Extended Privileges are used by Privilege Sets, so no to specific users/accounts.
I've often needed this feature, too (multiple "sets" for an Account), so that certain tasks can be used with the "main" set.
I don't know if EA would help here. Likely it would be to duplicate the sets needed ('Worker' & 'Project Managers') and add the ability to approve the PO's. Then assign to the Accounts as needed.
Worker ==> Worker_plus_PO
PM ==> PM_plus_PO
That's what I'm currently having to do, but to me it seems so inefficient. If you look at any other permissions models ( e.g POSIX, ACL's etc), a key part is being able to ALLOW or DENY to any combination of Users or Groups, which gives sufficient granularity to cover pretty much any case.
I might raise a Product Idea for this...
I'm on your side, James!
are there IDEA(s) on this? if not would you create one (and vote on it)? post the link here...
1 of 1 people found this helpful
James Glendinning wrote:
Is there a way to apply Extended Privileges to a specific user, as opposed to an entire Privilege Set? I thought this would be an obvious thing to allow...
I really don't want to go down the route of hardcoding account names into scripts.
The only other way I can think to do this is to store some sort of boolean logic against a table of 'Users' which correlate to Filemaker Accounts, but that seems to be wandering outside of the in-house security tools provided by Filemaker.
That's pretty much the way to do it. Set up a table of users, then have a set of data points that the user may or may not have, e.g., "may print", "may approve PO", etc. On login, move these privileges into a global field so that it is universally accessible. Your scripts do have to test the field but it's a stable point of reference. Your scripts look like this,
if ( preference::user_may_approve_PO )
The alternative is to set up a privilege set, as you want it, then duplicate it and add the extended privilege set to that. Then keep those two sets in synch. Using extended privileges isn't a magic bullet. You'll still have to test for the presence of the extended privilege and fork the code.
James Glendinning wrote:
But some functions need to be performed by specific users who are not all in the same Priv Set, for example a single 'Worker', and only two of the 'Project Managers' need to be the only ones who can approve PO's, but no-one else. Surely creating an Extended Privilege and applying it to these specific users would be the way to go? How else would one achieve this without having to create a specific Privilege Set for these 3 people?
What you are missing here is that the "worker who can approve POs" is not a "worker". Those two things are two different roles and each should have their own priv set.
What you're saying is true, but it seems to require the need to build a permissions model from scratch, which is a bit of a pain. I'll have to do it this time, but I've added a Product Idea to get this stuff built in at some point...
Hi Wim, I get what you're saying, but that means I have to create a PrivSet for every possible permutation of access control across the system. It just seems cumbersome, especially when dealing with 'edge cases' of permissions.
Yes and no.
Yes: edge cases are always tough and that extra granularity would be very useful.
No: you wouldn't need a priv set for every single permutation
As a "thought point", keeping the "roles" angle in mind can be a trigger to scrutinize what people can do and seeing of all those permutations really can't be reduced to distinct roles and reduce the perceived complexity. In my experience these things start off as looking very complex but in a few iterations of looking at all the actions and the roles, sometimes some simplicity can be found.
it's exactly what I said in the first reply.
do not go down the 'ersatz' security road. Security by obscurity is not going to make any of us sleep well at night.
Privilege sets are (and always have been) what can be done by a group (of one or many). Accounts are assigned to the set.
I can wish (until the cows come home or pigs fly) for a little more flexibility such as you need. But I don't side-step what must be as it is now.
You could have a centralized script that returns a result of 1 or 0 based a list of Get ( AccountName )s. Call that script at the top of your privileged scripts to see if the user can proceed.
The fact that scripts can be called from many files as opposed to extended priv sets that are file specific earns this technique a place in the tool box.