You might consider it useful to have; but there is a reason why the official security checklist recommends to disable the CRXDE Bundle! I don't really agree to recommendation, because for debugging purposes CRXDE has proven its value. But definitely not for performing changes in PROD.
TreeLoader.js:153 TypeError: Cannot read property 'properties' of undefined
at getMergedPropertyDefinitions (NodetypeRegistry.js:53)
at Array.each (Ext.js:43)
at Object.getPropertyDefinitions (NodetypeRegistry.js:120)
at constructor.processNewChild (RepositoryTree.TreeLoader.js:56)
at Object.<anonymous> (TreeLoader.js:142)
at Object.each (ext-base-debug.js:407)
at constructor.processResponse (TreeLoader.js:139)
at constructor.handleResponse (ext-all-debug.js:47781)
at Ext.data.Connection.handleResponse (ext-all-debug.js:8550)
I think adobe should fix that, since user has enough permission to view those content, and login as admin does work without js error.
I would hope that they can only replicate via crx/de if they have replicate permissions on the node (I have not verified this, but it seems like something the system would prevent a user from doing if they don't have replicate access to the node). Technically, a savvy enough user could also just send the appropriate REST operation to do what crx/de is doing and if they have permissions, the system will allow it.
I am not advocating and advertising this to our end users, but it is a lot easier for some people to see how the page is created and then copy sections of the page via crx/de. For example, when I created a complex page that had a lot of reference links to other content embedded in other components, it was easier and faster for me to copy a node that defined the component and paste / change that node in crx/de than it would have been via the editor.html interface. Since I had value out of crx/de, I find it hard to prevent other people from getting a similar value out of it.
I do agree that it allows them to bypass business processes and other policies / checks in place for field values. All that being said, it isn't being used all the time by the powerusers. It is more of a helpful tool for them to troubleshoot any problems that they may not see in the editor or preview modes. Thanks for the explanation about the cause of this change!
With 6.4 there was some problem with login on CRXDE Lite if you don't have read permissions on /conf (or something like that, was a weird permission thing). Daycare should know that topic and should be able to help you.
Anyway, if your powerusers work directly on CRXDE Lite and modify nodes and properties, I wonder why you need AEM at all. They are using the system in a way, which is hardly controllable (the only constraints are permissions, but everything else is totally free to them), and therefor they can bypass many processes you have provided to authors. For example, in CRXDE Lite they can trigger replication and bypass any approval workflow.
I do not recommend that approach at all. Access to CRXDE should always be restricted.
While I agree only Admins should have access to CRX DE, in practice, our "power users" find that they can do more when they have access to it (ie. change content / page templates / properties directly). I created a group that has access to crx/de by setting the permissions to be "Read" on "/" and "conf" (I did not need that group to have read on the etc or home directories but YMMV).
Additionally, I noticed that if I added a person to the "operators" group, they would have access to crxde, but I can't seem to locate any documentation on what the "operators" group in AEM does (The node permissions seem very restrictive, but I don't know if they had additional permissions on osgi bundles).
This does work. Though I'm not sure why since the permissions to the paths are the same as the content author group.
I've also confirmed that with the custom group and the content author group added for the test user, that crx/de access is maintained.
With further testing of the above I found the solution will be to create a custom group called "crxde-access" or something of the sort and manually grant permissions to it as above. Then assign that "crxde-access" group to the content authors group. This allows all content authors access to crx/de folders, as well as editing rights in crx/de in the content directory.
I'm seeing similar issues with my 6.4 implementation. I created a local AEM test user and put that user into the content author's group. Then validated that the test user was granted read access via the content author group.
However when logged in as that user the CRX console does not show the folders in which the user has read access to:
There is ONE exception. If I add permissions to "home" withing user admin, that then shows up under CRX/DE but no other folders with the same permissions do.
The only solution I have found is that in order to access crx/de a user must be in the Administrators group, which is not a good solution for content admin access.
On /crx/de console, the nodes are listed based on user's permissions.
You'd need to navigate to localhost:4502/useradmin > Login with admin account > Search the user/group whose permissions you'd like to modify > Double click on that user once it is listed in the search list on left panel > Click on Permissions tab > Check/uncheck whatever permissions you want that user/group should have.
Is this what you're looking for?
Yes, I would like to know which permission I must add to my user to allow read and modify the rest of the folders
He already has read/write permission under /content/myproject/
Hence, I would say for the new AEM version we need to add another special permission.
Could you elaborate your use case?
The 'title' of question made me think that you want to know how to get access on /crx/de console. Is this correct?
You could navigate to '/useradmin' and assign appropriate "read", "write" permissions to users/groups.