It would be very useful (in my case on Grids in the Portal) to be able to have individual rows either editable or not, conditional on the data in the row - both through the edit button or in-line, i.e., to be able to prevent specific rows from being able to be changed.
I think that this would be somewhat similar to another recent request for conditional read-only fields (see attached screenshot).
Hey Phillip, thank you for this suggestion! I will add this to the previously submitted feature request for similar functionality to increase its priority internally.
I will post a reply here once there’s an update on this! Thanks again for taking the time to provide this suggestion!
When editing with the child form you could have a look at this workaround in the meantime, which might just do the trick! For inline editing there’s no workaround for this at the moment, unfortunately.
Hi Hannes, thanks for the workaround suggestion, I have actually used that in a few places, however, it is a bit clunky as it requires creating extra fields in the AirTable base and as you say, it does not solve the issue around inline editing. It would be great to have this “read only row” facility that also disables inline editing on the row. I look forward to an update in the future.
Hi Hannes, just to provide you with a bit more context on the use case here, I have a table with a list of events from now into the future. Users can see those events and check a box to indicate their participation in each, plus check other boxes to indicate certain options - so each row is an Event Name, Date and a number of check box fields. However, the opportunity to make changes for a given Event expires 2 weeks before the Event takes place. So, when the user looks at the list of Events, they can only edit/change their participation in those that are more than 2 weeks away, but they still need to be able to see what they have elected to do within the next 2 weeks. Therefore, the first few rows need to be un-editable but the others (for Events more than 2 weeks away) need to be editable.
For the time being, I have dealt with this by having to Custom Views on the table, with one being read-only showing all Events and one being editable but only showing Events that take place later than 2 weeks from now. It would be nice not to have to use two views, but that works for now.
I see, thank you for providing the context! While reading through it I also thought about the custom view workaround, so that seems like your best bet for now, but our team will look into this and I’ll let you know once there’s an update on this functionality!
