Hi Babynus!
I want to congratulate you on a new version, with nice new features and (IMHO) more importantly, swift bugfixing. You introduced big upgrades as "multiple changing of elements" (something that, in itself, could have "deserved" a major version) and resolved quickly any bug that came out from that. Congratulations!
Now, to the point
I've been wondering (and wandering, too, probably
) about how to deal with document approval process for some time now. I've proposed several new features regarding it, most of them (thank you!) already tracked within Project'OrRIA's roadmap.
So, a few days ago (quite some, actually, but it's been a few busy weeks at work), it came to me that I was missing a point here (probably an important one):
Documents, same way as
products do, have a certain "lifecycle". Trough their "existence", they must
evolve through certain "steps" or "stages" according to their "maturity level". At least, that is so in industry and construction, where docs are first useful to discuss a project, then (after proper refinement) they are documented instructions for erection, and finally, they reach their last "goal" as final (closed) documentation describing what's been done, and the final state of the construction (e.g.: the plant, or the multiple-storey building) kept as reference for, e.g., following building extensions.
So, a typical lifecycle for a document, would go over (e.g.) these "stages":
I - Preliminary
II - For discussion
III- For quotation
IV - For construction / for production
V - As built / as manufactured
VI - For (future) reference [CLOSED]
Of course, depending on the importance and size of the project, perhaps not every document would need to go over
all these steps.
Basically, you would:
1- Create minor versions while in
internal review/approval process.
E.g.: a1, a2, a3...
2- Once the document gets approved by the responsible of the project, the
major version gets published
to the client. It also becomes "a reference" of that version.
E.g.: A (is reference)
3- Only
then is the client able to see that doc, and review it. And, here comes the thing:
- If he/she don't validate it -> it remains at the same stage. New uploads would change version to next index, and go back to (1).
E.g.: b1, b2, b3...
- If he/she
does validates it -> it
advances to the next stage. New uploads would change version to next index, and go back to (1). (*)(**)
E.g.: from stage III to stage IV -> 0.1, 0.2 (***)
E.g.: from stage II to stage III -> b1, b2
(*) Of course, once it gets to stage VI: "For (future) reference", the review workflow is over.
(**) Perhaps it wouldn't be necessary for every doc to go through all those stages mandatorily. It might be nice to provide the customer, in the "validation window", with a drop-down list where he/she can choose the next stage the document is advancing to (defaulting to the one previously defined by portal administrator).
E.g.: he/she might consider a "Stage I" doc ("Preliminary") good enough so as to promote it to "Stage IV" ("For production"), bypassing stages II and III.
(***) Sometimes a change of stage also (usually) implies a change in the revision index format. It's common use that revisions in stages I, II and III are represented by
letter indexes (A, B, C...), while from stage IV on they're represented by "number" indexes (0, 1, 2...)
So, the question: is there (already) a way to manage this process in Project'OrRIA?
I believe there isn't right now, but it's not very far. Some aspects of this behaviour are already there, some is already on the roadmap, and I believe only the
stages thing would be missing. But not by far: there's already "Versions" elements for projects/products. I imagine it would be possible to adapt these to be able to define documents "stages", and, with further fine-tuning, be able to manage this process I've just described.
Besides, "Versions" are defined by portal admin, so it would be configurable if/which stages the company is to use.
Personally, I believe there should be a portal default stages config, that can be overriden project-wise by the project manager. Because it may be the case that companies set a high standard, with a more complex review process, for big, long projects, but need to simplify it for small, simple projects that need to get defined more quickly.
I'd like to propose this process as an evolution for Project'Or RIA, because I believe it would "take it to the next level" regarding documents management/workflow. Somehow it includes and complements other (already asked-for) features that are already there, or on their way.
What do you think, Babynus?