Jump to content
Sign in to follow this  
MHAriete64

New user with limited access

Recommended Posts

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 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"

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

See here.

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

Share this post


Link to post
Share on other sites

However, behavior has changed in FM10. Link

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

gPrivSet=PrivSetCreated in the rla.

Share this post


Link to post
Share on other sites

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 by Guest

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.