jforget1
asked on
Reader Access
Have a form that I am using author fields to allow read access to only the user who submitted a request. I have been asked to open that a little. I have requests which will be coming in from multiple users within the same office. I would like to change the design so any user who is within an office can see all the requests placed for that office. I capture the office ID in a field and it is standardized format. How can I add a reader or author field to allow all users in office say 123 to see all these requests placed with 123 in that Office id field, not just there own.
ASKER
I thought reader was the way to go, did not want to assume, but is there a way to link to the value in the office field? It is not viable to do it by roles. Lets say I have user A and they enter a record for office 123, I have user B and they enter a record for office 123. Right now user A and B can only see the records they entered because they are the author. Can I do a reader field that ties to the value 123 in the office field so user A can see User B's requests and vice versa, but not the requests for other offices.
About the roles, it's rather easy:
- add a Readers-field OfficeReaders, computed, formula "[" + Office + "]"
- in the ACL, create groups of users per office
- assign each group the role of the appropriate office
- I hope there are no more than 72 offices... that's the max number of roles allowed
- you can do the same with group-names instead of roles, with Group/OU/ACME
Since Readers-fields need to be stored in the document before they can function, you need an agent to update existing documents.
- add a Readers-field OfficeReaders, computed, formula "[" + Office + "]"
- in the ACL, create groups of users per office
- assign each group the role of the appropriate office
- I hope there are no more than 72 offices... that's the max number of roles allowed
- you can do the same with group-names instead of roles, with Group/OU/ACME
Since Readers-fields need to be stored in the document before they can function, you need an agent to update existing documents.
ASKER
The problem is there are well over 100 offices involved and we do not know up front who will be the users for each office.
> The problem is there are well over 100 offices involved ...
Ah. Now you're in trouble, can't do that with roles, only with groups.
> ...and we do not know up front who will be the users for each office.
That's a disaster! If you don't know what office a user works for, how should your application know??
Does each office have its own server? You could restrict replication, but that would be a last resort solution to me.
Ah. Now you're in trouble, can't do that with roles, only with groups.
> ...and we do not know up front who will be the users for each office.
That's a disaster! If you don't know what office a user works for, how should your application know??
Does each office have its own server? You could restrict replication, but that would be a last resort solution to me.
ASKER
I agree I have been telling the people I work for that this is n ot possible. I was just hoping that there may be some way to tie into the office ID field and if there some way to tie into the commonality.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Appreciate the help, I may give this a lil time to see if maybe someone has some quirky work around.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Wouldn't an Office Definition then be the functional equivalent of a Group in the NAB? Maybe I don't understand where your proposed solution really differs from Groups.
You can also create a categorized view, first column is the office, and create a Page with that view embedded on it, with show single category. In that way, the documents for one office only can be shown. Note that this has nothing to do with security...
You can also create a categorized view, first column is the office, and create a Page with that view embedded on it, with show single category. In that way, the documents for one office only can be shown. Note that this has nothing to do with security...
ASKER
I think the problem here is that we have this database setup to be open and not require a lot of maintenance of the ACL. THat will limit the ability to capture the info needed above without making it very cumbersome, but I appreciate the help.
I appreciate the appreciation :)
Use roles for this purpose: give a group a role, and create an additional (internally generated) Reader-field with the value "[Role]"