Konrad Windszus

We should not implement that until we have a convincing use case for setting CUG ACEs with the ACTool.

This is related to #369

Of course a good patch adding that functionality (of optionally creating a version before installing anything with the ACTool) would also be great.

According to https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/release-notes/deprecated-apis.html?lang=en this should have been removed end of 2021 already, but even ACS AEM Commons is still using that and noone recommended a usable alternative I would for...

Could this be related to the usage of the [Composite NodeStore](https://jackrabbit.apache.org/oak/docs/nodestore/compositens.html)? That would indeed prevent modifying ACLs on that area. But I fear there is nothing that the ACTool could...

This requires Jackrabbit 2.18 which only ships with AEM 6.5+ though. Also compare with Adobe-Consulting-Services/acs-aem-commons#2541. Even 6.5.13 does not come with the necessary bundle `oak-authorization-principalbased` so currently only AEMaaCS is...

Since when do Lucene-based indices in Oak also support property constraints? Remember we have to support back to AEM 6.1. Also path restrictions are supported in Oak property indices (https://issues.apache.org/jira/browse/OAK-3263)...

> Since when do Lucene-based indices in Oak also support property constraints? I think this has been introduced with https://issues.apache.org/jira/browse/OAK-2278 so AEM 6.1 should support that.

Path restrictions are only supported in Lucene since Oak 1.2.3 (https://issues.apache.org/jira/browse/OAK-2599), so we cannot implement that except we increment the minimum system requirements.

At the same time it would probably be wise to get rid of lists of associative arrays in case the keys are unique. I.e. instead of ``` - user_config: -...