Suppose following use-case:
We get a supplier quotation and use the email feature to communicate with the supplier about issues.
Then we amend the supplier quotation.
What happens to the history? Are the comment and email entries goingt to be relinked to the amended document?
Nope, but the “Amended from” document is linked in the new one, so it’s possible to click into the original easily.
Hmm, that’s a bummer.
How we can easily see communcation history for a quotation, when we need to switch between documents?
When we have let’s say 4 amendments, no way I can communication to the user, just look at each of the previous docs to find your information.
The problem I see here is a basically the way ERPNext handles doc revisions.
Probably I’m not the first one to mention that. Are there arguments for using multiple documents to keep track of revisions instead of something like in common versioning systems?
Yeah, it’s an interesting question. The entire approach to naming series is probably due for a rethink. For me, the big issue is that drafts get assigned serial numbers before submission, which leads to gaps. In principal, it should be possible to create the versioning system you’re talking about purely on the frontend without needing any backend changes.
In the meantime, it should be possible to copy over comments to the new document with a server script. Emails would be a bit trickier.
@peterg, what do you think how to propose a design change for doc revisioning?
There will be many side effects I suppose, but I see this as a super crucial requirement. The current implementation is hardly usable for us to manage projects and purchase/sales of more complex items. We’ll always need another communication channel, which raises the question why using erp at all.
I had some thoughts on it.
Basically each doc needs to get a unique internal doc id that is not the doc name.
On amendment the doc needs to be replaced under the hood. A newly created document inherits the doc name. The amended_from field points to the previous doc.
Is there someone who has the same requirements?
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.
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.
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.
