Row Lock and Unlock, and Authorization Feature

[atanghoneycomb]

As I have mentioned in previous questions, I have been trying to finish my cash-out app. After some discussion with the operation manager, I realized that a row lock-and-unlock and an accompanying authorization feature is necessary for this app to be adopted.

In other words, after a cash-out check has been entered and confirmed, we don’t want the shift-leaders to change them anymore, and it could involve one row or several rows depending on the cash split. In addition, we would like to give authorization to the managers and me, the accountant, to unlock the locked rows to make changes under special circumstances.

Could you please help me achieve this? After both functions are realized in the app our company will officially start using Appsheet and start paying for at least 20 users.

Thanks in advance!

[MultiTech]

There’s a few different ways you could accomplish this; my main question is this:

• Is it necessary to keep a record of any modifications, and who made them?
• Or are you okay with just allowing people to go in and change things from what the original values where - and those original values being lost to the Ether?

[atanghoneycomb]

Of course it is better to have records of modifications.

[MultiTech]

Well, depending on how much of a paper trail you wish to keep, that determines how to go about things.

I wish to keep record of every modification made

To go this route, you’ll need:

• A sub-table to hold all the modification records
• A virtual column inside the cash-out record that uses MAXROW() to find the newest modification record
• You’ll also want to configure the cash-out record with another virtual column to serve as the final output (the display field) for the cash-out value. This has an IF statement that’s watching the MAXROW() virtual column, and if there IS something there (meaning a modification has been made) then this field takes the new value and displays it - otherwise it uses whatever original value was entered in the cash-out record.

I don’t need that much detail, but maybe just one space for modification that way we can keep the original and still be able to modify it.

This is simpler, all you need is:

• A few extra columns (one to hold the modification, a ChangeTimestamp that’s watching the modification column, and I would throw in two columns to capture emails (one that uses an initial value (to capture who creates the record), and another that uses an AppFormula (so it updates to whoever last updated the record)).
• Maybe add in another virtual column that’s similar to the IF() I talked about above (to provide a singular display field showing the cost)

[OptimiX_XcrY]

Would a conditional show of the Edit button work to “lock” a row? This way, other in app actions can still be used

[MultiTech]

Yes, putting a condition on the edit action of a record will make it conditionally editable.

You might check out the following post; it’s extremely helpful with customizing your apps.

Current_User (Slice) - How to conform your app around WHO is using the app Tips & Tricks 💡

One of the core basic functions, included in just about EVERY app I make, is the ability for the app to know WHO is using the app. If the app knows who’s using it, then I can easily control many different aspects of the app: Add/edit/delete permissions How data should be filtered What views are shown What buttons, or Actions, are visible Which workflows should fire off Which columns should be shown or editable etc. Requirements To accomplish this functionality in your app, you need the follo…