silverstripe-asset-admin icon indicating copy to clipboard operation
silverstripe-asset-admin copied to clipboard

Published 20 hours ago • verified publisher icon silverstripe

Move file history to more options

Open clarkepaul opened this issue 7 years ago • 10 comments

File history is being hidden as part of this issue https://github.com/silverstripe/silverstripe-asset-admin/issues/541. This issue is to make it visible again but a user can navigate to it via the more options dropdown for the individual file.

Just like any other content, users will require access to a files history and the meta information associated to it, like publish dates, who authored a change etc. We don't need to store all of the previous versions of a file unless the site has been configured to do so but we should allow visibility of file changes. The history viewer has now been built in a responsive way so it shouldn't bee too much of an effort to get this working for files.

Initial mockups here which might need modifications once this issue gets picked up ~https://projects.invisionapp.com/share/HGBQ16DP4#/screens/233857852~ https://invis.io/WCMZMHHXRJV#/380202567_File_History_1 UPDATED 22/8/19 by Jared Lee

Note

  • Add the behat tests that were removed in https://github.com/silverstripe/silverstripe-asset-admin/pull/582
  • Ideally we can switch this section to using GraphQL at the same time, see https://github.com/silverstripe/silverstripe-asset-admin/issues/333

Background

About a year ago we had file history in one of the tabs but this placement conflicted with the other tabs and the way "Save/Publish" worked across all the tabs, so we set about creating a React history viewer which could be re-introduced back into files in a better way which doesn't conflict.

clarkepaul avatar Aug 09 '17 22:08 clarkepaul

@clarkepaul I'm thinking of moving this out of the milestone, into a 4.1. What do you think the impact is for the average CMS author? I don't expect version tracking on files to be of very high value itself (e.g. knowing who changed a title, or replaced an image). On the other hand, it surfaces a banner feature of 4.x (filesystem abstraction), beyond just showing draft/live stages.

chillu avatar Aug 20 '17 23:08 chillu

@chillu Yeah, we actually came to the same conclusion when you were away. As part of this Beta we actually removed file history from view as it was still slowing down the edit panel load times and it didn't have the functionality to restore anyway. I'm happy to re-introduce the file history in the new location at a later date.

clarkepaul avatar Aug 21 '17 00:08 clarkepaul

Discussed with Paul, draft files is a new feature and hence won't be impacting a lot of authors (just the subset that cares about individual publication of files). Chris Joe said that the current history panel implementation can be reactivated by config.

Deferring this will also give us an opportunity to look at history viewers in a wider context (content blocks etc)

chillu avatar Aug 22 '17 02:08 chillu

Is there any traction on this issue, or any plan for when it might be implemented? I've spoken to a couple of clients who are keen to use it so they can version files and preserve them for regulatory compliance.

Thanks!

madmatt avatar Dec 20 '18 06:12 madmatt

Also - is this the same as #873?

madmatt avatar Dec 20 '18 06:12 madmatt

It sounds like it is, will leave for @clarkepaul to put two cents in before closing one of them

robbieaverill avatar Dec 20 '18 09:12 robbieaverill

FYI I've closed the duplicate issue.

clarkepaul avatar Jan 06 '19 21:01 clarkepaul

Hi, I'm dev for one of the clients that spoke with @madmatt. Thanks Matt for pointing me to this issue. I can confirm we're really looking forward to this feature as we work with finance and they are pretty strict about compliances and being able to roll-back files. For what I can tell it's pretty close to be functional so here's hoping that you guys can fast track it. Also, on a similar note: another feature we are really looking forward to is the history tab for the blocks/elements to be extended to all DataObjects (after all an Element is a DataObject and looking at the tables on the database it looks like that view should be compatible?). If you guys can point me to a correct thread I'll officially request this second thing as well. Thanks!

eehondas avatar Jan 08 '19 05:01 eehondas

Thanks for the background @eehondas. The new history viewer has been built to be compatible with all types of data/files so its more of a matter for us to get the other UI's within the CMS to use it now (although there are a lot of other priorities).

clarkepaul avatar Jan 08 '19 22:01 clarkepaul

its more of a matter [...] to get the other UI's within the CMS to use it now.

This can also be implemented with custom code (and custom DataObjects). There's some documentation here: https://docs.silverstripe.org/en/4/developer_guides/model/versioning/#using-the-history-viewer

ScopeyNZ avatar Jan 08 '19 23:01 ScopeyNZ