[
https://issues.apache.org/jira/browse/SLING-9963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber updated SLING-9963:
------------------------------------
Description:
the {{AccessControlEntry} takes an 'operation' as param to the constructor
which can only have 2 values: 'allow' or 'false' in expected to ultimately form
valid repo-init statements later.
i would find it a lot cleared if a boolean 'isAllow' would be used instead and
hardcoding the corresponding repo-init values 'allow' and 'deny' would be
located in the {{AccessControlEntry}} class instead of being defined in
{{RepPolicyEntryHandler}}. i spotted it while doing some initial work for
SLING-9692 and found myself hardcoding the string "allow" again in the handler
used for principal-based access control.
was:
the {{Acl}} takes an 'operation' as param to the constructor which can only
have 2 values: 'allow' or 'false' in expected to ultimately form valid
repo-init statements later.
i would find it a lot cleared if a boolean 'isAllow' would be used instead and
hardcoding the corresponding repo-init values 'allow' and 'deny' would be
located in the {{Acl}} class instead of being defined in
{{RepPolicyEntryHandler}}. i spotted it while doing some initial work for
SLING-9692 and found myself hardcoding the string "allow" again in the handler
used for principal-based access control.
> AccessControlEntry: refactor 'operation' string to boolean/enum
> ---------------------------------------------------------------
>
> Key: SLING-9963
> URL: https://issues.apache.org/jira/browse/SLING-9963
> Project: Sling
> Issue Type: Improvement
> Components: Content-Package to Feature Model Converter
> Reporter: Angela Schreiber
> Priority: Major
>
> the {{AccessControlEntry} takes an 'operation' as param to the constructor
> which can only have 2 values: 'allow' or 'false' in expected to ultimately
> form valid repo-init statements later.
> i would find it a lot cleared if a boolean 'isAllow' would be used instead
> and hardcoding the corresponding repo-init values 'allow' and 'deny' would be
> located in the {{AccessControlEntry}} class instead of being defined in
> {{RepPolicyEntryHandler}}. i spotted it while doing some initial work for
> SLING-9692 and found myself hardcoding the string "allow" again in the
> handler used for principal-based access control.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
