Make fields read only

[Scott Pon]

We have a database that is our sales orders database. One of the fields is "Closed Date" Is it possible to make the layout locked or read only when the closed date is filled in? this way the record can't be edited. (I'll handle editing it with a closed date at another time).

Any thoughts or suggestions?

[dsghs]

You can set the entry settings for the field in the inspector window. Just uncheck allow edit in browser mode.

[LaRetta]

Hi Scott, :-)

The only reliable method is to use security and add calculation in the privilege set to Boolean true aka 1, something like:

IsEmpty ( table::CloseDate )

... or even

not table::CloseDate

... which means they can edit the record until a date is entered in CloseDate.

[Deepak Kumar]

Hi scott,

when the closeddate field is filled then, just use commit records in script. It will lock the records.

[Scott Pon]

Thanks for your feed back. I"m going to try these and see what comes out the best.

[Scott Pon]

You can set the entry settings for the field in the inspector window. Just uncheck allow edit in browser mode.

That will not work. The screen needs to be editable for records that aren't closed.

[bcooney]

To add a bit to this. I would use LaRetta's RLA rule and create a duplicate layout that the user sees when the Sales Order is closed (use nav scripts or layout triggers). Remove all unnecessary functionality on this layout. Add an "Unlock for Edit" button that allows an admin priv set to nav to the unlocked layout and clears the Close Date.

Also, script the close. Write an activity or set a timestamp, modifier account in fields that document the close.

[Scott Pon]

Hi Scott, :-)

The only reliable method is to use security and add calculation in the privilege set to Boolean true aka 1, something like:

IsEmpty ( table::CloseDate )

... or even

not table::CloseDate

... which means they can edit the record until a date is entered in CloseDate.

So this is what I did (in a test file):

As admin I went into Manage->Security

I created a privilege set "Lock if Closed"

Under Data Access and Design, Records set to "Custom Priveliges"

I changed Edit to "Limited..." which caused a "Specify Calculation" box to appear.

I put "IsEmpty ( Closed Date )" clicked ok

I assigned User A to "Lock if Closed"

went back to my layout. As admin, I am able to edit the record.

I close the file and re-open, and log on as User A.

When the field "Closed Date" has a date, I can not edit the record. Error Msg "Your access privileges do not allow you to perform this action"

I have to log in as admin and clear the Closed Date. then User A can edit the record again.

Does this sound correct? Any thing else I should be worried about if I do this?

bcooney, is this what you are also suggesting? (aside from the last timestamp suggestion)

[LaRetta]

create a duplicate layout that the user sees when the Sales Order is closed (use nav scripts or layout triggers). Remove all unnecessary functionality on this layout. Add an "Unlock for Edit" button that allows an admin priv set to nav to the unlocked layout and clears the Close Date.

Also, script the close. Write an activity or set a timestamp, modifier account in fields that document the close.

Not sure this is necessary. Why create a duplicate layout which would not then require duplicate changes if changes are made to the other layout particularly when the record can't be changed anyway? I would prefer conditional formatting a text object on the layout with 24 pt font saying CLOSED. If User continues to try and modify the record, they'll be stopped. Unlocking the record so Admin can modify it might not also dictate clearing the Close Date ... that would be a business decision on what 'closed' represents.

But yes Scott, that should do it. :^)

[bcooney]

bcooney, is this what you are also suggesting? (aside from the last timestamp suggestion)

Not really. Think of privilege sets as groups of users that should have similar editing/viewing abilities. You've correctly created the privilege set, but your name for the priv set seems very narrow. If you come up with another restriction for this group of users, what are you going to do? Each account can only be assigned to one privilege set, but each privilege set can have distinct rules for each table.

So, I suggest that you rename your priv set to something like "Sales Staff."

LaRetta and I differ in philosophies on the use of "locked layouts." True, maintaining a locked layout may increase your development time, but to me it is the cleanest interface for a user.

As for how to "unlock" the record. Well, how that happens and what happens when it happens, as LaRetta says, is dictated by the business.

This might also help: http://www.nightwing.com.au/FileMaker/demosX/demoX07.html

[LaRetta]

Hi Barbara,

But this isn't an issue where the User does not have rights to SEE certain records or field values ... only not CHANGE any record values once closed which can be clearly indicated to the User on the layout. They will not be seeing <no access> .

So if you really feel another layout would be warranted in this instance then I guess we DO disagree on this one. And that's okay too. :-)

[bcooney]

Yes, LaRetta, in this case, even with view privs, I still create a locked layout.

[comment]

Barbara, can you explain what exactly would be the difference between the two layouts? You said "remove all unnecessary functionality on this layout" - but the only difference AFAICS is in the permissions, which are not layout-dependent.

[bcooney]

OK. Typically, on a form view, I have a tab panel of portals that have an Add button to create a new child record and a delete button on each portal row. It is easier for me, imho is less confusing to the user, and saves dev time, to duplicate the layout and remove these buttons, than to modify each script with validations. I also remove any browse mode edit capability from any fields within the portal (such as a Qty in an InvLineItem). Yes, I use RLA. I don't like the default "your access privs don't allow" dialog..and if I could suppress it, and write an alternative, I would.

[comment]

I see. I am not sure that adding an exception to the script/s and some conditional formatting to the buttons is more work than maintaining two layouts - but that may well be a personal preference. I do think that denying entry to the fields is too harsh - why shouldn't the user be allowed to copy from them?

[bcooney]

There would be no need to copy field data. It's never been an issue.

I really don't believe that there's a right answer. I think it depends very much on the interface and what native FM dialogs and alerts you're willing to accept.

Hey, I'm one of those that hide/lock status, build find screens, and for the most part script any native functionality. That may change with FM12...haven't done anything substantial with it yet.

[comment]

I really don't believe that there's a right answer.

Well, not one that would fit all, that's for sure.

[bruceR]

Can you just use the layout script trigger for on record commit?

Using script triggers is not the most robust security method.

But might it e "good enough" for you and your users?

Your call.

If ( yourLockCalc)

Revert Record [No dialog]

Exit Script [ false]

Else

Exit script [true]

End if

EditControl.fp7.zip

[LaRetta]

Hey, I'm one of those that hide/lock status, build find screens, and for the most part script any native functionality.

.... which is standard practice by any descent decent developer and hardly something which communicates your intent of the message which appears to be that you are very safe with your designs which is a good thing and I would never question that about you, Barbara. :-)

And I too believe the User experience is most important and is worth the extra development time IF it is worth it. Would you sum it up then that the only reason you duplicate a layout is to provide a nicer message to the User? And it takes (in addition to privilege set):

1. A duplicate layout

2. Remove buttons, change (potentially) to different custom menu

3. Turn off entry to every field and portal and attach script trigger.

4. Remember to duplicate every change you make onto both layouts and, not only duplicate the changes but make sure its location is exact to the px so Users don't see a jidder when they change layouts ... and if one is form view and the other is list, remembering to off-set pasting your objects by 3 px to account for list view record indicator.

Using single layout method will use conditional format CLOSED in red (or even nice message Record closed. Modification prohibited and let security message enforce with "you do not have access" if they still try, whereas you tell them nicely in a message, "Sorry but the record is Closed." Your approach (although it took some work to set up) sounds good ... the user is IMPORTANT to us ... but there is usually more than one layout where Users can data-enter for any given table and/or security restriction and you will need to perform items 1 - 4 above on each of them. If you do not protect them all then User will get the dreaded 'you do not have rights' anyway.

If a system response might be unexpected or unclear in the current layout-specific user interaction (particularly with User FIELD interaction) you can bet I provide my own messages and neither am I opposed to duplicating layouts and I have done so when it seems the only logical choice but I still see no true benefit (in this instance) when it prohibits additional functionalities such as scrolling and pasting and requires so much more resource and developer time to implement and maintain.

Regardless, it is good that you spoke up so folks have options. I've learned a lot from you over the years and hopefully many more to come! :-)

Edited October 5, 2012 by LaRetta

[LaRetta]

Hi Scott,

I neglected to reinforce what Barbara had mentioned about providing a way out. This protection should apply to all accounts unless they are forced to go through a process to unlock it (and hopefully strong hints to lock it again, from their dashboard, TTD, refuse to let them leave etc). None of us knows your business rules so we can't describe more specifically what is best but when you do it, back up first, LOL. Maybe you require they go to Manager (secured) layout and click a button which 'checks' an Override field for 1 and allows editing of the record OR only allows removal of the Close Date.

Hi Bruce! Glad you are joining!

Words like Closed and Posted (when used in business software) shouts of 'closing month-end' financials, posting GL, inventory, payroll, quarterly taxes, sales commissions, paying invoices ... all things which need to be forever frozen in business (only opened in extreme emergency by authority). It is probably because of my prior life deep in those trenches, LOL. Alternates are always good. I'll check your file when back at a box. :^)

[Scott Pon]

Thanks everyone.  I was able to implement this using security.  Just one additional question.   can i show a custom message? right now it says "Your access privileges do not allow you to perform this action"

 

I'd like to say something like "This order has been completed. You can no longer edit this order."

[LaRetta]

Hi Scott,

 

Well the reason for my suggestion of text object with the phrase is so you wouldn't have to attach a trigger to every field - that Users would simply see the message on the top of those records, LOL, but if you wish, I would suggest a script trigger OnObjectKeystroke with:

 

Nope, I removed my suggestion because I just looked at Bruce's file and I see now that Bruce uses layout script trigger.  That is very good!  Scott I suggest you use the method Bruce shows because it only needs to be applied to the layout itself ... (Layouts > Layout Setup > Script Triggers). 

 

Thanks for showing this Bruce! :^)

Edited December 19, 2012 by LaRetta

[LaRetta]

Hey Bruce,

 

Your approach using layout-level trigger and Revert is really great but I wondered about the timing, ie, it would need to fire before the commit (which OnRecordCommit does) but also before security so I tested by adding privileges to your file which restricts to edit 'limited' and not CloseDate (revised fp7 file attached) and OnRecordCommit doesn't suppress the security message.  Of course you created the file on assumption of using it in place of that security so the file is still great to use in many places but for Scott, we need to adjust it, I think.

 

It seems that OnLayoutKeystroke DOES work which was why I originally reached for OnObjectKeystroke; my sense being that keystroke would fire before modification or attempt at modification and before security squawked but still allow copy of field data.  It would also be better (in this specific case for Scott) to test security rather than the closed date.  Usually with permissions, I test for a Privilege Set and this is the first time I have attempted to capture a security error using Get(LastError) and I was quite shocked that it did not produce Error #9 (insufficient privileges)!

 

ADDED:  I just mean that not throwing an error is an unexpected behavior to me!  Also added red.

 

Hi Scott,

 

So if basing the trigger on CloseDate, management would need to go to another layout if they want to change something which is probably fine since the message is cosmetic and true protection lies with back-end security.  Also, I would assume in works the same on your Windows 7 machine as my XP but I wouldn't guarantee it without testing; same with Mac.  And maybe we can still tweak it further by including test for security; that would be cool if we could.  Hopefully Bruce or Michael or others have input on the best approach.  It sure beats adding trigger to every field! 

 

Also note that OnLayoutKeyStroke would also prohibit typing into global fields so it might be a bit tighter than you want.

EditControlREV.zip

Edited December 20, 2012 by LaRetta

[comment]

I am not sure where this stands at the moment, but...

 

Speaking as a user, the "Revert on Commit" is a terrible UI. It lets you spend any amount of time and effort editing the record, only to say at the end "Sorry, blah, blah..." and flush your work down the tubes.

 

Speaking as a user again, I suggest developers do what they are paid for - that is develop. If it takes adding a script trigger to every field, then that's what it takes. User's convenience takes precedence over developer's convenience - that, IMHO, is the essence of the job.

 

 

 

---

EDIT:

That said, OnLayoutKeystroke could well be a decent compromise...

 

EDIT2:

Oops, forgot about cutting and pasting. Not a good idea, after all.

Edited December 20, 2012 by comment

[LaRetta]

I appreciate the perspective! I don't mind doing whatever work is necessary but you teach 'simple' as well and for good reason; far simpler to administer a single layout trigger than to remember to add a trigger any time you add a new field onto the layout.

However I didn't consider paste - nice catch. Of course this is just to be nice ... Security would still *protect from modification, right? If security fails on cut/paste then we have bigger issues anyway. If User got the security message at that point then they deserved it, LOL.

* assumption not yet tested due to being on iPad right now. :-)

ADDED I agree that letting User type only to remove it is not good idea. Using keystroke triggers fire before they type.

Edited December 20, 2012 by LaRetta

[comment]

Hmmm... perhaps I will change my mind again. It turns out that when you deny edit privileges, users cannot cut or paste either.

 

OTOH, they don't even get an error message when they try - it just doesn't happen, and you don't know why. I don't think that's how it should behave.

[LaRetta]

No error message on paste here either, even without the layout trigger and reproduced in 12.0v3. I consider this unexpected and certainly unwanted behavior. When I've the chance I'll test back through versions. I suppose if it has never thrown a security message on illegal paste then it (probably) is not considered a bug although we've seen some slip through 4 or 5 versions before.

CTRL-L (to drop into layout mode) for an unauthorized User does not produce security message either but paste hits the data layer so probably not fair comparison to layout action. BTW, do you know why an error isn't thrown? It would be great to know simply if security is rearing up or has reared up during a scripted process.

[comment]

BTW, do you know why an error isn't thrown?

 

I have a guess: Paste doesn't throw an error message, because it doesn't happen. It doesn't happen, because it's disabled (take a look at the available menu commands, and you'll see that all Edit commands other than Copy are greyed out). So while a keystroke attempts to modify the field and gets shot down by the security setting, paste is - literally - a non-event and gets no response.

Edited December 20, 2012 by comment

[LaRetta]

Good information to add pieces to the picture, thank you Michael. So, although attempting to bypass security can produce the security message (or not in cases such as paste), no error is ever thrown (in data viewer) because security stops the action before it can happen. And this is same whether using paste or typing directly into field ... security message itself does not mean an error.

I guess I'm left wondering why Error 9 exists if not for script to test. What if running script behind the scenes and security message appears? How can we protect? This feels like potential issue and/or hole in my understanding. I envision a security dialog hanging a server-side script, for instance with nobody there to OK the dialog or trap what went wrong. Of course script should be ran with full access but I'm just speculating. I suppose instead I'll focus on testing to find out. :^)

[comment]

I am sorry - I haven't noticed the distinction you made between between a "security message" and an error. i have edited my previous post to clarify I meant an error message. I am not sure in what context one should test if an actual error (with a specific error number) is generated.