Get(PrivilegeSetName) from the Accounts and privileges

[Homer]

I'm using FileMaker 10 revision 1.

I'm tired but I think the Get(PrivilegeSetName) function (and probably some other Get functions) are evaluating differently in FM10 !? At least, when they are evaluated from the Accounts and Privileges(A&P) module.

I understand the result for the Get(PrivilegeSetName) is implicit when I'm using this function to limit the access for a Privilege set, but this function is always returning the same result in FM10. I.e.: [Full Access].

The Data viewer is displaying the right result but conditions like If(Get(PrivilegeSetName)...), placed in the A&P module, aren't working anymore. While it was working in previous FM versions.

Any comments ?

Thanks !!

Edited January 10, 2009 by Guest

[bcooney]

Just ran a test and didn't see your problem. Can you post a test file?

[Homer]

Thanks for your feedback.

I don't think it is a context matter. Actually, it is not a developer context matter but it looks like a big concern for FileMaker's core programmers...

I quickly built a small file to demonstrate the problem. I tried on Mac and Windows and there's no difference in this bad behavior.

My demo file is here: http://idisk.me.com/forg99/Public/Dnloads/S4H_PrivilegesAndFunctions_InFm10.zip (the forum's add file feature doesn't seems to work).

Thanks for testing and I'll wait for more feedback.

[comment]

It's a bit weird to determine the privileges from the privilege set itself. Still, I can confirm that it doesn't behave as one would expect (and did in previous versions).

PrivilegesBug10.fp7.zip

[Homer]

Thanks a lot Comment for your time and expertise.

I tried your file and it doesn't display the "No access" message either. While it should because you placed an "On view" restriction for this table.

At first, I thought the problem was only when evaluating the Get(PrivilegeSetName) function inside an If, inside the security module... But your file shows that the problem exists even with a simpler and basic formula.

Well, where do I go from there ??

[comment]

I suspect the issue is with the privilege set getting the condition from within itself - at least I haven't been able to reproduce the problem using Get (AccountName).

I believe you should report this as a bug:

http://forum-en.filemaker.com/fm/board?board.id=aut

[Steven H. Blackwell]

Hi, Gaston. Happy New year. Are you running this from a script set to run with full access privileges?

Steven

[Homer]

Hello Mr. Blackwell !! It's always a pleasure to hear from you. Happy and healthy new year !

To answer your question, no ! Scripts, script steps, or buttons aren't used yet. I guess you are referring to the checkbox at the bottom of the Edit Script window in "ScriptMaker" !? If so, it is not the cause.

I'm trying to debug a solution I have here. But the problem describes earlier in this post is bugging me at the calculation level. It seems to be a problem in the security module for FM10 !? Because this function, used in a privilege access formula, was working great since FM7 (I think).

Thanks again for your attention !

[bcooney]

That context comment is just my signature line. (It's the cause of 99% of my grief! and an inside joke with my fm dev partner). Sorry, didn't mean to confuse the issue.

I see the problem as well using comment's demo. Hmm.

[Steven H. Blackwell]

The Privilege Set Name must be comparted to something, as in Exact(Get(PrivilegeSetName); "Managers") for the test to work. If calling just Get(PrivilegeSetName) it likely will return [Full Access] because the calculation engine always runs at [Full Access].

Still not sure what is happening with your file.

Steven

[Homer]

Good morning !

To bcooney: Funny, I thought it was your signature but I just wanted to explain it is not the cause for this problem/bug.

To Mr. Blackwell: I don't want to insist, but I tried using the exact() function as you proposed and it didn't fix the problem. Now, you know how much I love the security module who was introduced in FM version 7. I think it is thousands of time better than the primitive password-based 'security' for FM 6 and previous. I want this module to be as best as possible ! But I think the problem I describes is very important because some FileMaker solutions are now unsecured.

I make a new version to show the problem I'm talking about. It is available here as ...version2. To fully understand the issue, you have to make the same operations with FileMaker version 9 (or previous), then close the file, then open FileMaker 10 and try the same operations.

In FM10, FileMaker won't display the "no access" message (resulting of the view limited calculation) AND it won't disallow read/write permissions (resulting of the edit limited calculation) for users who belongs to the restricted Privileges.

I think I'm gonna report the bug to FMI as suggested by Comment ! Hopefully, they will listen even if I never wanted to be a FSA/FBA member. :)

[Steven H. Blackwell]

Gaston:

I am back from the West Coast now, so let me take a look at this as soon as i can do so.

Steven

[fabriceN]

Hi,

I have a slightly different issue here.

A privilege set with custom record access (view), based on a global variable

$$myVariable = myfield

always returns false in find mode, meaning that as soon as the user performs a find, no record is found.

Works well on FM9 Client

Works well on FM9 Server

Works well on FM10 Client

Doesn't work on FM10 Server !

Any idea ?

[bcooney]

bump. This one just got me. Is there a work-around so that you can compare a priv set to disallow view/edit?

[Steven H. Blackwell]

Hi, Barbara,

First take a look at thefmkb.com/7161 that talks about this issue.

It might be possible to set a global field to the privilege Set Name and make comaprisons that way. But as the tech Info notes, this is almost a case of circular logic.

Steven

[bcooney]

Thank you, Steven. I did end up at 7161, and did end up setting gPrivSet in my Open Script and changing the calcs in A&P to use gPrivSet rather than Get (PrivilegeSetName). I don't see how it's circular logic. In my system, we're restricting edit for all priv sets <>[Full Access].

So many tables, so many calcs to change. Yikes!

[comment]

I don't see how it's circular logic. In my system, we're restricting edit for all priv sets <>[Full Access].

What you are saying, in essence, is that "this privilege set allows editing, unless this privilege set forbids editing". IOW, the privilege set's contents depend on an attribute of the privilege set itself.

[Fenton]

Somehow I'm missing something. Wouldn't you just say: Edit ->No in the privilege sets?

[bcooney]

Yes, you would. If there were no conditions that would allow edit for that priv set.

I understand now the circular logic. I have 2 tests that allow a privset to edit, otherwise no edit. Mistakenly, I was thinking, "What will allow the user to edit this table" when I should have been thinking, "What will allow a user with this priv set to edit this table." I don't need the third test that compares the priv set to Full Access, duh!