Presets Redux

On my current project, I finally have the opportunity to use presets to configure Webtop without performing WDK customizations.  I was aware of some of the capabilities of presets from EMC World, but this was the first time I could implement presets against user requirements.  One set of requirements was that certain Webtop features should only be available to certain roles.  This may sounds trivial except for the fact that the roles were not hierarchical and users may belong to multiple roles.

Lets use an example.  Assume there are two roles: submitter and approver.

The submitter role can see the WDK Import action; the approver role can not.  Also, the approver can see the WDK Copy and WDK Move; and the submitter can not.

In the WDK customization world, this is easily accomplished by scoping the appropriate WDK component to the role.  This does not work in the preset world.

When defining presets, you can select the role that you are configuring a preset for (eg submitter).  For the Action rule, you are given a UI to select which WDK actions to exclude. This is fine so far.   For the submitter role, I exclude the Copy and Move actions.  For the approver role, I exclude the Import action.  This implementation of the requirements is relatively straightforward.

The preset engine checks to see if a user belongs to the role.   If so, it fires off all the rules associated for the role.  The problem is that the preset engine is only looking to see if there is one match.  This makes sense if you assume the roles are hierarchical, like the default client capability roles that the Content Server provides (eg consumer, contributor, administrator, etc).  This design does not support a user belonging to multiple roles – user is both a submitter and an approver.

In this case, the preset engine either 1) disables Import and enables Copy and Move or 2) enables Import and disables Copy and Move. There is no way to enable Import, Copy and Move.

I realize that Preset is a new feature that came out with D6.  Like the first incarnation BOF, there are a few shortcomings with the initial design.  Hopefully, EMC has thought about this and will be making Preset into a true rules engine.  Until that happens, I can at least still rely on WDK customizations.

Advertisements

6 responses to “Presets Redux

  1. fredericfortin

    Hi Johnny,

    I had similar issues it the past with WDK scoping. One of my customers was implementing the functionality scoping by exclusion instead of inclusion.

    People tend to think of role design like security permissions while it’s not. When implementing security you must restrict the users to certain levels. When working with roles you must open functionalities not close them.

    Most of the time the users are made as contributors and developers are excluding functionality. This is a major mistake. The users should be made consumers and given extra actions. I understand that it’s more work but this is the only way to make it work when a user is in two roles.

    I don’t know much about presets (yet). I don’t know if it has or will have an “include” rule but the fact that it provides an “exclude” rule is a huge mistake. Its misleading users to a bad design approach. I think EMC should take it off for future release and provide good practices as why exclusion should not be used.

  2. Seems like you could create a role “submitter and approver” which contains the other two roles, then create a combined preset that has a higher prio than the single role rules… It’s been long enough since I’ve looked at this, but I thought you could order the rules like this…

  3. Johnny, was going to suggest the same thing as Bindu, but he beat me to it. With a small number of roles, it works. Obviously the problem becomes exponential if the role count increases. It is a stop-gap measure at best.

    You could just do what we do and not give the users Webtop. 🙂

    Pie

  4. Thanks for the comments guys, glad to hear that there are still people reading my blog after my hiatus. Hi Bindu/Pie, as you eluded, the problem is more complex if than I have described it. Thanks for your input though.

  5. Hi Johnny,
    I don’t usually blog or comment but I appreciate those who do. I was a lead engineer working on presets at EMC Documentum (now moved on to Education Services, writing courses for application and system architects). I thought I would add to this conversation on presets by giving a little bit of background about how presets work “under the covers”.

    The PresetService is an SBO that provides a service to save and load preset configurations (i.e. dmc_preset_packages) to and from the repository. The PresetService also provides an API for editing preset configurations. This API is used by the Webtop preset editor components.

    The PresetService doesn’t do any interpretation or enforcement of rules. When Webtop starts up, the preset configurations are dynamically loaded into the WDK ConfigService in-memory structures. After that, preset configurations are looked up and enforced just like the WDK component configurations that you are all used to using (i.e. ConfigService.getInstance().lookupElement(, context), etc.).

    It is true that with Webtop presets as well as WDK ConfigService in general, settings for all of the groups/roles that a user belongs to are not aggregated. I believe that the solution that Bindu suggested is what is commonly done to accomplish the desired aggregation. But you are right that this can be cumbersome especially if there are lots of roles and not a very formal role structure defined for the application.

    WDK 6.0 and above app.xml has a new configuration element called that allows you to specify a precedence order to be used for establishing context for configuration lookups. This precedence applies whether the configurations are static (i.e. in component config files) or dynamic (presets).

    Hope this bit of information is helpful. As the evolution of Documentum application development progresses with CenterStage, I expect you will see context based configuration capabilities pushed lower in the stack and pervasively available to both applications and services. Your feedback and commentary is very useful in future improvements.

    Thanks,
    Kristy

  6. Thank you Kristy for providing some insight. I’m happy to hear that people on the product team read my blog (as well as others) and do care what we think. Sometimes I think we’re not heard unless we work for a high priority client or our client has $$$ invested in EMC licenses.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s