Allow hiding the preview link

[antonioribeiro]

Summary

Sometime we want to have revisions, to see who's changing what, but not previews, because there's no frontend page related to that module.

Describe the solution you'd like

I believe the only way to hide the preview link is to remove HasRevisions from the model. Would be better if we could hide them by configuration, maybe on $indexOptions?

[ifox]

We can make this easier and better, but there is another way without disabling revisions: returning an empty array of revisions to the UI, using formData. The current UX requires preview to be enabled to restore a revision, since clicking on a revision opens the preview. When returning an empty array, revisions are not exposed to the user, the preview link is not showing, and revisions are still stored in database. If you use this approach, forceReloadOnSuccess should also be used, since without it the frontend will dynamically expose the new revision on save.

[antonioribeiro]

It's not only about storing revisions, but being able to look at who and when is updating these records, while hiding the preview link. If we remove revisions but keep them on database it's not really useful on the CMS, unless we create something else for users to see who is changing things.

To not overcomplicate things, the revision links could stay, showing only a modal asking if the user wants to restore to that version. But ideally it should load all the inputs on the CMS, make them read-only, and change the update button to "RESTORE".

[ifox]

I was only providing a way to achieve what you were looking for because what you are describing requires internal changes to the UX, so it is not as simple as giving you the ability to hide the preview link was what I was trying to say. We can certainly find a solution, but it will require more time.

[ifox]

What you describe about the form when restoring a revision is also pretty much the existing behavior, it loads the form with a message indicating to the user that they are currently restoring, the button label changes too, but it currently goes through a preview where the restore button is exposed to get into the form in restore mode.

[Tofandel]

I think there is some improvement that can be done on revisions, maybe instead of the preview we could show the fields directly in the form and highlight the ones which have been modified somehow, it does need to make it clearer what's been modified or not

We could even have a revision on a field by field basis, a bit like languages, so you have a revision icon next to a field which shows the edits that happened to that field when you click on it, and shows the old value of only that field when selecting the revision

[ifox]

I agree a "diff" sort of view would be great as an option, but we don't want to lose our ability to visually compare the frontend when there is a corresponding route to preview for the edited record. Even when the edited record doesn't correspond to a route, it can usually be rendered using the frontend components in which the data would be used. There is definitely a use case for non-previewable revisions, and I think our data structure could easily be rendered as a helpful diff in that case. I also researched in the past how we could apply some diff styling to the rendered frontend, to better indicate where the changes are visually, but the experience could be jarring depending on the frontend design.