Andreas Hartmann wrote:
Richard Frovarp schrieb:
Andreas Hartmann wrote:
Richard Frovarp schrieb:
Is there any documentation on how aggregate-fallback actually
works? Or is the source it?
AFAIK theres no docu on the website. I added some more info to the
javadocs.
-- Andreas
Thanks. Clears up what I thought I read in the source. How does it
affect the usecase configuration? Our default configuration has an
aggregate-fallback.
Does the top level usecase-policies.xml override any setting? Or does
it merely add grants/denies? For example:
sitemangement.archive
publication: edit grant
template: sitemanager grant
What is the end result for the sitemangement.archive usecase in the
publication? Is it (edit), (sitemanger), or (edit,sitemanager)?
From a quick look at the UsecaseRolesBuilder I'd say it is (edit):
for (int i = 0; i < usecaseElements.length; i++) {
// add roles only if not overridden by child publication
if (!usecaseRoles.hasRoles(usecaseId)) {
...
usecaseRoles.setRoles(usecaseId, roleIdArray);
}
}
IIUC the builder adds sets the roles for a usecase only for the first
encountered element. Since the iteration is top-down, the instance
overrides the template. If the system behaves differently, I'd
consider it a bug.
IMO this behaviour is reasonable, because otherwise you couldn't deny
permissions which are defined by the template.
WDYT?
-- Andreas
That makes sense to me. I've had issues in the past with not being able
to change usecase permissions. Wanted to make sure I understood what was
going on while I'm trying to upgrade to 2.0.1.
Thanks,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
