Using Aspects to Control Access to Actions?

[pjaromin]

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 viewing it, so permissions don't really seem appropriate - any user with access to the node should be able to perform only the functions available for that node in it's current state.

In some cases, nodes may be granted ALL actions upon creation. In others, a subset of actions may be available initially, with others added upon completion of specific workflow processes or upon other events.

My thought for supporting this is to create a series of custom aspects that track 1:1 with the set of available actions. I would then use a variety of strategies to apply/remove the aspects when appropriate, thereby adding and removing access to the aspect's partner action.

As I've only been working with Share for a few weeks, I thought I'd post this here to solicit feedback from those with more experience/insight.

Does this sound like a reasonable approach? Or is there some simpler/clearner/better mechanism I should be looking at?

Thanks!

-Patrick

[afaust]

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

[pjaromin]

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