New user with limited access

[MHAriete64]

I have a fairly complicated issue. The current solution is relatively complex, with 19 tables, all related to a table I’ll call PARTICIPANTS.

Here’s the issue: A peripheral department in the organization, one that serves some of those already in the database’s PARTICIPANTS table, is now asking to use the solution to track their participants as they transition through their own programs. A simple change might be to give this new player access to the server and allow them to log in just like the original clients.

The problem is, they really shouldn’t have access to ALL the PARTICIPANTS records, only those PARTICIPANTS they serve. Also, the original clients for whom the solution was designed should always have access to all the PARTICIPANTS.

The original client is the umbrella department for the services these participants are receiving, so they will always have full access.

I’m thinking of some kind of partitioning effect - when they log in they can only see and find records that get some kind of tag in a field (maybe through a privilege?). But, they should interact with the data with all the same layouts and scripts as the original layout b/c we will make these changes to the current hosted solution.

This should also be generalizable and transferable, so that as this solution becomes more and more desirable by other departments it can grow rather easily.

Thanks for your help!

Edited May 8, 2009 by Guest
The Topic: <a href="http://fmforums.com/forum/showtopic.php?tid/205135">New user with limited access</a> was moved from <a href="http://fmforums.com/forum/showforum.php?fid/32">Relationships</a> to <a href="http://fmforums.com/forum/showforum.php?fid/33"

[bcooney]

Your instincts are correct, this is a case for Privilege Sets and Accounts, using Record level access settings. Each table needs a field "PrivSetCreated" that is set in each record to the Get ( PrivilegeSetName ). Then you can set RLA rules where Get(PrivilegeSetName) = PrivSetCreated in order to edit/view the record.

[MHAriete64]

BCooney, thanks for a) your response, which prompted moving me to the right forum area.

But, can you say just a bit more about this recommendation. I understand adding a field that identifies what Privilege Set will have access to any given record. But, the Record Level Access (RLA) is a new area for me. Any more detail on this would be appreciated.

Thanks.

[mr_vodka]

See here.

http://fmforums.com/forum/showtopic.php?tid/198109

[bcooney]

However, behavior has changed in FM10. Link

So, you'd gPrivSet=Get (PrivilegeSetName) in an open script and use

gPrivSet=PrivSetCreated in the rla.

[Moses Holmes]

I am working with MHAriete64 on this same project and attempted to implement all of the above suggestions without achieving the results that we are aiming for. Regardless, I would like to offer much gratitude to bcooney and Mr. Vodka for the help thus far!

I’ll re-iterate our problem in light of attempting the previous proposed solutions:

First off, the solution in question requires a number of different User Accounts with several levels of Access and Privileges across multiple Entities. I’m calling any group or organization that wants to use this database as a template for its own sets of records an Entity.

In essence, what we would really like to achieve would be to have one server-based database that can be used by several different Entities, each Entity containing multiple User Accounts with their own respective Privilege Sets.

There would be a Main Entity hosting the base-level database and serving several sub-entities, each having their own User Accounts, respective sets of records while using the same general layouts/ fields. The Main Entity has “root” level access to all of the records of itself and the various sub-entities. The sub-entities can view and modify only their own sets of records and not even see the current 2000+ records in the Main Entities’ database.

In other words, a sub-entity seeing 2000+ records with “” printed in 295 fields would not be an efficient way to browse its own additional 300+ records. This was the result of attempting to use the Get ( PrivilegeSetName ) = PrivSetCreated in the RLA view calculation.

For sake of portability, this problem cannot easily be solved by using Get(AccountName) as the sentinel value for determining sets of records to be viewed based on Privilege Set for reasons that should now be apparent by the above description or our database schema.

To further compound the problem there is another key variable at work here. There are a set of particular fields in each record that are populated with rather sensitive data via a scripting process that queries yet another server. It would be desirable that this scripting be run exclusively through the Main Entity for all records across all entities, thus the need for both the encapsulation of the sub-entities and root level access for the Main.

I hope this helps shed some light on the complexity of our dilemma. Thanks in advance for any help and expertise you can offer. It is very much appreciated.

Edited May 15, 2009 by Guest