processi

about processes and engines

UserGetStrategy

This post complements that one on ParticipantGetStrategy.

Many times, I’ve been asked on the forums : “I’ve got many users and each of them needs a store for his workitems”. I usually replied that the integrator/developer could simply parse out workitems that are not for the [requesting] user when building the view on the store. This question came so many times that a few months back, I implemented a “UserGetStrategy”.

The file etc/worklist/worklist-configuration.xml contains the stores’ settings, it looks like :

    <service
        name="Store.inbox"
        class="openwfe.org.worklist.impl.store.SimpleWorkItemStore"
    >
        <param>
            <param-name>participants</param-name>
            <param-value>inbox</param-value>
        </param>
    </service>

With such a vanilla setting, everybody with a read access on that store will see every workitems in it. You can define a ‘GetStrategy’ for each of those stores.

(The parameter ‘participants’ has the value ‘inbox’, it means that all the workitems for the participant ‘inbox’ will be directed to this store. The parameter participants accepts comma-separated lists of participant names as well as regular expressions)

    <service
        name="Store.inbox"
        class="openwfe.org.worklist.impl.store.SimpleWorkItemStore"
    >
        <param>
            <param-name>participants</param-name>
            <param-value>inbox</param-value>
        </param>        
        <param>
            <param-name>getStrategyClass</param-name>
            <param-value>openwfe.org.worklist.impl.store.UserGetStrategy</param-value>
        </param>
    </service>

Out of the box, the UserGetStrategy, when consulted by the store upon a ‘browse’ request by a client, will only allow to return workitems whose field ‘__username__’ value is equal to the requesting user’s name.

This strategy could get leveraged by process definitions like this one :

    <sequence>
        <user uname="Kurt" />
        <user uname="Roberto" />
    </sequence>

    <process-definition name="user">
        <sequence>
            <set field="__username__" variable-value="uname" />
            <participant variable-ref="inbox" />
        </sequence>
    </process-definition>

The process (the first) sequence uses the subprocess ‘user’ which takes care of setting the field ‘__username__’.

The process integrator will certainly ensure that every process definitions in his engine can take advantage of the ‘user’ subprocess by making it an engine-level process (for example by putting it (defining it) within the etc/engine/library.xml file).
It’s an easy way to extend OpenWFE’s process definition language and to have easily readable main process definitions.

Written by John Mettraux

May 20, 2006 at 7:57 pm

3 Responses

Subscribe to comments with RSS.

  1. Hi john,

    the normal question after the configuration of a store like this is how can i create a super user who can get access to all items in this store, i meen that how can we create an administrator to this store?

    this is the first question.

    the second question: if i’d like to add a variable wich contole the privecy of a work item how can i define it, that men, i’d like to add a variable “private” if this varlable take the value true the work item will be accessible to all users of the store, and if this variable is false the work item still accessible only for this user.

    note: i talk about user not role, so the second question is related to the first,

    the conclusion is that i want to crate a store with the UserGetStrategy but i want an administrator to this store, and i want to controle the visibility of workiltems coz i have a private workitems and a public work items.

    best best regard John

    Rami (Romio)

    rami

    May 21, 2006 at 10:49 am

  2. Hi Rami,

    could you please repost your question on the help forum ?

    Thanks for your understanding.

    John

    jmettraux

    May 21, 2006 at 11:26 am

  3. […] The OpenWFE worklist relies on two main concepts : workitem stores and users. Users are granted access rights to each store. By default a read access right allows to read any workitem in a given store. But you can swap the strategy a store uses to filter workitems presented to each users. I already blogged about the UserGetStrategy and the ParticipantGetStrategy. […]


Comments are closed.

%d bloggers like this: