Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

console - support additional LDAP Organization fields #2552

Merged
merged 31 commits into from
Jul 18, 2019
Merged

Conversation

cmangeat
Copy link
Contributor

@cmangeat cmangeat commented Mar 19, 2019

Proposal for #2146

@fvanderbiest
Copy link
Member

There are conflicts, can you update the PR please ?

@cmangeat cmangeat requested a review from groldan May 14, 2019 08:47
fvanderbiest added a commit to georchestra/georchestra.github.io that referenced this pull request May 14, 2019
@fvanderbiest fvanderbiest removed the request for review from severo May 15, 2019 12:24
@jeanpommier
Copy link
Member

jeanpommier commented May 22, 2019

You're keeping the competency area (list of INSEE IDs) in the groupOfMembers' description field ? Woudn't it be more explicit to use a dedicated field in the georchestraOrg object ?

fvanderbiest added a commit to georchestra/ckanext-georchestra that referenced this pull request May 22, 2019
@fvanderbiest
Copy link
Member

You're keeping the competency area (list of INSEE IDs) in the groupOfMembers' description field ? Woudn't it be more explicit to use a dedicated field in the georchestraOrg object ?

Very good point Jean.
We should indeed take advantage of this PR to clean the mess, eventually creating a new schema field.

@landryb
Copy link
Member

landryb commented May 23, 2019

Yes, but once and for all... think of the ones who built code that uses the existing DIT schema :)

@fvanderbiest
Copy link
Member

Yes, but once and for all... think of the ones who built code that uses the existing DIT schema :)

You're a bit late to the game...
I'm not sure I get your point. Would you like us to not use custom fields ?

@jeanpommier
Copy link
Member

No, I think Landry says not to move this extent information elsewhere; We actually can keep it on the description field. It is just not very obvious which is which, since we'll have a description field on both objects defining the organization.
Anyway, Id' tend to say that if we move it in a dedicated field in the georchestraOrg object, it should not be so difficult to adjust existing apps to use it, right ?
And yet, will your applications support the pending evolution in the LDAP schema ? If not, it will indeed be a good opportunity to clean up a little bit

@landryb
Copy link
Member

landryb commented May 23, 2019

Its fine to use a custom schema instead of abusing existing object fields, and i dont mind if description content is moved to another attr, as long as it's changing at every release.

adding attributes is fine (like for image/url/etc), its renaming/repurposing attributes that can get hairy.

@fvanderbiest
Copy link
Member

Anyway, Id' tend to say that if we move it in a dedicated field in the georchestraOrg object, it should not be so difficult to adjust existing apps to use it, right ?

Agreed. To my knowledge, only https://github.com/georchestra/foncier makes use of it atm.

as long as it's changing at every release

OK, I get your point now. Yes, we do not break stable releases (well, we try) ;-)

@cmangeat
Copy link
Contributor Author

@groldan here...

Copy link
Member

@fvanderbiest fvanderbiest left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but we'll change the field to store city codes in a second time.

@cmangeat
Copy link
Contributor Author

816c170 need the "right" latest docker image to be available for tests.

@groldan
Copy link
Member

groldan commented Jul 11, 2019

@cmangeat please rebase on top of master, the branch 60 commits behind master.
It rebases fine, but when running mvn verify -Pit to run integration tests, get a bunch of failures like this one:

[ERROR] Failures: 
[ERROR]   OrgsIT.createAndGet:62 Status expected:<200> but was:<500>
[ERROR]   OrgsIT.createAndGetWithDescription:95 No value at JSON path "$.description": com.jayway.jsonpath.PathNotFoundException: Expected to find an object with property ['description'] in path $ but found 'java.lang.String'. This is not a json object according to the JsonProvider: 'com.jayway.jsonpath.spi.json.JsonSmartJsonProvider'.

Copy link
Member

@groldan groldan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cmangeat please rebase on top of master, the branch 60 commits behind master.
It rebases fine, but when running mvn verify -Pit to run integration tests, get a bunch of failures like this one:

[ERROR] Failures: 
[ERROR]   OrgsIT.createAndGet:62 Status expected:<200> but was:<500>
[ERROR]   OrgsIT.createAndGetWithDescription:95 No value at JSON path "$.description": com.jayway.jsonpath.PathNotFoundException: Expected to find an object with property ['description'] in path $ but found 'java.lang.String'. This is not a json object according to the JsonProvider: 'com.jayway.jsonpath.spi.json.JsonSmartJsonProvider'.

Other than that the patch looks pretty straightforward, but can't really run a more in-depth review until the branch is building fine.

@@ -119,4 +122,10 @@ public ResultActions perform(RequestBuilder requestBuilder) throws Exception {
public String testName() {
return testName.getMethodName();
}

public String readRessourceToString(String name) throws URISyntaxException, IOException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: readRessourceToString -> readResourceToString

Copy link
Contributor Author

@cmangeat cmangeat Jul 12, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed typo and rebased ... thanks.

Copy link
Member

@groldan groldan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. If at all, change the title of the PR so that the merge commit message is more informative.

@groldan groldan changed the title Org fields 2 Support additional LDAP Organization fields Jul 18, 2019
@groldan groldan merged commit 3199e93 into master Jul 18, 2019
@fvanderbiest
Copy link
Member

Tested, looks good !

Capture du 2019-07-23 10-46-26

Capture du 2019-07-23 10-46-50

@fvanderbiest fvanderbiest changed the title Support additional LDAP Organization fields console - support additional LDAP Organization fields Jul 23, 2019
@fvanderbiest fvanderbiest added this to In progress in Geo2France via automation Jul 23, 2019
@fvanderbiest fvanderbiest modified the milestones: 19.09, 19.12 Oct 22, 2019
@fvanderbiest fvanderbiest deleted the org-fields_2 branch December 3, 2019 08:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Geo2France
  
In progress
Development

Successfully merging this pull request may close these issues.

None yet

6 participants