Re: ldap isGroupUser

good question greg.  The way we're doing it is to map our xpdl
participants to the ldap group.  So, when an activity is started every
ldap user in that group can view and accept the activity.  Once
someone accepts it, then the activity becomes locked, so others cannot
accept it.
hth,
Ben

On 7/25/05, Dahl, Greg (BLM) - contr <[email protected]> wrote:
> Thanks for your response.
> 
> Another question struck me about this - how do you handle locking of
> workflow records?
> 
> I can imagine an external system where you can keep track of individual
> users and the groups they belong to.  Then, its pretty simple to map
> each of those external groups to a shark user id.
> 
> But it occurred to me that if I have ten people in a group and that
> group is tied to a single Shark user id, how do I prevent the first
> person in that group from grabbing work that the second person in the
> same group has started working on?  Since, to Shark, both of those users
> will be logging into the workflow system with the same Shark ID.
> 
> I hope that makes sense.
> 
> Of course, I could do my own locking, but then I'm getting close to just
> implementing the whole thing myself.
> 
> Greg
> 
> 
> > -----Original Message-----
> > From: Ben Anderson [mailto:[email protected]]
> > Sent: Friday, July 22, 2005 3:47 PM
> > To: Dahl, Greg (BLM) - contr
> > Subject: Re: [shark] ldap isGroupUser
> >
> >
> > well, we're all sticklers - we're software developers :-)
> > yes, that is what I meant (I think)
> >
> > we need to map our ldap groups to participants in shark.  So,
> > everyone under a certain group in ldap can see specific
> > activities.  Once someone accepts the activity, then we won't
> > let others see it.  This is how we're doing the work queue concept.
> >
> > -Ben
> >
> > On 7/22/05, Dahl, Greg (BLM) - contr
> > <[email protected]> wrote:
> > > Ben,
> > >
> > > I'm working on something slightly different, but you mentioned you
> > > need to map "roles to groups" - do you mean you needed to map your
> > > _participants_ to groups in Shark?  I'm not trying to be a
> > stickler,
> > > but if there is something else that can be done, I'd like to
> > > investigate it in trying to solve my own issues.
> > >
> > > Greg
> > >
> > >
> > > > -----Original Message-----
> > > > From: Ben Anderson [mailto:[email protected]]
> > > > Sent: Friday, July 22, 2005 8:32 AM
> > > > To: [email protected]
> > > > Subject: Re: [shark] ldap isGroupUser
> > > >
> > > >
> > > > nevermind - this works fine.  All I needed to do was to
> > map roles to
> > > > groups and the users are derived from that.
> > > >
> > > > On 7/22/05, Ben Anderson <[email protected]> wrote:
> > > > > Hi,
> > > > > I'm a little unsure of exactly how ldap user/groups map to
> > > > > participants.  We're using the 2nd option of ldap
> > > > configuration.  What
> > > > > I'd like to do is just define group participants in our
> > > > xpdls.  Here's
> > > > > the example.  In ldap we have 2 users, jsmith and jdoe.
> >  They both
> > > > > belong to the indexer group.  Now, in our xpdl we specifiy the
> > > > > performer to be indexer.  When an activity which has
> > the indexer
> > > > > as the performer is started I want both jsmith and jdoe
> > to see it.
> > > > > I think this is working fine as long as we create
> > > > > ParticipantMappings for both jsmith and jdoe.  Since
> > the ldap will
> > > > > be changing
> > > > much more
> > > > > than our shark bundled application, I don't want to have to
> > > > create new
> > > > > ParticipantMappings for each user.  Is this a requirement
> > > > for shark to
> > > > > work, or will it derive the mappings automatically since I
> > > > defined the
> > > > > indexer participantMapping? Thanks,
> > > > > Ben
> > > > >
> > > >
> > > >
> > > ******* Confidentiality Notice *******
> > > This email, its electronic document attachments, and the
> > contents of
> > > its website linkages may contain confidential health information.
> > > This information is intended solely for use by the individual or
> > > entity to whom it is addressed.  If you have received this
> > information
> > > in error, please notify the sender immediately and arrange for the
> > > prompt destruction of the material and any accompanying attachments.
> > >
> > >
> > >
> > >
> >
> >
> 
>

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws