#48140 Allow mod_post to consider existing objects for addition to MEP
Closed: wontfix None Opened 9 years ago by firstyear.

MEP expects that the only time it will create a managed entry is on the addition of the entry. Modifying an existing entry and then having it retrospectively add the managed entry is not supported.

Currently, if one creates an object such as:

objectClass: top
objectClass: account
uid: foo
sn: bar

Followed by a mod operation to add posixAttributes, in a standard MEP with user -> group template, the group is not created, because the operation isn't considered unless it's an add.

This attached patch adds support and dynamic plugin tests to allow MEP to create managed entries if a mod operation would bring an entry into a state where it now satisfies the criteria of the template.


Additionally, the patch has commented tests and locations in mep.c for the inverse, where when you take an entry that has a managed entry, and remove "enough" parts of it to fall out of the mep scope, that the managed entry should be removed also. This behaviour however, being more "destructive" should be controlled by a configuration item to state whether the current MEP behaviour or the new behaviour is followed:

  • Current -> If you remove the parts of an entry that would make it fall out of the MEP scope, the managed entry is not removed.
  • Proposed optional -> If you remove the parts of an entry that would make it fall out of the MEP scope, the managed entry is removed.

Hi William,

I reviewed the mep.c part. Your fix looks good.
I guess you are currently working on movig the test script to ds/dirsrvtests/suites/mep_plugin.
I could wait for your new patch with the change for another review to push your patch. Or if you split the patch into 2 -- one for mep.c and another for the test script, then I'd push the mep.c one to the git repo. Either way works for me.

Also, setting the milestone to 1.3.4.

Thank you so much for your contribution!
--noriko

Replying to [comment:1 firstyear]:

  • Current -> If you remove the parts of an entry that would make it fall out of the MEP scope, the managed entry is not removed.
  • Proposed optional -> If you remove the parts of an entry that would make it fall out of the MEP scope, the managed entry is removed.

Regarding this proposal, once the origin entry gets out of scope of the mep plug-in, the managed entry can be manually removed, can it? (Please note that if it is in the scope, it is not allowed.)

Automated deletion sometimes causes unexpected surprise. To implement it, a new config parameter needs to be introduced and switch between reserving the current behavior and the new behavior.

But the proposal itself looks very useful. Could you please open a new ticket for the feature?

I'll tidy this up into two patches. One for the tests, one for the feature.

I will add another ticket for the deletion feature. I suspected that configuration option for this would be the preferred way forwards. The deletion is a bit more complicated to implement, and I have a skeleton version of it partially working already.

I'm currently investigating a few outstanding failures in the tests, and will update accordingly.

additional patch: it'll avoid the mod ops if it was called from the plug-in. but still my test does not pass... keep investigating...
0001-Ticket-48140-Allow-ME-creation-on-mod_post-for-exist.patch

Patch to allow MEP to create managed entries if an object modification would cause the object to satisfy the mep criteria
0001-Allow-ME-creation-on-mod_post-for-existing-entries.patch

Updated patch with cleaned up tests. Passes full dynamic test suite and stress test.

I would rather focus on http://directory.fedoraproject.org/docs/389ds/design/mep-rework.html and drop these changes. There were too many issues with my original approach.

Replying to [comment:10 firstyear]:

I would rather focus on http://directory.fedoraproject.org/docs/389ds/design/mep-rework.html and drop these changes. There were too many issues with my original approach.

Thanks for the clarification, William. I'm going to close the associated bug.

Metadata Update from @nhosoi:
- Issue assigned to firstyear
- Issue set to the milestone: 1.3.4 backlog

7 years ago

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 issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1471

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)

3 years ago

Login to comment on this ticket.

Metadata