There’s always the chance that a user might accidentally delete an item from the “link to table” field. We even had a recent issue in Airtable where someone mistakenly removed a client from a contract, leading to errors in our monthly financial report. It took us an hour to figure out what went wrong.
It would be beneficial to have some sort of safeguard against this. Perhaps a confirmation pop-up could appear when someone tries to unlink an element, or maybe unlinking could only be done from the detailed view of a field. Other solutions could work too.
I think that adding one more click just to confirm deletion will in many cases slow down the working process with the database. This is what I like in baserow - potential speed of productivity (minimum steps needed to achieve what I want), easy use, and effectivity.
Btw. if you delete something accidentally in a row, you can immediately use undo (several undo’s are possible too). I know it surely cannot help if you do many more operations after you made a mistake and then you figure out it much later. But working in the database is just data critical, so one has to be careful when working with data. On the other side, I believe that when you accidentally click the cross and delete something, you probably know about it (you see that it disappeared) and you can use the undo button immediately.
Thanks for the feedback, @Alexander. I agree with @marcus on this. I’m afraid adding a confirmation pop-up will make the linking process more complicated.
Nevertheless, I will discuss this request with the team. Perhaps we can find an alternative solution or workaround.
I agree that the two solutions I proposed might result in additional clicks, but perhaps there’s another effective UI/UX approach that could be explored.
Hey @Alexander, we were thinking about displaying this pop-up only if there are many dependencies on the field you are trying to unlink. What do you think?
I’ve recently given this some thought about this topic and came up with ideas which will cover the topic I’ve started but bit deeper.
I propose three approaches to enhance data protection from accidental editing/deleting in Baserow and not decrease speed and comfort:
Locking Rows:
Introduce a feature to lock rows to prevent accidental editing or deletion.
Users can lock|unlock a row or a range of selected rows from the row context menu.
A lock icon or a color change in the primary field can indicate a locked row.
It would be great to have the ability to restrict lock/unlock permissions for rows to certain users. This way, not everyone would have the ability to lock or unlock rows, adding an extra layer of security and control over the data.
This feature is useful for ensuring that, for example, completed tasks or recorded accounting operations remain unchanged.
Restrict API modifications for locked rows, while keeping allowing updates to dynamic fields (e.g., formulas showing the number of days since the row was created).
Add a filter option in views to display locked and unlocked rows separately.
Locking Columns:
Introduce an optional feature for editing confirmation for fields in columns, accessible within the column settings window.
This allows users to decide if they need it, particularly for sensitive fields like link records fields (which I would turn on for sure).
When editing a field in a protected column, a pop-up will ask for confirmation to approve or discard changes.
This added layer of protection does not apply to creating new rows, ensuring that the speed of work is not compromised.
A lock icon | color change can be displayed in the column’s name to indicate this setting.
Deletion Confirmation:
A confirmation before deleting a row or a range of rows to minimize the risk of accidental data loss.
Variations can include: mandatory confirmation when deleting via the delete key, no confirmation when deleting from the context menu, mandatory confirmation always, or a table setting to enable/disable confirmation.
These proposed features aim to strike a balance between data protection and work efficiency in Baserow. In the Airtable community forum, there were lots of topics regarding the same issues.
