-
-
Notifications
You must be signed in to change notification settings - Fork 311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Record validation #939
Comments
Very interesting @jferard ! One related idea that has come up is a kind of draft mode. Where you hit a key to start accumulating changes that should be submitted as a single coordinated change. This comes up for people using Grist more like a database than a spreadsheet, or when there are integrations tracking individual changes that should not see intermediate states. What do you think of that kind of approach? |
The idea is very similar. But if I understand this draft mode, it is the user that decides when to enter the draft mode and when to "commit" the changes. In my proposition, there would be an automatic entering in the draft mode at the beginning of the record creation or update, and an auto commit when the user presses "enter". Thus you can think of my idea as an "auto draft mode". |
I hear what you are saying. The auto draft mode tweak sounds reasonable. I read that as: where a change is rejected because of access rules, the change isn't just rejected but preserved in the browser, and we effectively enter a draft mode. There could be decoration to explain what is going on, including an easy way to exit the new mode. I'd be nervous about changing the default behavior of "enter", that is a bit scary for an app with a lot of existing users. |
I understand that. Maybe that could be an opt-in at table level.
Imagine you have a condition on the record :
But how do you leave the draft mode? If you correct the value in the column "C", it's ok. But the problem may be in the values in columns "A" or "B". If you can, in any way, leave the draft mode without fixing the whole record, the record is still created. Since you entered the draft mode in column "C", one can't expect a "rollback" of the whole record: values in col "A" and "B" are definitely saved. |
Is there a need to support this in a regular table view, or could such functionality (auto draft mode) be tied to particular UI? E.g. I could imagine the following: in a page where such functionality is needed, one could lock the table for editing, making it read-only with a button to open an editable record. Opening the editable record would enter the draft mode, where all the changes remain in the browser, until a "Save" button is clicked on the record. That would submit all changes as a single update. In other words, this would be a more typical app interface, rather than the spreadsheet-style one-cell-at-a-time approach. |
I imagine this particular UI would be like a form, with a "submit" button, but accessible from the document, not through an external link. Or a card-like widget with a submit button. That would be nice and would allow the owner to protect the data set from invalid records. Beyond this UI question, there's a semantic question: what is the minimal element in a table that makes sense?
Since Grist "combines the flexibility of a spreadsheet with the robustness of a database", why not allow to choose the behavior, depending on the needs of the user? (Okay, that's easier said than done and I'm aware that there are probably technical issues here, but that's another question.) |
I vote for this feature! |
Here is a workaround that I have found. You have to add two columns to your table :
Now imagine you have three columns : "Anum" (a numeric column), "Bdate" (a date column), "CintGE10" (an integer column with a value >= 10) Here's the "ErrMessages" formula :
Of course, you can set the error checks (and associated messages) that you want. Here, I wan't the columns to be not empty and of the correct type and, as said, "CintGE10" >= 10. Now, the trick is to accept the validation only if the "ErrMessages" are empty. This is ensured by the following access rules on the table :
Then you filter the records to keep only the validated ones in your widgets. This is better than nothing, and may probably be improved, but there is a main drawback : a valid record may not be validated and thus ignored. |
The problem
It's a common need to prevent the creation of invalid records in a data set. This enforces the quality of the data. And everybody knows that usual spreadsheets are not very good for this task.
With Grist, we can use Access Rules to prevent some values to be inserted in some columns. E.g. If (numeric) column "A" values must be greater than 10, we can have a rule: allow update or creation only if
newRec.A > 10
. But a record may be invalid even if each of its values is valid. E.g. I can accept any value for (numeric) columns "A" and "B", but reject a record that would not meet the conditionnewRec.A + newRec.B > 10
.What happens
If I try to enforce such a condition with an Access Rule, here's what happens when I want to have "5" in the column "A" and "7" in the column "B" of a new record (creation):
The hack is to copy-paste "5\t7" on the row of the table.
What I would expect
In other words, Grist would allow that during the update or creation, a record might become temporarily invalid. That implies that record creation would be validated after all values are entered (pressing "enter" is the signal) and the values should be saved only after that validation.
Obviously, this would be a non trivial change in the user interface of Grist. It seems to me that the benefits (quality of the data) outweigh the disadvantages (loss of flexibility), but I may be wrong!
Related
The text was updated successfully, but these errors were encountered: