Totally agree, your table’s got it right in my opinion.
One detail I’d like to add: when a PUT or POST includes data for a column that isn’t editable, the call shouldn’t be rejected. That column should just be ignored silently, and the rest applied.
That’s how it already behaves today for fields that aren’t in the view at all. I tested a POST on a grid with an extra field that wasn’t a column, and got a 200 with the record created and that field simply left out. Keeping the same rule for non-editable columns means existing code that sends a full record payload keeps working, instead of turning this into a second breaking change.
Thanks for the feedback. We will be holding off on this change until we are able to discuss it further and come up with other non-breaking solutions. I will respond to the questions/points in more depth shortly.
We really appreciate knack holding off on this to allow us to fix and adjust our code. Some of these fixes are important and should be made as they are real security issues, as until this forum post we assumed inline edit was the gate for POST ing records. We have some views where this is undesirable.
I’m a little late to the party, but I really don’t want my apps to allow POST to an edit form or inline editable view.
Often, I’m wanting to lock down permissions that certain users roles can do, and if I know that a user role does not have any access to a “create record” form, then I assume there’s no way for them to create a new record (which as we see here is not true)
Alternatively, I may want a user role to be able to create records but with very limited fields & some auto-set metadata. I can achieve this through a create record form that only contains the relevant fields and has some record rules.
Both of these important security use-cases are broken if it’s possible to POST to an edit form or an inline editable view.
The new data access controls somewhat helps this situation (but not completely), but I still don’t like how POST to edit forms and inline editable views opens apps up to unauthorised API access.
I support Stephen’s suggestion ifthere’s a security setting in the app where you can toggle allowing POST on edit forms and inline editable views
I also think that the behaviour of allowing POST for those views should be OFF by default as it creates more secure apps by default, and only some users implementing custom code will want to change this.