Right now, security policy is extracted from database. So, we can configure grants and permissions for a specific user(Principal) through uman tool and is working fine. But when it comes to participants mapping, it is done from participant-map.xml.
1] What is the difference between users and participants ?
2] Is there a way to store even paticipant mapping.xml details in database itself?
3] FOR US, USERS ARE PARTICIPANTS. And if 100 (n) users needs to be mapped to a store then participant-map.xml would become big. Is there any way to make this mapping through database?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello john,
we never meant to offend you or scream at you. we think here you have misunderstood us. We just wanted to highlight the point that "for us , users are participants".
We never wanted to make any rude comments. We like to work on OpenWFE.
Sorry , if any statement of ours hurt you.
Hoping to hear from you soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1). Participants are tied to the <participant/> expression in the process definitions, those definitions are interpreted by the engine component.
Users are users of the worklist component.
The participant-map.xml file tells what is really behind a participant, usually participants are mapped to a worklist.
In the file worklist-configuration.xml, participants are 'assigned' to workitem stores.
Users, as per etc/worklist/passwd.xml are granted access to stores.
That's it.
2). Yes, you have to extend the class openwfe.org.engine.participants.AbstractParticipantMap or at least to implement the interface openwfe.org.engine.participants.ParticipantMap
3). Your questions are overlapping each other and this question somehow replies to question 1).
Yes, as per reply 2). you could have different ways of storing your participant-map.
Are you sure you need to have one store for each participant ? Couldn't you go and have 1 or 2 participants and then have multiple users ? That would be way more elegant. Please search the 'Help' forums, I've answered to this question so many times and please save our time and have a look at : http://web.openwfe.org/display/openwfe/Chosen+threads
Best regards,
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. Sorry to disturb you again. Please provide some more insight to your replies.
reply-1)
In our view, 'user' logs on to the 'webclient' and sees any tasks assigned to him/her. If tasks got assigned, then he/she will act on that. This gives me an impression that 'user' itself is a 'participant'(to whom workitem is assigned), and whose mappings with stores and permissions are configured with 'uman' interface. Please correct me if Iam wrong here.
Uman provides a greater control on mapping stores to users and setting appropriate rights(At present we are using oracle database rather than passwd.xml). Similarly we want to store other configuration files to be fetched from database instead of fetching from file system as we are planning to develop interface to manage this stuff. What are the steps that we need to take to extract configuration details from database.
reply-2)
Can you please elaborate on below point.
--Couldn't you go and have 1 or 2 participants and then have multiple users--
Thanks,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1). users may be mapped one-to-one to participants, it's a matter of configuration.
Indeed, the uman interface allows you to determine mappings from user to store (but not form participant to store).
2). I already explained you what you have to do in order to have an alternative participant-map 'storage'.
3). Please go and search the help forum for strings like 'users' and 'participants', I have explained this so many times and I'm currently on vacation. I don't feel like repeating myself for free once again).
You'll soon understand the provided levels of indirection and the flexibility it gives you in configuring your 'organizational model'.
Best regards,
John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi John,
Right now, security policy is extracted from database. So, we can configure grants and permissions for a specific user(Principal) through uman tool and is working fine. But when it comes to participants mapping, it is done from participant-map.xml.
1] What is the difference between users and participants ?
2] Is there a way to store even paticipant mapping.xml details in database itself?
3] FOR US, USERS ARE PARTICIPANTS. And if 100 (n) users needs to be mapped to a store then participant-map.xml would become big. Is there any way to make this mapping through database?
WHY ARE YOU SCREAMING ? THIS IS RUDE !
Hello john,
we never meant to offend you or scream at you. we think here you have misunderstood us. We just wanted to highlight the point that "for us , users are participants".
We never wanted to make any rude comments. We like to work on OpenWFE.
Sorry , if any statement of ours hurt you.
Hoping to hear from you soon.
Then everything is OK, let's go on :-)
1). Participants are tied to the <participant/> expression in the process definitions, those definitions are interpreted by the engine component.
Users are users of the worklist component.
The participant-map.xml file tells what is really behind a participant, usually participants are mapped to a worklist.
In the file worklist-configuration.xml, participants are 'assigned' to workitem stores.
Users, as per etc/worklist/passwd.xml are granted access to stores.
That's it.
2). Yes, you have to extend the class openwfe.org.engine.participants.AbstractParticipantMap or at least to implement the interface openwfe.org.engine.participants.ParticipantMap
3). Your questions are overlapping each other and this question somehow replies to question 1).
Yes, as per reply 2). you could have different ways of storing your participant-map.
Are you sure you need to have one store for each participant ? Couldn't you go and have 1 or 2 participants and then have multiple users ? That would be way more elegant. Please search the 'Help' forums, I've answered to this question so many times and please save our time and have a look at :
http://web.openwfe.org/display/openwfe/Chosen+threads
Best regards,
John
Hi John,
Thanks for your reply. Sorry to disturb you again. Please provide some more insight to your replies.
reply-1)
In our view, 'user' logs on to the 'webclient' and sees any tasks assigned to him/her. If tasks got assigned, then he/she will act on that. This gives me an impression that 'user' itself is a 'participant'(to whom workitem is assigned), and whose mappings with stores and permissions are configured with 'uman' interface. Please correct me if Iam wrong here.
Uman provides a greater control on mapping stores to users and setting appropriate rights(At present we are using oracle database rather than passwd.xml). Similarly we want to store other configuration files to be fetched from database instead of fetching from file system as we are planning to develop interface to manage this stuff. What are the steps that we need to take to extract configuration details from database.
reply-2)
Can you please elaborate on below point.
--Couldn't you go and have 1 or 2 participants and then have multiple users--
Thanks,
Hi,
1). users may be mapped one-to-one to participants, it's a matter of configuration.
Indeed, the uman interface allows you to determine mappings from user to store (but not form participant to store).
2). I already explained you what you have to do in order to have an alternative participant-map 'storage'.
3). Please go and search the help forum for strings like 'users' and 'participants', I have explained this so many times and I'm currently on vacation. I don't feel like repeating myself for free once again).
You'll soon understand the provided levels of indirection and the flexibility it gives you in configuring your 'organizational model'.
Best regards,
John