Locking: add ability to lock deleting rows (while being able to edit existing cells)

There’s a separate option to lock adding rows, but for some reason there is no option to prevent deleting rows and still be able to edit existing rows. The “Change table values” toggle locks both editing and deleting.

Need to be able to lock the section so that displayed cells can be edited, but nothing can be added or deleted.

Example:
I want to be able to change values in the “control” table and edit the snapshot name, but prevent users from deleting rows from the report (which are globally reused):

6 Likes

Yeah, this would be a very helpful addition to locking. I also use locking for our HR functions, and want people to edit but not delete rows

1 Like

I’ve added this to our tracker!

4 Likes

The current way things are working was a conscious decision so I’m not sure we’ll be changing it soon. The idea is that if a user can add/edit rows, they can also delete the rows they’ve added. They cannot delete rows others have added.

If you’re seeing a different behavior here, please report back and let us know.

Also, if there are use-cases you have in mind that we can research more where not allowing any deleting of rows is beneficial, it would be good to have that conversation here.

The reasons for blocking row delete:

  1. You have assigned some important tasks to your teammates. They can only mark the task as completed or dropped. If they delete the task, you have no idea which task was deleted.

  2. Some users are not good at computer or mobile app and they only fill in simple data but not deleting the row.

  3. A helper table to house a lot of complex formula and button which should not be put inside the data table. The row in helper table should not be deleted.

I would like to have the locking option for delete row. It only hide the delete button in right click or menu but you can still use a button to delete the row if you really want. At least you can use a button with “disable if” to have more control on what should be deleted.

3 Likes

I second what @David_Chung says, here.

In my opinion, the best approach would be to have standard permissions at object level (none, read, write, execute, delete).
Ideally up to the row granularity, but also at table level would work.

  • None: object not visible/accessible
  • Read(-only): allow to see data
  • Write: allow to change data
  • Execute: allow to manually trigger actions (i.e. buttons)
  • Delete: remove data.

It’s nothing new and - for this reason - more intuitive.

Also, from a UX perspective, it would be helpful to see the Current User’s (and eventually groups) permissions on the object itself (colour, pop-up letter, info box, etc).

I’m sure it’s far from being an easy implementation, but it’s a good way (the only one?) to have very consistent document authorisation setting.

2 Likes

Hi @BenLee,

I would like to add some images for elaboration. In locking setting, add the “Delete row” option.

The option only hide the “Delete row everywhere”. It should be relatively easy to implement. User can still use “DeleteRows()” to delete it with a button.



1 Like

I just tested this - a user can delete rows added by another user for a table in a locked page with the following settings:
Interact only

  • Use buttons and controls: On
  • Change table values: On
    <all other options under “Interact only” are Off>

Hi @Patricia_Liu,

Yes, that’s expected behavior. If you only want people to be able to edit and delete their own rows, you can use:

  • Use buttons and controls: ON
  • Change table values: OFF
  • Add rows?: ON

Add rows will allow people to add/edit/delete only their own rows, where Change table values allows this editing for any row.

Thank you for the clarification! I tested this to understand the behavior.