| Author |
Message
|
| ptazbaz |
 Posted: Tue Oct 08, 2002 3:50 pm Post subject: Retrieving array of person objects |
 |
|
Apprentice
Joined: 23 May 2002
Posts: 29
|
| Does anyone know of an elegant way to retrieve a collection( Array, Vector, etc) of Person objects from workflow using the java api? I want to be able to locate all Persons that are authorized for a given worklist and then check their levels, but I don't want to have to logon on as each individual person in order to find out their level. |
|
| Back to top |
|
 |
| jmac |
| Posted: Tue Oct 08, 2002 5:01 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
The person object can be accessed using a persistent ID. The persistent ID of a person object is the userid. This should give you what you need.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| ptazbaz |
| Posted: Wed Oct 09, 2002 9:37 am Post subject: Array of Persons |
|
|
Apprentice
Joined: 23 May 2002
Posts: 29
|
| What Class and method are you referring to? I have an ExecutionService object and there are only two methods I know of that can return a Person object. One is userSettings() which requires you to be logged on as that person in order to retrieve all the info(name, level, etc.) and the other method is called persistentPerson() which does take the userid as a parameter. However that will only create a transient Person object and it does not retrieve any info like name or level. That method does not connect to the workflow server. If persistentPerson() returned all the object attributes, then I would be in good shape. Any thoughts? |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Oct 09, 2002 10:55 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Persistent person does retreieve all of the Person attributes.
I use code like this
| Code: |
System.out.print("Enter UserID ==> ");
String userName = ReadString(33);
Person thisPerson = service.persistentPerson(userName.trim());
thisPerson.refresh();
System.out.println();
System.out.println("User " + thisPerson.firstName() + " " +
thisPerson.lastName() + " has UserID " +
thisPerson.userID() );
System.out.println("Manager is " + thisPerson.manager() ); |
Let me know if you still have trouble
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| ptazbaz |
| Posted: Wed Oct 09, 2002 12:46 pm Post subject: Array of Person objects |
|
|
Apprentice
Joined: 23 May 2002
Posts: 29
|
| I thought you might mention refresh(). That method will only work if the logged on user that calls it has authority. Otherwise, it throws an fmc exception. My users have no priviledges other than looking at their work-items, but I still need to profile other Persons in the system using their logged on session. I cannot grant them any additional rights. It seems like the only way to do that is to log off that user under the covers, logon with an account that has authority and then retrieve the Persons. Then log out and log on as the original user. That is very ugly. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Oct 09, 2002 12:58 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
You are correct in that the refresh on the person object will fail if the issuing user does not have access to the Workitems of the user that is being accessed.
I still don't know very much about what you are attempting to do and what environment you are in (Fat or thin client) . But it would seem to me that you should be able to set up a "User Server" class that during initialization logs on as admin and has a static method that accepts as input a userid and returns the Person object. I have never done this, but it seems reasonable to me.
Please let me know if you try this.
GOOD LUCK
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| ptazbaz |
| Posted: Thu Oct 10, 2002 4:30 pm Post subject: Array of Person objects |
|
|
Apprentice
Joined: 23 May 2002
Posts: 29
|
As a test, I granted the priviledge of
AUTHORIZED_FOR STAFF
to a basic user and that allowed me to successfully call refresh() with that user's login. I cannot find much documentation on this priviledge. Can you provide some background on this and how much risk there would be in granting this priviledge to all users of my system. The only point of entry is through a work list, so there would be no way for them to make any other API calls other that what I provide in the gui. Any input is much appreciated. Thanks.
-Paul |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Oct 11, 2002 5:14 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Paul:
I too have seen very little on the "Staff Authority". One thing the doc states is that it allows you to "Define/Modify" users, I took this to mean Define/Modify in Buildtime, and Import person definitions into Runtime. Another thing I believe has to do with Defining Public worklists. I think I remember that you need Staff Authority to define a public list.
So your risk with assigning this authority is that:
the user could logon to Buildtime. This is easy to get around, just dont give the users access to the Buildtime client
The user could import staff. I don't think this is an issue if you don't give the user operation authority
The user could define a public worklist. This is the one that you will need to work at to ensure that they can do no harm. If you use the IBM fat client I think there is no solution. If you use the IBM Thin client, you can simply not give the usere the ability to Create a List
As to being able to access other users, I will have to run some tests on this. I thought that this was based on access to their workitems, but I can see how this attribute might apply. I will post my results here when I complete my testing.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Oct 11, 2002 7:27 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Paul:
You are correct, it is having "Staff Authority" that allows you to access other users.
In my mind this is good for your scenario, since this does not have much of an impact on "bad things a user might do" with this authority. The only exposure that I think you have is the third point in my last post. The user could create a "Public" worklist. However, if you are writing your own client (fat or thin), it should be a fairly easy thing to keep users from being able to creat lists.
In my "Ideal" world, I give some users a Role of "Workflow Administrator", it is these users that I let do things like, look at the Process Monitor, Create lists of any type, etc.
GOOD LUCK
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
|
|
