topic Re: Using Aspects to Control Access to Actions? in Alfresco Archive

Using Aspects to Control Access to Actions?

pjaromin — Sat, 18 Aug 2012 02:39:45 GMT

I'm heavily customizing Share and have a use case where I need to be able to have fine-grained control over the list of actions available for specific nodes based on various criteria. The list of actions available for any given node relates directly to the status/state of the node, not the user view

Re: Using Aspects to Control Access to Actions?

afaust — Sat, 18 Aug 2012 11:28:12 GMT

Hello,

it depends on how many actions you expect to end up with. I would have no problems with 1 or 2 aspects tracking some UI-related state, but more would be quite an overkill.

I'd attempt a Repository tier customization for the document library which is able to extract the necessary information from the element without the absolute need to maintain it as data on the node (only in cases where it is expensive to extract the information would I use a single aspect with some properties). On the Share tier you can then configure evaluators based on custom data extracted by the Repository tier.

Regards
Axel

Re: Using Aspects to Control Access to Actions?

pjaromin — Mon, 20 Aug 2012 00:38:07 GMT

That's a very cool feature I was unaware of that could very well come in handy…thanks!

The piece here that I now see is critical for understanding my core question but not included in my original post - mainly for brevity/clarity - is that my repo/Share extensions are really the basis of a "platform" deployed in numerous environments (multi-tenant) and therefore the rules for how and when specific actions are enabled need to be stored within the repository itself to avoid the need to maintain multiple, different spring context files/AMPS.

In other words, I need to develop one set of core extensions to the spring configs, etc. that can then be further customized through relatively simple additions/edits to custom configs stored within the repository itself. For example, a base tenant-specific "config" document that sets up the default list of actions available for specific types of nodes. Then configurable workflows that turn various actions on/off, again with the bootstrap workflows being the same for all tenants, differing only through tenant-specific repository-stored config docs and aspect property values.

Does this make sense and/or change your opinion?

Thanks!

-Patrick