Jump to content
Server Maintenance This Week. ×

Hide records based on current login and layout


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

Recommended Posts

One table ANSWERS, 2 fields EVALUATOR and MANAGER (and a lot of others with more data), 2 layouts Evaluator and Manager, based on the same table.

I want to hide records based on the layout AND the current logged in user's appearance in either of the 2 fields. (Managers should only see records when they are in the Manager field, and Evaluators when in the Evaluator field).

The Manager layout is not accessible by Evaluators. The Evaluators layout is accessible by both roles (as some Managers are also Evaluators).

Now I have a "Limited..." View restriction for Privilege set "Evaluators" that is this:

not IsEmpty ( FilterValues ( Evaluators_Names ; Z_GlobalValues::CurrentAccountName ) )

Which works fine for Evaluators; if they do a Find *, they see only 'their' records. 

Now, I have a "Limited..." View restriction in a Privilege set "Managers". A bit more complicated this time, because it depends on the Layout being viewed:

- Managers should see all records where they are listed in the Manager field on the Manager layout, but should only see records where they are in the Evaluator field on the Evaluator layout. Remember that they can be in both.

( 
not IsEmpty ( FilterValues ( Get ( LayoutName ) ; "Manager" ) )
and
not IsEmpty ( FilterValues ( Manager_Name ; Z_GlobalValues::CurrentAccountName ) ) // one and only one
)
or
(
not IsEmpty ( FilterValues ( Get ( LayoutName ) ; "Evaluator" ) )
and
not IsEmpty ( FilterValues ( Evaluators_Names ; Z_GlobalValues::CurrentAccountName ) ) // can be multiple evaluators
)

When a manager logs in (and a script Find *), he sees NO records in the Evaluator layout (although I'm certain he is in some Evaluator fields), nor in the Manager layout (same thing with Manager field).

If I leave out the LayoutName lines, all records show in both Layouts, (the middle OR statement works) but this is not what I want (while 'managing', a Manager should not see the records where he is Evaluator only).

2 possibilities:

  1. My logical testing is wrong (I doubt it, I've tried to verify this logical testing with a calculation field based on the same criteria, and there everything checks out fine.)
  2. The logical structure is ok, but it doesn't work as expected for a limiting view Privilege sets. (Something to do with syntax, or impossible to use LayoutNames testing?)

Please help if you can...

Edited by Roeland De Windt
Link to comment
Share on other sites

Thanks Steven,

I see "LayoutNames, ... since they can be spoofed" under the Inappropriate column, and not endorsed as Best practice. But should or should it not work technically? Shouldn't FMP throw an error if I try to use them?

Or do they work from a technical pov, but is my syntax wrong? Any workaroud to accomplish the same thing? 

Edited by Roeland De Windt
Link to comment
Share on other sites

@Roeland De Windt

I suggest you redefine your rules in terms of what data can each group access at all times - regardless of which layout is the current layout. Because if I am allowed to view a record or a field through layout A, there's no point in denying me access to the same record or field through layout B (and I am very likely to find a way to do it anyway).

Link to comment
Share on other sites

Please Do not edit your posts after they have been replied to.

Your last post is confusing?

Are you referring to the link I removed the period from in Steven’s post, or the one I posted?

Link to comment
Share on other sites

51 minutes ago, comment said:

@Roeland De Windt

Because if I am allowed to view a record or a field through layout A, there's no point in denying me access to the same record or field through layout B (and I am very likely to find a way to do it anyway).

Yes there is a point to deny imho...

MANfred has role MANager, EVEline has role EVAluator (role = privilegeset).

Record 1: Manager field = Manfred, Evaluator field = Manfred, Answer field = x1, EmployeeName field = y1
Record 2: Manager field = Manfred, Evaluator field = Eveline, Answer field = x2, EmployeeName field = y2
Record 3: Manager field = Manfred, Evaluator field = SomeOneElse, Answer field = x3, EmployeeName field = y3

Eveline will have access to Evaluators layout only, and see only records with her name in Evaluator field (Record 2 in this case) so that's no problem.

Manfred will have access to both layouts. In the Manager layout he should see all 3 records, ok.
In the Evaluator layout Manfred should only see Record 1, as he only needs to evaluate (to ACT on) that one. It's not only a matter of convenience: Manfred should not see Records 2+3 in Evaluation view. You could argue that I should assign an Edit limitation in for field Answer field x (and I have, only editable by Evaluator roles), but I thought it wise to hide the records altogether (as Manfred has no business there anyway).

Edited by Roeland De Windt
Link to comment
Share on other sites

26 minutes ago, comment said:

What is a matter of, then? It's certainly not a matter of security, since Manfred has access to all three records.

 

Manfred should not be able to change answer fields in any record but those where he is listed as evaluator. I have already limited this Edit access for the manager privset:

If ( PatternCount ( Get ( LayoutName ) ; "Manager" ) ; // should be rewritten as 'not isemtpy filtervalues' like in View privset
0 ;
PatternCount ( Evaluators ; Z_GlobalValues::CurrentAccountName ) // should be rewritten as 'not isemtpy filtervalues' like in View privset
)

This works. No edit access on manager layout (0) for anyone (view yes, only if listed as manager), and on the evaluator layout only edit access when listed in field Evaluators. Now one step further would be to hide the records altogether when on Evaluator layout.

45 minutes ago, Lee Smith said:

Please Do not edit your posts after they have been replied to.

Are you referring to the link I removed the period from in Steven’s post, or the one I posted?

Sorry Lee, Steve's original link is still bad. Yours works. I'll refrain from editing my posts after answers come in, good point.

Edited by Roeland De Windt
Link to comment
Share on other sites

If you want Manfred to be able to view any answer for which he is the manager, but edit only answers for which he is the evaluator, you should set the Managers custom record privileges for the Answers table as follows:

Records can be viewed when:

Get ( AccountName ) = Manager

Records can be edited when:

Get ( AccountName ) = Evaluator

This is assuming both the Manager and Evaluator fields contain a single name each - not a list of names.

 

33 minutes ago, Roeland De Windt said:

Now one step further would be to hide the records altogether when on Evaluator layout.

This is not a security issue, and the best way to solve it would be through running a script triggered (for example) OnLayoutEnter.

Link to comment
Share on other sites

Final solution, after comment's last post (clarifying the non-security issue in ANSWERS table depending on role)...

Manager Role, View privset:

not IsEmpty ( FilterValues ( zc.Emp_Manager_UPN ; Z_GlobalValues::CurrentAccountName ) )
or
not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) )

Manager Role, Edit privset:

not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) )

Evaluator Role, both View and Edit privset:

not IsEmpty ( FilterValues ( zc.Emp_Evaluators_UPNs ; Z_GlobalValues::CurrentAccountName ) )

And then I have 2 separate OnLayoutEnter scripts, both finding records in the same ANSWERS table, but depending on current layout

  1. Manager layout: finds CurrentAccountName in Manager field
  2. Evaluator layout: finds CurrentAccountName in Evaluator field

As for security, indeed, a Manager may manually find records in the Evaluation layout (because he is listed as manager) that he needn't answer, but he won't be able to edit as per privset. The above OnLayoutEnter finds should cover that situation.

Seems to do the trick. Simple solutions are often the best!

Link to comment
Share on other sites

This topic is 2852 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.