This should be removed after we have the change in python-ldap package.
https://github.com/python-ldap/python-ldap/pull/247

Hey mate,

This looks like a really good idea, but I think the way we actually do the checking is going to cause some issues potentially. When we open the schema.c from 99user.ldif do we add "X-ORIGIN user-defined" to it?

What if a user supplies '98-myschema.ldif'?

It would be good to check the schema.c behaviour with content from 99user.ldif to be sure we have a consistent X-ORIGIN (even if one is supplied).

Thanks!

Hey mate,
This looks like a really good idea, but I think the way we actually do the checking is going to cause some issues potentially. When we open the schema.c from 99user.ldif do we add "X-ORIGIN user-defined" to it?
What if a user supplies '98-myschema.ldif'?
It would be good to check the schema.c behaviour with content from 99user.ldif to be sure we have a consistent X-ORIGIN (even if one is supplied).

This is a good point and one that caused me some grief with early versions of the UI... We can not rely on X-ORIGIN == USER_DEFINED to determine what is custom schema(editable) vs system/standard schema(non-editable).

If this is the only option(using x-origin), and unfortunately it might be, then it needs to be documented somewhere ( we'll be in touch @mmuehlfeldrh )

Hey mate,
This looks like a really good idea, but I think the way we actually do the checking is going to cause some issues potentially. When we open the schema.c from 99user.ldif do we add "X-ORIGIN user-defined" to it?

Yes. " X-ORIGIN 'user-defined' " is added for 99user.ldif.

What if a user supplies '98-myschema.ldif'?

It isn't added for something like '98-myschema.ldif' though...

It would be good to check the schema.c behaviour with content from 99user.ldif to be sure we have a consistent X-ORIGIN (even if one is supplied).

This is a good point and one that caused me some grief with early versions of the UI... We can not rely on X-ORIGIN == USER_DEFINED to determine what is custom schema(editable) vs system/standard schema(non-editable).

I agree... It is not a perfect solution but it is the only solution I found currently.

If this is the only option(using x-origin), and unfortunately it might be, then it needs to be documented somewhere ( we'll be in touch @mmuehlfeldrh )

So that's what I think:
- WebUI has a limited administration scope as I see it. So it is okay if WebUI will support only basic schema manipulations (still it is a pretty vast). We should document the part about X-ORIGIN of course. Also, I explicitly mentioned in the UI that it is about " X-ORIGIN 'user-defined' " exist or not exist thing (not like in Java console - standard/non-standard schema);
- dsconf CLI has bigger capabilities and you can do a bit more than you can do in WebUI, and construct the schema objects with all details. Also, it doesn't have any mentioning of 'user defined';
- and ldapmodify is for very experienced admins.

@spichugi Perhaps this is okay then, given it's added for 99user.ldif, but the issue there is that IPA on upgrade will sometimes write schema to 99user.ldif as part of replication ... so that means we can then edit system schema until the replica has a yum/dnf upgade and the schema update runs.

Saying that you shouldn't be using our command tools on IPA, so maybe non-issue?

For now I can't think of anything better, unless we went the other way - instead of adding X-ORIGIN to everything, we add a new schema element in schema.c (SYSTEMSCHEMA or whatever) to anything we read from /usr/share, then when it replicates from host A -> B, that SYSTEMSCHEMA is maintained even into 99user.ldif?

Risk there is breaking replication between 1.4 -> 1.3 that may not understand the new schema element type ....

I've made all the changes that were needed (applied @mhonek and @mreynolds requests).
Please, review.

@firstyear I think it makes sense to wait for IPA to make the feature request if they require it. I am not sure that they need it (or their users)... And it will go to the next big build anyway (now we have limited time and resources for such improvements)

LGTM for now. Lets get this in and play around with it more. We have time to make changes...

Is this really needed? Doesn't seem to do much

Is this really needed? Doesn't seem to do much

Yeap, it needed because of the how CLI tools work.
Let me give an example:

We have 'oc1' :

( oc1-oid NAME 'oc1' SUP top STRUCTURAL )

We want to add 'DESC' and we run schema objectclasses edit oc1 --desc "Hello world". So we have:

( oc1-oid NAME 'oc1' DESC 'Hello world' SUP top STRUCTURAL )

If we run schema objectclasses edit oc1 --sup Organization it won't change description
But if we run schema objectclasses edit oc1 --sup Organization --desc "" it will remove the DESC:

( oc1-oid NAME 'oc1' SUP Organization STRUCTURAL )

So if a user have cleared DESC form it will remove DESC from the objectclass. And it is why I have cmd.push.apply(cmd, [""]);

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3025

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.