This bug has been around for a really long time now. It would be nice to finally have it fixed. You can even modify these value lists using a "Guest" read-only account...
I discovered that while I was testing to see if the problem was verifiable. Why should a user with read-only privileges be able to alter value lists?
A guest with read-only privileges is able to replace or alter values, essentially corrupting the input options available for data entry users. They aren't able to use the value list to enter data but they are able to modify the value list in any way they like.
Thank you for the post.
I am able to replicate on both the Mac and Windows operating system with FileMaker Pro 13.0v3 (Advanced).
Additionally, I forwarded a report to Testing and Development for review.
An entry in the Known Bugs List has been linked to this Issue Report. Any Comments/Questions/Suggested Corrections should be posted here or in a new thread. Please do not post such comments to the Known Bugs List thread.
Testing has posted that the privilege setting "Value Lists: All view only" is only about creating/modifying the definition of value lists. The Inspector option about editing value list content is not about changing schema definitions, so it is not covered by that privilege.
Our Documentation department has now been notified so this information can be included and/or made clearer in future documentation.
I must respectfully disagree with your testing department. The "Edit.." option most definitely modifies the definition of a custom values value list. It exactly duplicates the action of using Manage | value lists to open the definition of a custom values value list and changing the values listed in that value list definition.
Sounds like your best work around at this time if you plan on sticking with a custom values value list is to direct limited access users to copies of your layout that do not use value lists with this option set in the inspector. Either that or in FileMaker 13, layer two copies of the same field on top of each other, one with the Edit option specified and one without and use the "Hide Object When" property for each to control which copy of this field is visible for a given user...
What is a Value List? How do you define a value list?
Is it simply the id and the name label? Or is it is values which comprise the list?
In some cases the content is dynamic and depends on the values entered into a field. If a user has rights to enter data in that field, they will modify the value list. If a value list is derived from data sources we have plenty of options for securing the data. We have field level locking, record level locking, table level locking and we have layout level locking. Any or all of these can be used in combination to secure the data using privilege settings. In addition, we have field validation options. We may provide strict validation rules for the fields being used to deliver data into value lists. It must be a number , it may not be empty, it must be unique, etc.
However, in the case of a value list that uses custom values, the values entered into the custom value area are fixed. They are entered by the developer/authorised person. Why should any user have rights to modify custom values?
Obviously, we can easily imagine situations where one set of users should have the rights and the ability to modify custom value lists while another set of users should not have those rights. In this case we need to be able to provide the editing rights to only one set of users and there should be some means of protecting the value list from the other set of users. Do we mean protect the value list id and the value list name from being edited or deleted? Or do we mean protect the values which comprise the value list and which are entered in the custom value dialog box?
In the case of custom values, if the values cannot be protected in Privilege Settings, then there is no protection for them anywhere within the security mechanisms that FileMaker provides. This is an extremely unusual exception and it would warrant clear description, no?
The documentation in "About protecting databases" http://www.filemaker.com/help/13/fmp/en/html/passwords.14.2.html suggests that we can use privilege sets to secure values in value lists.About protecting databasesYou can limit what users can see and do in a FileMaker Pro file. You can restrict:Access to value lists and scripts. Prevent users from accessing and modifying value lists and scripts, and from running scripts.The documentation in "Editing value list privileges" http://www.filemaker.com/help/13/fmp/en/html/passwords.14.22.htm says that view-only privileges prevent users from modifying values.To set privileges for all value lists in the file, for Value Lists, choose All modifiable, All view only, or All no access. These options allow or prohibit the following:
"All view only allows viewing of existing value lists only" seems like a fairly clear statement. There is no rider that says "except for the power to manage any custom value list." I would expect the view-only privilege would also extend to the dialog box which is displayed when using "edit values" on a field formatted with a custom value list. Otherwise, it feels very much like "viewing existing value lists only" really does not mean what it says.In the same document, in notes, it says:To make a value list modifiable for users with the appropriate privileges, you must format the field object with the options that permit adding new value list items or editing existing value list items (or both).I would emphasise "make a value list modifiable for users with the appropriate privileges." If we allow that the Development and Testing team are correct then we have the counter-intuitive situation where a value list is modifiable for users with "view-only" privileges. This brings us back the question of how we can protect the values. We also have to wonder why the only way in which custom values of a value list are able to be afforded protection is by using the no-access privilege.A much more serious problem flows on from this. The Read-Only privilege set is defined within every new file created. In my reading of the documents today I have not seen any clear description of the rights provided to view-only users to edit and destroy values in custom values lists. I have not found anything that contradicts it but that is not the same thing. An omission is not the same as an admission. This is undocumented behaviour.Development and testing are saying that the power to destroy data stored in custom value lists is normal and expected behaviour for users who have view-only privileges. Are there any other situations in which users with view-only privileges are able to make changes. Can development and testing tell us other situations where we may normally expect users with view-only privileges to modify records, layouts, value lists or scripts?Similarly, are there any other layout level controls which are able to over-ride privilege settings?
- All modifiable allows viewing and modifying value lists, duplicating and deleting value lists, and creating new value lists.
- All view only allows viewing of existing value lists only. Prohibits opening the Manage Value Lists dialog box in order to create or edit value lists.