Using "no update" version option for documents

babynus wrote: Double approvment is not planned.

It would be pretty useful, I think, since this type of workflow is pretty spread around in construction, design, industrial (...) businesses.

Perhaps there could be an intermediate stage between "in process" and "approved". Something like "reviewed".
It's usual that there's only one, or a few, people, (department head) that are responsible for the approval of every doc. Since many docs are created, by many more people, bosses should only have to review the final drafts of the revision, when minor defects (omissions, typos, aesthetic issues, etc.) have already been found and corrected. And that first "review" can be done by peers. That way you manage to loosen up bosses' (usually pretty tight) schedule, but they still have "the last word".

Creating another "stage" could be the first step in an automated process.
You could do it anyway, since you can check when all the other "approvers" have approved the doc. And only then you mail your boss so that he knows that only his approval remains regarding a certain doc (or something like that...)
But in order to automate this (as a future improvement) Project'OrRIA should know these different stages (or at least I think so )

babynus wrote:

Once I've uploaded a file to create the first (or new) draft version of a doc, does the "approve" button automatically appears in the approvers' doc panel?. What if he finds errors? is there a "reject" button, so I automatically know that I need to review it? Is there a "comments" box, so that he/she can write down what needs to be changed in that particular version?

No, approvment process is not so sofisticated.

- Is a ticket (or activity) created automatically when the doc's status change? (e.g.: how can I know that I've got pending "reviewing" tasks?)

Hem, no. There is no direct way to check pending approvments. It may be an improvement to implement.

This could be a great (fundamental, I'd say) improvement for construction (or design, generally speaking) companies. Mainly because creating docs is (one of) the most important task(s) for everyone. So, automating this process would make everyone's lives so much easier .
The goal would be that, when I log in the portal, I get a summary of the docs I need to create, the ones I need to review (if I find errors I press a "reject" button and a dialog pops up prompting me to comment on necessary changes), and the ones I've already created and have been reviewed (and commented by peers) and need changes.
These would be tasks for me to complete (not sure if they should become tickets, activities, or something else...).

In fact, I'd like to propose this as an evolution. Do you think this is possible to be done?

Would you prefer me to continue this thread until we find precise definitions for these requirements? Or should I start a new "propose evolution" thread, with a more "open" idea (sort of "how I imagine the ideal document workflow, and the tools that I'd like Project'OrRIA to provide" thread )?

Thanks Babynus! for such an interest in resolving our doubts, and for your big patience!!

babynus wrote:

way to check pending approvments

I had already recorded request as Ticket #1114.
And in fact, something like that already existed on Ticket #890.

Great!

Ticket #890 is "Document approval notification"

Probably just single button to send messages to all approvers (who still not approved) that they have document to approve

I understand this is some kind of reminder. That is nice to have. But what I intend is a little bit different: I'd prefer reviewing and approval stages became tickets, or activities, for people who are designated as responsable for those status changes. That way, that ticket remains there until you actually review/approve the doc (and doesn't get lost in email reminders) and actually consume the ticket (not really sure if "ticket" is the right word here ).
Also you can have a better picture of which/how many documents are in which stage, you could have reports regarding it, and you could even allocate real work time to it.

Ok, maybe I'm just dreaming awake
Maybe I'll just have to wait until v4.0 is out, and congratulate you once again

babynus wrote:

Double approvment

Request recorded as Ticket #1115

Thanks! I'll be waiting for it
It seems there'll be some nice improvements around workflows in v4.0

One more thing I'd like to point out:

I've already explained the workflow we use (and which is pretty common in industry), and the fact that we use two revision flows in paralell: internal (draw -> review -> approve for publishing) and external (publishing -> approve/reject by client).
We can figure this out, as you've already explained, using draft (internal) and non-draft (external).

It's common use that a letter (starting on "A") is used as revision index while the document is rejected by the customer. But once the doc gets approved by the client, the revision index changes to a number (starting on "0"). Following versions would be 1, 2...
Is this something that can be taken into account?

The complete workflow would be something like:
- vA_draft1 is created -> "done" (reviewers and one approver are defined)
- (when "done") a review ticket is automatically created for reviewers
NOTE: perhaps there should only be one ticket per doc, and all people involved should allocate their time spent on it there (thus this step would be different: instead of a review ticket there should be something else that prevents people from misplacing review activities). Not really sure which is the best solution here
- vA_draft1 is reviewed -> "rejected" (changes are described in the corresponding field)
NOTE: in the ticket reviewers can allocate real work time for reviewing activity
- the responsible of the doc gets notified (via auto-ticket or via auto-something-else) that he/she needs to generate a new draft.
- vA_draft2 is created
- vA_draft2 is reviewed -> "reviewed"
- approver gets a new ticket/sthg else that prevents him/her from fogetting this.
- vA_draft2 is approved -> vA gets "published" (?)
- only then is the client ("external project leader") able to participate: he gets notified that a new version (vA) has been published.
NOTE: not really sure if the inner side of the process should be visible to clients. Perhaps it should be configurable through parameters (as almost anything is in Project'OrRIA )
- vA is "rejected" by the client (with comments)

...iterate...

- vB is "approved" by the client (kudos!)
- responsible gets notified and uploads new version -> v0
NOTE: from now on, new versions would be 1, 2...(automatical change of revision caption, based on the "client approved" status). This whole thing would be like a new "industry" versioning type (such as "evolutive" or "sequential").

OK, that would be all by now... I don't want to get kicked off the forum by mad babynus (LOL!)

Cheers...!