This relates to some extent to the separate discussions about autosave (#1172174: Make autosave optional and implement a "save button" views field), but I thought I should point this out.
- Text field: autosaves when focus changes
- Select field: autosaves when value changes
- Hierarchical select field: doesn't save at all (#1349592: Hierarchical select widget doesn't save values)
- Checkbox/radio buttons: no autosave, has a separate "Save" button for each widget

Personally, I'd choose to disable autosave and have a save button either for each row, or for the whole page, or both. But if autosave is to be retained, can the interface be consistent?

Comments

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented

We cannot autosave complex fields, so no, the interface cannot be made consistent :)

I think #1172174: Make autosave optional and implement a "save button" views field is the way forward, as it will allow the most flexibility.

adam_b’s picture

adam_b CreditAttribution: adam_b commented
Component: User interface » Documentation
Category: bug » support
Priority: Normal » Minor

Fair enough, and I agree that #1172174: Make autosave optional and implement a "save button" views field looks like the best option. But if there have to be discrepancies, maybe the documentation should make it clear what users can expect in each case.

AndrzejG’s picture

AndrzejG CreditAttribution: AndrzejG commented

Moreover, there is inconsistency when update of a node using Editable Field triggers Rules action.

Case: I have a View displaying a table with one column of editable fields, and have quite long Rules action making some calculations of numeric fields and then locking edit through checking a Boolean field (so, update can be done only once).

Recently (alpha2 version) I noticed that calculations are triggered by "autosave", and locking is triggered by the Save button below a table.

So, it seems there are two update-like or save-like events differing slightly, and this difference is recognized by the Rules.

Conclusion: Bahaviour of Editable Fields should be strict: editing a field should be absolutely tentative until a Save button is pressed.

rooby’s picture

rooby CreditAttribution: rooby commented
Issue summary: View changes

It is pretty annoying that this is the default behaviour.

It would be good if the save on change functionality could be switched on/off.

That linked issue (#1172174: Make autosave optional and implement a "save button" views field)seems pretty focused on views and doesn't seem to be progressing, whereas it should be pretty easy for this issue to add a configurable setting for the functionality as it currently stands.