An in what table is that drop down field defined?
Do you find that, when locked, you can't change existing records, but can still add new records in the portal?
The drop down fields are in a value list not the database. Yes, I still allow new record creation and deletion which works fine. The only custom privilege set I have is on the Edit set.
The drop down fields are in a value list not the database.
This is not possible in FileMaker. All fields are defined in a table otherwise they do not exist. They are either defined in personnel_signin or some other table in your database.
Yes, I still allow new record creation and deletion which works fine.
But that isn't the question that I asked. What I was asking is to get a clearer picture as to WHEN values can and cannot be selected in the drop down list. If the drop down list field is defined in personnel_signin, your lock expression should prevent modifying existing records, but it, by iteself, will not necessarily prevent adding a new record in the table--which may require additional settings.
But that may not be what you are reporting here so I am asking for clarification.
ahh.. I misunderstood your question..
Yes, all the drop down fields are defined in the same personnel_signin table. - This is a portal on the layout.
I am assuming since the fields are all in the same Table they should not be able to be modified if the criteria is met. Permitting I have the criteria and everything setup correctly.
Preventing adding a new record is no needed in the case, just preventing a record from being changed once the container field is signed. (Not Empty)
Since it is in a portal do I need to do anything to different?
What happens if you temporarily change the "lock expression" to be just: IsEmpty ( Signature ) ?
I'm guessing that the relationship link to JSA_Form is not valid in this context and thus a reference to it may always be returning 0.
And it may just be that you need to change the OR operator to AND, but I'm not sure how the lock field in the related field is intended to work here.
actually the Islocked = 1 always seems to always work, but the IsEmpty (Signature) is the one that seems to be not working.
actually the Islocked = 1 always seems to always work,
I doubt that it will keep the user from creating a new record.... We set invoices up so that when their status is "printed" normal access level users can't edit the record, but the same lock on the related line items doesn't prevent a user from adding a new line item, I had to take additional steps to prevent that.
Don't see why IsEmpty ( containerField ) won't work, but as a test, define a calculation field with:
As its only term and with Text specified as the result type. Try using IsEmpty with it and see if you get any change in behavior.
"I doubt that it will keep the user from creating a new record...."
- I don't need to stop them from creating new records and I don't have this in any security setting... I am only looking to keep them from modifing the records once signed or locked.. that's it..
Sorry, forgot that you had said that earlier. Then try the test I suggested and see what happens.
Also, after inserting a signature, make sure that the records are committed immediately after. You can temporarily test this by clicking or tapping a blank area of the layout. Then see if your original lock expression works.
No problem... I took out the other calc and only left the IsEmpty (Signature)
Still no go... Do you think it may be a portal issue? Do I need to use a "self" somewhere? To identify each portal row?
It was time and past time to see if I can replicate this and I cannot replicate this behavior.
Compare your file to this demo: https://dl.dropboxusercontent.com/u/78737945/ContainerControlledRLA.fmp12
Open it with Admin and no password to open it in full access. Open it with account: test, password: test to open with a password where the record with an image in in the container field cannot be edited.