Hi Paul,
I haven’t thought through this thoroughly, and I’d be curious to hear about the maintainers’ views on the semantics of amended documents, but just speaking off the cuff I think what you’re describing could be done with very little change and no side effects. Appropriate data structure is already in place on the back end, and adjusting the UX would require only a few very minor tweaks on the front end.
Amended documents form an explicitly linked chain, starting at the original and ending at the currently submitted version. All we need to achieve what you’re describing are a few design cues to link versions in the chain together.
On the form view, you’d need two things:
-
A widget that allows you to select earlier versions of a document in an amendment chain. (I have no eye for design, but just as an example it could be as simple as this:
. Clicking on a version name loads that form view.
-
A tweak in the code that pulls comments and emails. Right now, it just pulls timeline events from the current document version, but it would be relatively trivial to make it pull also from previous versions in the amendment chain.
On the list view, you’d need one thing:
- Right now, the list shows all versions in an amendment chain as separate documents. Presumably, we’d only want to show the latest version and let older versions be accessed from the form view. I don’t think this could be done with filters out of the box, but it certainly would be possible with a bit of post-processing.
I’d have to look more closely to be sure, but at first glance it seems like it might all be doable by overriding some javascript classes at runtime with an app.
EDIT: Editing just to add that I don’t actually like the Amendment History dropdown where I’ve put it in the picture above. It should probably go in the sidebar above the word “Comments”, but that’s just as easy to do.