Allow to set property disabled for users in AC Tool config (setting rep:disabled under the hood)

[mtstv]

As a new feature would have to set/reset some others User/Group properties.
For example I want to set a cq:authorizableCategory="blabla" for existing "/home/users/system/replication-receiver" user and to reset (delete) "rep:disabled" property to "null".

[mtstv]

May be it can be implemented similar to "initialContent" functionality for ace_config?

[ghenzler]

We have profileContent and preferencesContent already (see https://github.com/Netcentric/accesscontroltool/blob/develop/docs/Configuration.md#configuration-of-users), if set they do reset the profile and preferences data (this also works for groups). Do you really need to set properties on the very node /home/users/system/replication-receiver itself?

[mtstv]

The predefined property "rep:disabled" is neither in the profileContent nor in the preferencesContent of "home/users/system/replication-receiver" user. I need really to reset/delete the alreday existing property "rep:disabled" directly in the "home/users/system/replication-receiver" Node to enable this already existing user for replication purpose in the AEM.

[mtstv]

here is the import from AEM 6.2
/home/users/system/replication-receiver/.content.xml

<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:rep="internal" xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="rep:User" 
    jcr:mixinTypes="[rep:AccessControllable]"
    jcr:uuid="345bef9b-ffa1-3e09-85df-1e03cfa0fb37" 
    rep:principalName="replication-receiver" 
    rep:authorizableId="replication-receiver" 
    rep:disabled="Please enable this user before using it as replication transport agent." 
/>

[ghenzler]

The rep:disabled property can be controlled via the interface User: https://jackrabbit.apache.org/api/2.6/org/apache/jackrabbit/api/security/user/User.html#disable(java.lang.String)

As it is not a simple boolean, if adding this here it would have to be something like
disabledReason: "User is disabled" <-- this is easy
enable: true <-- call to User.disable(null) effectively enabling the user again
left out <-- no change/no call do User.disable

@mtstv Do you see any other properties that would have to be set on the very authorizable path itself (and not in sub nodes profile or preferences)?

[mtstv]

At the moment no.
I think only one extra property for User Config would be Ok.

disabledReason: "User is disabled." - String describing the reason for disable this user
disabledReason: "" - empty if the user account should be enabled again.
left out - no change/no call of User.disable()

[ghenzler]

Then I'll probably just use the following:

To disable: disabled: "User is disabled" or disabled: true (calling User.disable("true") and effectively setting the reason to true)
To enable: disabled: false (this will actually call User.disable(null) to enable it)
To leave unchanged: property left out

[mtstv]

Ok, good