Privelege Set Case Statement

[uemtux]

Hi all,

No matter what user/permission set I am logged in as, this calculation ALWAYS evaluates to 1. The weird thing is, I can take each individual case, and evaluate them in the Data Viewer, and they all evaluate to a big fat boolean 0. Logged in under the user I am, this value should be 0, but it's not. (It's an unstored calculation)

Help?

Case(

Get(PrivilegeSetName) = "SL20Accounting" ; 1 ;

Get(PrivilegeSetName) = "SL30VPPublishing" ; 1 ;

Get(PrivilegeSetName) = "[Full Access]" ; 1 ; 0

)

[Fenton]

Storage options for such a calculation (and many others in the Get() functions) should be set to [x] Do not store, if you want them to be dynamic.

[uemtux]

As I mentioned, this is an unstored calculation. Thanks. :)

[comment]

Are you sure?

What happens if you change it to =

Case(

Get(PrivilegeSetName) = "SL20Accounting" ; 1 ;

Get(PrivilegeSetName) = "SL30VPPublishing" ; 2 ;

Get(PrivilegeSetName) = "[Full Access]" ; 3 ; 0

)

Or:

Sum (

Get(PrivilegeSetName) = "SL20Accounting" ;

2 * ( Get(PrivilegeSetName) = "SL30VPPublishing" ) ;

4 * ( Get(PrivilegeSetName) = "[Full Access]" )

)

[uemtux]

Logged in as a user with permission set "Test" the 1-2-3 case is returning 3, as if I were logged in as "[Full Access]"

The data viewer is confirming my Privilege set name as "Test"

[comment]

Is this a calculation field? Or a script?

[uemtux]

An unstored calculation field.

[comment]

Then I don't know. Does this work for you?

85.zip

[Vaughan]

Is this calculation in a field or in the access privileges itself?

What version FMP are you using (include the v revision number too please). Is the file hosted in FMS? If so, give the FMS version number.

[Zcast]

Well, you say you are logged in with the permission set "Test", but does your "Test" permission set have [Full Access]?

[Vaughan]

Good question Zcast...

To uemtux: create a script in the file that displays a custom dialog, the custom dialog message is

"account: " & Get( accountname ) & "¶" &

"privileges: " & Get( privilegesetname )

See what it shows.

Note that in FMP 11 there are 2 possible privilege sets returned: the *current* privilege set, and the privilege set that the user opened the file with.

[comment]

does your "Test" permission set have [Full Access]?

What does "have [Full Access]" mean?

[Zcast]

I can create a new privilege set, call it "Test", and give it access to everything, which in turn is really [Full Access].

[comment]

I don't think you can do that. But even if you could, the set's name would still be "Test", not "[Full Access]".

[Zcast]

Yes, you are correct Comment, that will not work.

To uemtux: Can you post a sample file with that problem? I would like to see that myself.

Edited June 10, 2010 by Guest

[bruceR]

Good question Zcast...

To uemtux: create a script in the file that displays a custom dialog, the custom dialog message is

"account: " & Get( accountname ) & "¶" &

"privileges: " & Get( privilegesetname )

See what it shows.

Note that in FMP 11 there are 2 possible privilege sets returned: the *current* privilege set, and the privilege set that the user opened the file with.

To be more specific, the FM11 feature allows a script running with full access to evaluate the user's actual current privilege set, as opposed to what we might consider the script's privilege set.

[Vaughan]

I'd phrase it this way: you can see what privilege set the user initially logged-in with (which is arguably their "real" privilege set); and you can see what privilege set they have right NOW which may be at the moment a script is running with [Full Access] privileges.

FM 10 and earlier only allows the determination of a users privilege set right NOW.

The function has been renamed in 11 but I cannot remember what it is now called, since I'm not actively developing in 11 yet.

[uemtux]

the strange thing is, if I make a fresh file, what I'm doing seems to work. I suppose it may have to do with the particular database. It's a 3GB DB that's gone from one version of FM to the next for the past 5 years, it has been corrupted and rebuilt 3 or 4 times, and I'm currently editing it live as 50 or so users use it. Maybe the file is corrupt?

I have changed the calculation (again, the case statement I showed you all is an unstored calculation field) from my original post to the 1-2-3 model comment suggested so I can tell which Case it's matching. It's always returning 3, suggesting I have [Full Access] privileges, but the data viewer tells a different story.

Sorry, I lied, the privilege set name is not Test -- I just hate typing out the boss-mandated privilege set names... :

Edited June 10, 2010 by Guest

[bruceR]

Except that "initially logged in with" is not accurate either, it seems to me. They could have done a re-login; in which case that IS there current account and privilege set and that is what the new functions see.

[bruceR]

the strange thing is, if I make a fresh file, what I'm doing seems to work. I suppose it may have to do with the particular database. It's a 3GB DB that's gone from one version of FM to the next for the past 5 years, it has been corrupted and rebuilt 3 or 4 times, and I'm currently editing it live as 50 or so users use it. Maybe the file is corrupt?

I have changed the calculation (again, the case statement I showed you all is an unstored calculation field) from my original post to the 1-2-3 model comment suggested so I can tell which Case it's matching. It's always returning 3, suggesting I have [Full Access] privileges, but the data viewer tells a different story.

Sorry, I lied, the privilege set name is not Test -- I just hate typing out the boss-mandated privilege set names... :

I still suggest you upload an example file illustrating your problem. This is all kind of pointless without that.

Edited June 11, 2010 by Guest

[Vaughan]

Except that "initially logged in with" is not accurate either, it seems to me. They could have done a re-login; in which case that IS there current account and privilege set and that is what the new functions see.

Ahhh, I was wondering about that situation. Thanks for confirming.