Revisions with Approved Projects
complete
Seth
complete
Done in v15.
S
Steve
Thank you for continuing to listen to your customers and for continuing to make an incredible piece of software. Great job.
N
Naresh Nichani
in progress
T
Tim Ogilvy
Thanks - this or any other way of making sure order statuses and other data in approved projects can be backed up or stored without having to create a change order.
K
Kevin Frye
Tim Ogilvy: Is the specific request to be able to create revisions arbitrarily after a project is approved? Is there a process, milestone or other factor connected to the capturing of revisions? I think this is an interesting topic and points to project process/milestones and how we might want to capture snapshots along the way.
I think it also speaks to the general idea of data backups and how our current backup scheme makes an "all or nothing" backup of data. Not only do we need regular backups, but an easier route to getting granular data recovery would help.
T
Tim Ogilvy
Kevin Frye: Yep, as per the other note, our procurement team, and support teams are constantly updating ordering ETAs and other information. We're currently not using D-Tools purchase order engine, and it might take us months, or even years to change our process to implement that.
Currently every time a user opens a project they are literally prompted to delete every bit of ordering information we have in there, which means it's pretty much guaranteed I'm going to have to deal with a major data loss situation in the next 2 weeks.
From my perspective, no data is expendable.
I know y'all are moving from XML to using the database, it would be very interesting to explore how many KB of database it would take up to store a revision history, or delta of project changes.
I realise this is harder with relational data than it is for the XML documents, so it may prove to be a valid use for a JSON or similar data structure, stored in something like Postgres or another document-store style database structure, to allow historical restore points. This would also address the undo history that users are requesting.
How granular should it be?
Ideally, at least a snapshot for every check-in. This would be the starting point... or you could allow users to choose how often, using workflow rules etc. You could also have an option to flush the backlog of check-in snapshots after a period of time, or at a certain number of check-ins (ie, the last 30... or from more than 6 months ago).
If you do eventually end up building undo-history into D-Tools, it would be amazing to check that undo history into the server with the project, so that the next user has the ability to undo things the previous user did, but I know that's a very complex idea to deliver.