Jump to content

Get(PrivilegeSetName) from the Accounts and privileges


Homer

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

Recommended Posts

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 by Guest
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 !

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 months later...

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 ?

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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