Calc based on a record creator's privilege set

[polarpro]

Hey,

My records contain a field "Creation_AccountName" with the Account Name of the user who created the record.

I am trying to add a calculation field to my table that shows a certain result, if the name held in Creation_AccountName belongs to a certain Privilege Set. Any suggestions?

Thank you for your ideas,

Mike :P

[LaRetta]

I would suggest using their Staff table (where each staff member is listed) and include a field naming their privilege (whatever you wish), possibly using a value list. Then check this table for their privilege within the calculation.

[comment]

a calculation field to my table that shows a certain result, if the name held in Creation_AccountName belongs to a certain Privilege Set.

And if not? IOW, what's the purpose here?

[David Jondreau]

Not sure what you're really trying to accomplish, but why not capture the Privilege Set Name instead of the Account Name?

[polarpro]

Thank you, LaRetta, this works fine. I had it all set up, but didn't see how easy it was (and wrecked my brain with more complicated approaches...)

The reason why I'm setting this up: Our records have a field that hold one or more values that describe the record's so-called "functional area". There is a check-box set where they can tick Proof Reading, Fact Checking, Enquiries,... When a user of the "Proof Readers" privilege set marks a record in such a way as 'relevant for proof reading' (among others),

1. a calc field gets set and shows other users which user group "owns" this record and

2. the record can be edited by the other users of this privilege set through the relationship LaRetta suggested.

(Sounds complicated?)

I must admit though, capturing the Privilege Set name right from the beginning sounds even easier...

[Steven H. Blackwell]

Depending on the sensitivity or the criticality of your data, I would likely avoid "user tables" or artificial or ersatz system to determine privileges. You might want to see this FM Forums article.

I'd also recommend taking a look at thefmkb.com/7161 Tech Info for a discussion about appropriate and inappropriate Record Level Access tests.

Steven

[LaRetta]

I do not recommend User tables either for standard privilege sets. I saw the request as a one-time thing ... a method of identifying the privilege set of existing account data. And there is NO way to do so without using a temp field and no better place than using the staff table with 50% of the data already complete.

However, it is quite acceptable to provide management check boxes in which they can control additional rights for their Users from browse mode.

[David Jondreau]

I'm confused by two passages in the KB article.

"In FileMaker Pro 10, you have to put the name of the privilege set in the calculation."

"Appropriate RLA tests are those whose determinations lie outside the definition of the Privilege Set itself. It is almost circular logic to say that a Privilege Set bit’s definition must rely on something within that Privilege Set itself."

Must Privilege tests in 10 now include the privilege set name itself? What does the first passage mean?

[David Jondreau]

Testing indicates you don't need the privilege set name, but what does this mean?

"In FileMaker Pro 10, you have to put the name of the privilege set in the calculation. Since the calculation is in the privilege set definition, it is a constant. Much like when doing calculations in scripts running as full access, all privilege calculations are now evaluated from the standpoint of the [Full Access] Privilege Set."

[bcooney]

This thread might help DJ

[Steven H. Blackwell]

What it means is that if the Privilege Set name is evaluated within the context of the RLA test itself, it will always return [Full Access] as the result.

Further, what it means is that there are a number of tests that people have been using that are inappropriate RLA tests. The Tech Info article attempts to delineate those.

Steven

[Steven H. Blackwell]

However, it is quite acceptable to provide management check boxes in which they can control additional rights for their Users from browse mode.

Unless access to such fields is carefully controlled, they can be manipulated and users can thereby promote their privileges. A custom extended privilege is a more secure approach for this.

Steven

[LaRetta]

Unless access to such fields is carefully controlled, they can be manipulated and users can thereby promote their privileges. A custom extended privilege is a more secure approach for this.

I agree but unfortunately that is not always the world we live in. If a business requires highly advanced, complex privileges (and Management needs to manipulate those privileges easily without developer) then using check boxes is the only viable alternative otherwise the custom privileges can become impossible to administer.

If access to those check boxes and layouts is tightly controlled via privileges then why is it any different than controlling any other field view or data via privileges? There is none. Full, tight privileges MUST be in place and never should passwords be within data. But if someone can break into getting to check box data (when privileges are in place to prohibit viewing/changing those fields or even accessing those layouts) then ALL data is already compromised anyway.

[David Jondreau]

What it means is that if the Privilege Set name is evaluated within the context of the RLA test itself, it will always return [Full Access] as the result.

OK, I see now. Thanks.

[polarpro]

Thank you very much, Steven, for pointing out what could go wrong regarding the user table. (7161 is very interesting.)

I think LaRetta's solution still works fine (as I now have highly restricted access to the user table); but having all this in mind, it seems to me now that the most secure way to implement what I want is to create a new field that captures the name of the privilege set that the record was created with; like D J mentioned. This solution seems to be the simplest, too...

Thanks again,

Mike

[Steven H. Blackwell]

But if someone can break into getting to check box data (when privileges are in place to prohibit viewing/changing those fields or even accessing those layouts)

The key here is that access to these checkbox type fields [color:red]cannot be controlled by layouts or similar User Interface devices. Access can only be controlled by field level privilege settings in the Manage Accounts & Privileges section of the security schema as shown in the attached screenshot.

Steven

[LaRetta]

The key here is that access to these checkbox type fields [color:red]cannot be controlled by layouts or similar User Interface devices.

Precisely and I thought I was clear that I said using Accounts & Privileges to restrict access to field data, view and layouts but I appreciate you being more specific, Steven.

Edited May 25, 2009 by Guest
Changed sentence