Signed in with the wrong privilege set?
First idea would be to refrain from putting entire question into the title of any future questions that you might ask.
Second would be as previously suggested, double check the privilege set name of the current user when it "doesn't work".
Get ( AccountPrivilegeSetName ), either as a watch expression or in an unstored calculation field can tell you the current user's privilege set.
Third idea would be to tell us exactly HOW it doesn't work. Just as you wouldn't take your car to the Mechanic and tell him "it doesn't work" as your only info about the car, it helps us to help you to know exactly what is happening when the system fails to work as expected.
Another thing to beware of, is a script with "Run with Full Access" turned on, will override any user-restrictions you have applied. So make sure the change to that field isn't scripted (with that option turned on) rather than a user manually changing it.
Tech Info 7161 (https://thefmkb.com/7161) or (https://support.filemaker.com/s/answerview?anum=000023754&language=en_US in the new system) talks about some appropriate tests and some inappropriate ones. I would recommend a review of that Tech Info Note. Note particularly the link to Tech Info 6996 or 000023683 (new system) that talks about functions that resolve differently on server than on the local client in case you might be using such a function.
When you can rule out any bad tests in the privilege set, then we can narrow down other possible causes.
Steven H. Blackwell
Platinum Member Emeritus, FileMaker Business Alliance
Per suggestions on how to elaborate on my question:
Get(username) is used in multiple areas of the database for everything from creating quotes to calculating commissions. Incorrect user names would also be immediately discovered because, of course, user names are associated with a password for access to the data base. (as a side note, when the user name in question did not function properly on the server, I created a new user ID - Test Name with a password of 1111 to insure the User ID was not the issue - it also did not work on the server.)
1) Copy backup from server to capture any modifications that might have been done.
2) On the Local Copy: Copy Privilege set Administrative (Administrative does not have access to 6 layouts or fields specific to employee records).
3) Rename new Privilege set Administrative Level 2
4) Under Security,
> Administrative Level 2,
> Select Records (custom privileges)
> Select Table (in this case, the Header Table)
> Under Set Privileges, Select Field Access
> Select Limited from pull down menu
> Select Field (in this case, auto populated Record Number)
> Select View Only
Ok, ok, ok, Save
5) Enter Accounts and reassign Employee from Administrative to Administrative Level 2 (note from above, when this failed on the server it was tested with a new user ID with no history or assigned Privilege set)
6) Signed out of FileMaker, signed in as employee, tested and it worked perfectly - the user had the same limitations as in the original Administrative Privilege Set with the added limitation of not being able to enter or change the Record Number.
Replicated the above on the Live Data Base and the end user could still enter and change the Record Number. Tested with a new User ID - same thing.
Note: Record Number is not the internal FileMaker generated number; rather, a field auto-populated that access to is required for various purposes by management and can not be locked out globally.
Access is not script driven; therefore, full access is not an issue. This is an extremely simply procedure and seems like it is a no brainer for function.
Incorrect user names would also be immediately discovered because, of course, user names are associated with a password for access to the data base.
This is not the case and is often a source of confusion. User names are set in preferences on the individual client machines. Account names are associated with a password and are created in Manage Security. They are often the same, but this is far from guaranteed as it is very easy to have different account and user names.
FileMaker makes this confusing by entering the user name as the default account name in the password dialog.
I contacted the company hosting our database and requested a reboot of the server; which, required substantial coordination between other companies but, it was done an hour ago. This resolved the issue. I'm a bit suprised but, it is what to is. Thank everyone for their comments, suggestions and time.
Glad it is working for you now.
"Reflect, Repent, Reboot. Order will be restored."
However, this item, as noted by PhilModJunk is not correct:
"user names are associated with a password for access to the data base"
The Account Name, not the User Name, is the one coupled to the password, irrespective of whether the Account is internally authenticated, external authenticated, or oAuth provider authenticated. This is an important distinction.
Retrieving data ...