Locking Fields in a Tapform

[Emily Noble]

How do I lock a field so that others can’t edit it? Also how do I lock a field so that only values from the pick list can be added?

[Brendan]

Hi Emily,

You can lock an entire form so that others can’t edit it. But not a specific field.

The only way right now to prevent someone from editing the value of a text field with a pick list is to use a multi-select pick list. That’s on the iOS versions. The Mac version will still let you edit values even in a field that has a multi-select pick list attached to it.

Thanks,

Brendan

[Brendan]

Let me clarify the locking field issue. You can encrypt a specific field in a form. When you do that, Tap Forms will ask for your encryption key whenever you attempt to access any form which has at least 1 encrypted field.

Perhaps if you could tell me how you are intending to use Tap Forms I would be able to give you more precise answers.

Thanks!

Brendan

[Alan_ds]

I too have a need to lock a field to protect it from inadvertent change.

I have a password field which I toggle to masked, but the blocked-out dots can still be inadvertently edited.

Is there a way to confirm a change before it is made permanent?

Alan

[Brendan]

Hi Alan,

No, I’m sorry but there isn’t on the iPad. On the iPhone version you have to tap the field, then edit the value, then tap Save. If you tap the back button, it won’t save. But on the iPad version, just dismissing the keyboard will make it save. However, if you had to confirm every field that you enter and then leave if you make a change, I think it would slow you way down when entering data.

Thanks,

Brendan

[Frances Cherman]

I would like to be able to lock individual fields after entering values to prevent the values from being inadvertently edited. When I’m working in the Table view, it’s almost too easy to accidentally rest my cursor on a cell I don’t mean to edit and then accidentally hit the delete key. Is there any way to lock individual fields on selected records?

[Brendan]

There’s no function for that. Sorry.

[Frances Cherman]

Thanks for responding.

[richard maliszewski]

So I have a form I do not want edited directly. Some fields are updated based on calculations performed upon other forms by the form in question’s script.

I enabled access controls for the form, setting a password, yada, yada. Turned everything off, basically locking the form. Two questions/issues:

1) having done this, does this mean calcuations also cannot update fields, or does it just prevent direct entry?

2) having done this, I tried changing a non-calculated field in the form. TF did not stop me. Switched to another form, switched back, changed field was still changed. This suggests to me that locking the form did nothing useful. The name of this field is used for access to compnaion forms…I’d rather it didn’t just succumb to accidental entry. Am I missing something?

–Richard

[Brendan]

1. It just prevents editing. A calculation field can still be updated. Tap Forms doesn’t check the access controls at that level.

2. Did you have the access controls locked? At the bottom of the form inspector panel there’s a lock button that says “click the lock to prevent changes”. If it’s locked, you should be prevented from directly making changes.

[richard maliszewski]

With the lock set, I am able to modify a text field to my heart’s content. I was hoping for #1 to be as you say, #2 as well. But appears not. The DB is backed-up/linked via CouchDB. I just confirmed that the change I shouldn’t be able to make propagated across to a second device.

–Richard

[Brendan]

Hmm… that’s odd. I did test that out before I responded just to be sure, but perhaps I missed something. Are you saying that with the access controls locked and the Update Records option turned OFF, you’re still able to edit records? In any view?

[richard maliszewski]

Certainly in the multi-column view. Just verified I can do the same in the default layout. Is this perhaps because I am using CouchDB as backing store?

FWIW, I have worked past the issue (for me) by making the visible “name” field a calculation (concat) from the actual name field, which I have hidden. Since it’s a result, it’s immune to direct entry, and the thing I hope not to change by accident is safely out of view. At this point, I actually have the envelopes system pretty much working. The only nice-to-add thing would be preventing an edit to one end of an envelope transfer getting made without a companion change to the other end. Transaction commits record the “parent” record ID in both children, and the children IDs in the parent. If this was something I was going to inflict on a larger user base, I might try to get that done. But for our home use as a replacement for Mvelopes, it’s already a lot cleaner and works better for our use cases.

Thanks for your responses.

–Richard

[Brendan]

The sync service would have no bearing on this.

Would you be able to email me your form template so I can test it out? Just send the parent form and it’ll include the child form too.

[richard maliszewski]

There’s nothing sensitive in the crash-test-dummy version…and there’s no DB parent-child relationship, so I’m attaching the template for a form that just exhibited the locked-ain’t-locked behavior.

–Richard

Attachments:

You must be logged in to view attached files.

[Author]

Posts