Jump to content

Record Security Restrictions Break Relationships


This topic is 2821 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

I've got two tables. Employees and MBO. The MBO table is related to the Employees table by a simple employee id number. When a new MBO record is created for an employee, it's foreign key is populated with the employee id for which it was created. There is a portal on the Employee records which shows the corresponding MBO records.


Each Employee record has a "Reports To" field which specifies the employee id of the person that supervises them. Each MBO record has a calculation field ("Reports To") that evaluates to "Employees:Reports To". View/edit access to both Employee records and MBO records is restricted so that users can only see records if they are their own or if they are the supervisor listed on the record.


Everything works correctly when the user has full access.


When the access restrictions are enabled, they prevent access in exactly the way you expect them to. The part that isn't working, is that with the record restrictions turned on, the portals showing MBO records on Employee records no longer work. They're empty. Additionally, the "MBO:Reports To" calculation field no longer evaluates. It's blank. This is puzzling because even though the field is blank, the calculations fueling the MBO record view/edit restrictions still works (Reports To = $$userIndex or Windows AD Name = Get ( AccountName )).


I've played around with this a lot now and have googled a fair bit, but I'm coming up empty handed. Any help anyone can offer is greatly appreciated.

Link to comment
Share on other sites

Rather than trying to understand why your setup (which I don't fully follow) doesn't work, let me suggest an approach that should: starting with an RG that looks like this:




where both Supervisor and Supervised are occurrences of the Employees table, set the Employees privilege set to allow View access to records in the Objectives table when:

Get ( AccountName ) = Employees::AccountName
Get ( AccountName ) = Supervisor::AccountName


The Supervised TO is not really required for the current purpose, but I thought it best to include it for clarity.

Link to comment
Share on other sites

  • 1 month later...
  • Newbies

Thank you for your response and I'm sorry for not responding sooner. This project was shelved when other stuff came up. I'm now working on it again.


I set things up exactly as you laid out. The permissions work in that a user can view records in the "Employees" table and "Objectives" table if they are either that employee themselves, or listed as the supervisor of that employee. The problem is that it seems to break the relationship between "Employees" and "Objectives" when a supervisor is viewing the records of one of their employees.




We have two employees, Tom and Susie. Susie is Tom's supervisor.


Susie is able to view her own record in a layout showing records from the "Employees" table. The portal showing related records from the "Objectives" table displays correctly.




Susie is able to view Tom's record in the layout showing records from the "Employees" table, but the portal showing Tom's records from the "Objectives" table is blank.




This is what Tom sees when viewing his own record.




If Susie navigates over to the layout showing records from the "Objectives" table, she can view records for both herself and Tom, however, when viewing Tom's records, it doesn't not display any fields from the related record in the "Employees" or "Supervisors" tables.



Note that Tom's name (from the "Employees" table, as well as the EmployeeID field from both "Supervisor" and "Employees" is missing.)



I have to admit that I'm really at a loss here. It's a pretty simple setup and it looks to me like everything should be working. I must be missing something. Any further help anyone can provide would be greatly appreciated.

Link to comment
Share on other sites

This topic is 2821 days old. Please don't post here. Open a new topic instead.

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

  • Create New...

Important Information

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