Data Editor Lock

Feature Requests
1

As a Glide developer, I want the ability to lock the Data Editor to prevent accidental loss of data.

  • The Data Editor can be locked at two levels:
    – via a global setting that locks all tables at once
    – at an individual table level
  • when a table is locked, it means the table is in a read-only mode in the data editor. That is, all adds, edits & deletes are prohibited.
  • locking a table does not impact the functionality of the App, nor does it have any effect on the functionality of the Layout Editor. Only the Data Editor is affected.
  • when a global lock is in place, individual tables may be unlocked for a short period via the table context menu. ie. “Unlock for 5 minutes”
  • when a table is locked, there will be a visual indicator (“padlock” emoji) next to the table name.
  • locking a table does not prevent adding/editing/deleting columns. It only prevents the changing of data.
8 Likes
2

100% agree. It would be shockingly easy to accidentally delete critical data or even a whole table. After we’ve spent countless hours in development, mistakes should not be that easy.

1 Like
3

Just for clarification, this would mean that adds, edits and deletes would be prohibited from inside the builder (of course) but not from the live app in production, correct?

Out of curiosity, where did the idea come from, did something bad happen?

(As an aside, it’s one of the reasons I do two duplicates of projects – one with data sync, one with data async – just before I work on a project. The backups reassure me.)

4

Yes, correct.

To be honest, I don’t recall. But I probably did something stupid (or at least almost did).

1 Like
5

+1 (+10000 actually) on this, or at the very least an undo for accidental cell overwriting!! :sob:

1 Like
6

Mistakes from inside a Glide project are difficult to avoid, so I assume they will happen. Eventually. And as per Murphy’s law, I expect the mistake to happen precisely when I need it to happen the least.

So, my approach: I make two backups of the project (data sync and data async) before each major feature development. I name the backups clearly with date and time, with “sync" or “async".

Every once in a while I delete old backups I won’t need anymore. But I always keep the last few. In theory I would only need the latest.

This approach had served me well and even “saved" me once or twice. And conversely, once or twice I have been complacent and didn’t do the backup as I should have (or forgot), and this came back to bite me later on.

1 Like