We have different tasks for DataObjects and documents via listener (pimcore.dataobject.postUpdate), e.g. for url generation or indexing. We noticed that changes to the restrictions of the MembersBundle are always made after the event, which can lead to problems.
This is because the storage in the RestrictionController is done via Ajax after postSaveObject or postSaveDocument in dachcom-digital/members/src/MembersBundle/Resources/public/js/backend/startup.js.
This bypasses the pimcore.dataobject.postUpdate event. The preSaveObject would probably be too early, alternatively an event in the RestrictionController would be needed so that you can recognize the restriction changes.
@js-aw, I just prepared a PR for that. Please note, that we support inheritance, so these new evens may trigger several times, if a sub-entity inherits restrictions!
We have different tasks for DataObjects and documents via listener (pimcore.dataobject.postUpdate), e.g. for url generation or indexing. We noticed that changes to the restrictions of the MembersBundle are always made after the event, which can lead to problems. This is because the storage in the RestrictionController is done via Ajax after postSaveObject or postSaveDocument in dachcom-digital/members/src/MembersBundle/Resources/public/js/backend/startup.js. This bypasses the pimcore.dataobject.postUpdate event. The preSaveObject would probably be too early, alternatively an event in the RestrictionController would be needed so that you can recognize the restriction changes.
I can also provide a pull request for this.