Boris Kraft wrote:
To beat a dead horse: submit your changes and you don't have to worry
that it breaks with every update :-)
Okay FINE! Maybe I will!!!! ;-)
Alright. So here's the first thing I plan to tackle: creating a
distinction between having the right to edit and having the right to
publish (activate). My current implementation is rather crude (but it
works). I have created a role called 'cmsPublisher'. If a user has
this role, then any content for which they have 'write' privileges they
also have activate/deactivate privileges. I have added logic in
info.magnolia.module.admininterface.trees.AdminTreeWebsite to control
whether or not to enable the activate/deactive options.
// Does this user have rights to publish content?
boolean canPublish = false;
try {
Content user = Authenticator.getUserPage( request );
Content roles = user.getContent( "roles" );
Collection nodes = roles.getChildren();
Iterator i = nodes.iterator();
while( i.hasNext() ) {
Content node = (Content) i.next();
if( node.getNodeData( "path" ) != null && node.getNodeData(
"path" ).getString().equals( "/cmsPublisher" ) ) {
canPublish = true;
break;
}//end if
}//end while( i.hasNext() )
} catch( Exception ex ) {
ex.printStackTrace();
}//end try/catch
// if no subscriber is configured or the user is denied publish
rights, then disable related actions
if( !Subscriber.isSubscribersEnabled() || !canPublish) {
menuActivateExcl.addJavascriptCondition("new
mgnlTreeMenuItemConditionBoolean(false)"); //$NON-NLS-1$
menuActivateIncl.addJavascriptCondition("new
mgnlTreeMenuItemConditionBoolean(false)"); //$NON-NLS-1$
menuDeActivate.addJavascriptCondition("new
mgnlTreeMenuItemConditionBoolean(false)"); //$NON-NLS-1$
}
This is fine, but not very granular. A more robust solution would be to
expand the current roles dialog editor to support the ability to define
publish rights in the same way that read/write/deny rights are set.
Thus, it would be possible to give someone the authority to approve
changes but not actually have the authority to make the changes and
vice-versa. Also, you could have authority to modify certain parts of
the tree, authorize changes other parts of the tree, have both rights
for other parts of the tree, and then even be denied other parts of the
tree. This is both flexible and powerful.
So given that vision, where in the source code is the security role ACL
list (read, write, deny) defined? I would like to add another one
(publish) but I have been unable, thus far, to locate where this is
defined. Secondly, I think I recall that the read/write/deny rights
actually have JCR codes that they correspond to (1, 2, 4, 8, etc.). Is
there a code that can be used for publish rights? I did manage to find
info.magnolia.cms.security.Permission which lists off several
permissions and their codes. The last two in the list are execute(16)
and syndicate(32) could either of these be used to represent the
'publish' permission?
Your feedback is welcome.
--
Kyle Gabhart
Program Engineer
L-3 Communications
Link Simulation and Training
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
