Jump to content
Sign in to follow this  
polarpro

Calc based on a record creator's privilege set

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 :P 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

Share this post


Link to post
Share on other sites

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

FLA.png

Share this post


Link to post
Share on other sites

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

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.