ALFRESCO: New space for user docs

Hi Jeremy, :slight_smile:

I can not. There is no Add Content button in that space for me. I
 could upload to my space just fine, but when I went to run the
 action 'move' or 'copy' on the files which were in my space to the
 Writers Guide space, I got the following error: '* Failed to run
 Actions due to error: 000645896 Access Denied. You do not have the
 appropriate permissions to perform this operation.'

I've applied a short-term fix... Can you please try again?

David Nelson

It worked. Writer Guide 3.3 chapters 4 - 6 are now in Company
Home/LibreOffice Documentation/Writer Guide 3.3. Also, the 'Add
Content' button is now visible for me in that space.

My question now is, even though there was no true folder system like
that which Jean detailed on the documentfoundation website, there was a
matrix that helped us (me? haha) envision a proper workflow.

Would that be something for which the 'Spaces' area could be utilized?
Perhaps create 4 spaces per guide - Drafts, Feedback, Proofing and
Publish - with the documents being shuffled about between those spaces
as they progress?

Just thinking aloud here, but if so would that mean we would 1)
download the doc, 2) perform our task, 3) upload the doc and then 4)
move the doc to the new 'Space'?

-- jdc

That's more or less what the example (tutorial?) in the "Getting Started
with Explorer Document Management for Alfresco" guide suggests, although the
tutorial also talks about creating workflow "rules". I haven't quite got my
head around the concept of "rules" and what they are supposed to be used
for.

I like the idea of multiple spaces per guide, because that helps me keep
track of things, and it probably won't break anything to set them up. We
should be able to just move docs manually... at least at this point.

Hal

Ok, still thinking aloud here. If that's the case, with the documents
being stored in one of 4 spaces to keep track of work flow, the 'Content
Items' will then be empty.

Perhaps we could place a core set of documents in that 'Content Items'
for every guide we produce. The Workflow.png flowchart, a document
which details our workflow (certainly a working document at this stage
of the game - less so as it gets dialed in), A document which details
information about the project such as 1) Who is primary stakeholder, 2)
Goal of completion, 3) etc... and perhaps another document which gives
a list of links to further help such as to the Power User's guide,
maybe the irc.freenode.net address...

I'm sure the primary producers of documentation so far have a better
idea than I of what would be handy to have instant access to,
consolidated in one space, for every work space they could be involved
in. The idea is to 1) Make it obvious and easy to someone just joining
how they can be of use, and 2) Once the user is underway, keep them
from clicking all about looking for different pieces of a puzzle.

And if I'm on the right track here, I wonder when would be a good time
to rework http://wiki.documentfoundation.org/Documentation/Development
to 1) remove our current workflow and matrix, and 2) briefly explain how
we use Alfresco, add a link to the site and a request for the user to
get in touch with Hal or other to get a sign-in setup.

-- jdc

Ok here is a usecase that is active and being used for REAL:

We are a team of Brasilian translators that translate the BrOffice Magazine
from Portuguese eo English.

We have 4 folders in a DropBox setting with the root folder having a
Spreadsheet with the workflow,

So our root folder looks like:

WORKFLOW.ODS

Entry /

Translation /

Revision /

Diagramation /

So the workfow is:

1) An article is put into the Entry folder, Workflow.ods is updated ,
generally "$DATE, article.odt, is put into the Entry"

2) One of the Translators moves the "article" to the Translation folder,
changes it's name to show who is working on it and at what step he is
"article-Joe-Trans" - he updates the Workflow.ods to show what is being done

3) After he finished he renames to "article-Trans-FINISHED" moves it to
Revsion / folder and updates the Workflow.ods

4) One of the Revisors , renames to "article-Rev-Jonny" and updates the
Workflow

5) After he finishes , renames again to "article-Rev-FINISHED" and puts it
in the Diagramation folder, updates Workflow

6) Diagramation guys rename to "article-dia-Roberta" and when finished the
rename "article-FINISHED" and updates the Workflow, when all articles are
"FINISHED" we have a new magazine ready for the stands (at least the
eletronic ones) :slight_smile:

This seems to me a good place to start ...

Rogerio

PS: if the lsit permits I am sending our .ods for an example

Hi guys, :slight_smile:

There is a possibility that someone with Alfresco experience might
help develop a workflow for us (see [1]). Let's see what comes of
that...

Rogerio, your attachment did not get through to the list. If you'd
like to post in on the wiki and mail us the link, or mail me the .ods
file and I'll post it on the wiki, maybe?

[1] http://nabble.documentfoundation.org/ALFRESCO-Where-to-put-user-doc-files-tp2161736p2196110.html

David Nelson

http://wiki.documentfoundation.org/cgi_img_auth.php/b/b9/ZINE_02_TRABALHOS.ods

Here is the file

Rogerio

I can setup the review/approve workflow for the spaces. Someone need to
decide the number of steps in the workflow and name each space/folder. I
also suggest configuring auto-versioning for all spaces so everyone can get
back older revisions.

Hi Samhan, :slight_smile:

I can setup the review/approve workflow for the spaces. Someone need to
decide the number of steps in the workflow and name each space/folder. I
also suggest configuring auto-versioning for all spaces so everyone can get
back older revisions.

It would be really terrific if you could do this. I feel that Ron
Faile is probably the best person to liaise with about this, because
Ron has the best feel for the workflow within the team right now.

Does anyone else have any thoughts on the subject?

David Nelson

My only thought at this point is that the workflow needs to allow for the
possibility of looping through several iterations of reviews and edits, or
just one iteration, depending on the individual document, similar to the
diagram on the /Documentation/Development wiki page.

Note: I know nothing about the way "rules" are set up for moving files from
one space to another, so what I just said may be a built in or default
feature that those familiar with "rules" might think is obvious and "of
course it's that way".

Hal

-- jdc

Hi Samphan, :slight_smile:

We'd really love you to do this work very much. As you know, you
already have the necessary permissions in the admin back-end. Let me
know if there's anything that has to be done at OS level.

Ron Faile has agreed to lead in working with you on establishing what
our workflow is and what we would ideally like it to be, because he's
the one among us that is closest to the workflow right now. We'll all
be pleased to chip in with advice, comments and help when needed.

We're very much looking forward to working with you, and thank you
very much for your kind offer. :wink:

David Nelson

Jeremy, what file is that supposed to be? It's not a glossary. Wrong
reference, perhaps?

Hal

Jeremy, what file is that supposed to be? It's not a glossary. Wrong
reference, perhaps?

Hal

I believe it was a spreadsheet which detailed and controlled Rogerio's
Broffice team workflow. A spreadsheet seemed to be a thought someone
else had on inclusion in the Alfresco set-up.

I would also add at this time a list which details the sort of task Ron
details in the following message.

Hi Shawn. One thing we need help with right now is creating quick
reference cards for each of the applications in LibreOffice. If you
would be willing to help with that, we should be able to get you
started.

-- jdc

OK, thanks. The context confused me, as it appeared to be in response to the
quote from my note about a glossary.

Hal

Oh yes, no. Sorry to confuse you. I was just gathering ideas people had
for David and Samphan re: the Alfresco setup and usage. :slight_smile:

-- jdc

Samphan,

Here is the workflow that I've come up with. It's basically what we are doing now on the wiki.

Folders: Drafts, Review, Proofing, Published

Step 1.

A user uploads a new file to the Drafts folder. Someone checks out the file from the Drafts folder to begin editing. The file stays in the Drafts folder and is marked that it is checked out and to show which user is working on it. If possible, prevent other users from editing the file while it is checked out.

Step 2.

The user downloads the file, makes changes and then uploads the file to Alfresco and checks the file back in. The user is then offered the option to either leave the file in the Drafts folder if the file needs further editing or if editing is complete, move the file to the next step in the process, the Review folder.

Step 3.

Another user goes to the Review folder and checks out the file, downloads it and reviews it. If the file was revised, it would be moved back to the Drafts folder and the document is checked back in. If it was ok and ready to proceed to proofing, the file is moved to the Proofing folder and the file is checked in.

Step 4.

A user goes to the Proofing folder, downloads the file and proofs it. If the file needs more work, it is moved back to the Drafts folder. If they agree it is ready for publishing, they go to the Proofing folder and mark that the file is ok. The file is marked as having been proofed once. Then a second user proofs the file and if they agree it is ready to be published, they mark that they have proofed the file and it is ok. Once the file has been proofed by two users, then it will be moved to the Published folder.

I agree about turning on auto-versioning. Let me know if you need anything else. Thanks.

Ron

I've just finished early implementation Ron's workflow and roughly tested.
Here's the procedure of the workflow in Alfresco (sorry for my English
-_-!):

Spaces: Drafts, Review, Proofing, Proofing2, Published

Only Alfresco users in the "Documenters" group are involved in this
workflow. Other users have read-only access to the spaces.

Step 1.

   1. A user go to the Drafts space, click "Add Content", choose file to
   upload, fill-in the document "Name", and in the "Type" field choose
   "Content".
   2. Someone checks out the file from the Drafts folder to begin editing.
      - To check-out a file, click on the "More Action" (triangle inside a
      circle button) and choose "Check Out".
      - Then choose the space for the working copy which should be in the
      user's home space.
   3. The checked-out files stays in the Drafts folder and is marked that it
   is checked-out by the "locked" icon. Hover at the icon to show which user is
   working on it.
      - Other users are prevented from editing the file while it is checked
      out.

Step 2.

   1. The user downloads the working copy, makes changes and then uploads
   the file to replace the working copy with new versions.
   2. When finish, click the "Check In" button of the working copy. The
   working copy will be removed and the original file will be editable again.
   3. The user is then offered the option to either
      - leave the file in the Drafts folder if the file needs further
      editing
      - or if editing is complete, move the file to the next step in the
      process, the Review space, by clicking at the "More Action" button and
      choose "Submit to Review"

Step 3.

   1. Another user goes to the Review folder and checks out the file,
   downloads it and reviews it.
   2. If the file was revised,
      - the user check-in the changes
      - then choose "Reject to Drafts" to move the file to Drafts space.
   3. If it was ok and ready to proceed to proofing
      - the user check-in the changes
      - then choose "Submit to Proofing" to move the file to Proofing space.

Step 4.

   1. A user goes to the Proofing space, downloads the file and proofs it.
   2. If the file needs more work, it is moved back to the Drafts space by
   choosing "Reject to Drafts".
   3. If the file is OK, it is moved to the Proofing2 by choosing "Submit to
   Proofing2". This is to mark that the file have been proofed once.
   4. Then a second user goes to the Proofing2 space, proofs the file.
   5. if the user agree it is ready to be published, s/he choose "Submit to
   Published" which move the file to Published space. That means the file has
   been proofed by two users

I've just finished early implementation Ron's workflow and roughly tested.
Here's the procedure of the workflow in Alfresco (sorry for my English
-_-!):

Spaces: Drafts, Review, Proofing, Proofing2, Published

Only Alfresco users in the "Documenters" group are involved in this
workflow. Other users have read-only access to the spaces.

Step 1.

  1. A user go to the Drafts space, click "Add Content", choose file to
  upload, fill-in the document "Name", and in the "Type" field choose
  "Content".
   2. Someone checks out the file from the Drafts folder to begin editing.
      - To check-out a file, click on the "More Action" (triangle inside a
     circle button) and choose "Check Out".
     - Then choose the space for the working copy which should be in the
     user's home space.
  3. The checked-out files stays in the Drafts folder and is marked that it
  is checked-out by the "locked" icon. Hover at the icon to show which user
is
  working on it.
     - Other users are prevented from editing the file while it is checked
     out.

This is done automatically by Afresco right?

Step 2.

  1. The user downloads the working copy, makes changes and then uploads
  the file to replace the working copy with new versions.

Again done by Afresco?

  2. When finish, click the "Check In" button of the working copy. The
  working copy will be removed and the original file will be editable
again.

Nice

   3. The user is then offered the option to either
     - leave the file in the Drafts folder if the file needs further
     editing
     - or if editing is complete, move the file to the next step in the
      process, the Review space, by clicking at the "More Action" button
and
     choose "Submit to Review"

Nice

Step 3.

  1. Another user goes to the Review folder and checks out the file,
   downloads it and reviews it.
  2. If the file was revised,
      - the user check-in the changes

We will have to MANUALLY check in the changes or will the revision feature
in LiO give us this?

     - then choose "Reject to Drafts" to move the file to Drafts space.
   3. If it was ok and ready to proceed to proofing
      - the user check-in the changes
     - then choose "Submit to Proofing" to move the file to Proofing space.

Step 4.

  1. A user goes to the Proofing space, downloads the file and proofs it.
  2. If the file needs more work, it is moved back to the Drafts space by
  choosing "Reject to Drafts".
  3. If the file is OK, it is moved to the Proofing2 by choosing "Submit to
  Proofing2". This is to mark that the file have been proofed once.
  4. Then a second user goes to the Proofing2 space, proofs the file.
  5. if the user agree it is ready to be published, s/he choose "Submit to
  Published" which move the file to Published space. That means the file
has
   been proofed by two users

Nice

- Overall a very robust publishing system... my only question: IF reviewer
vanishes (has happened in the past) can someone get the copy of the file? in
the step it was left behind (I assume yes) ?

Rogerio

> I've just finished early implementation Ron's workflow and roughly
tested.
> Here's the procedure of the workflow in Alfresco (sorry for my English
> -_-!):
> Spaces: Drafts, Review, Proofing, Proofing2, Published
> Only Alfresco users in the "Documenters" group are involved in this
> workflow. Other users have read-only access to the spaces.
> Step 1.
> 1. A user go to the Drafts space, click "Add Content", choose file to
> upload, fill-in the document "Name", and in the "Type" field choose
> "Content".
> 2. Someone checks out the file from the Drafts folder to begin
editing.
> - To check-out a file, click on the "More Action" (triangle inside
a
> circle button) and choose "Check Out".
> - Then choose the space for the working copy which should be in the
> user's home space.
> 3. The checked-out files stays in the Drafts folder and is marked that
it
> is checked-out by the "locked" icon. Hover at the icon to show which
user is
> working on it.
> - Other users are prevented from editing the file while it is
checked out.
This is done automatically by Afresco right?

Yes.

Step 2.
> 1. The user downloads the working copy, makes changes and then uploads
> the file to replace the working copy with new versions.
Again done by Afresco?

The user just choose "Update" and select the file to upload.

> 2. When finish, click the "Check In" button of the working copy. The
> working copy will be removed and the original file will be editable
> again.
Nice
> 3. The user is then offered the option to either
> - leave the file in the Drafts folder if the file needs further
> editing
> - or if editing is complete, move the file to the next step in the
> process, the Review space, by clicking at the "More Action" button
> and
> choose "Submit to Review"
Nice
> Step 3.
> 1. Another user goes to the Review folder and checks out the file,
> downloads it and reviews it.
> 2. If the file was revised,
> - the user check-in the changes
We will have to MANUALLY check in the changes or will the revision feature
in LiO give us this?

Yes. The user must manually check-in/upload the revised file if s/he want to
make change.
If s/he just want to "read" the document then s/he can just download the
file w/o checking out.
The versioning in Alfresco is to call a new version after each update. If
you access Alfresco thru CIFS, update is merely saving the file. For
web-based Alfresco Explorer, update is an upload.

> - then choose "Reject to Drafts" to move the file to Drafts space.
> 3. If it was ok and ready to proceed to proofing
> - the user check-in the changes
> - then choose "Submit to Proofing" to move the file to Proofing
space.
> Step 4
> 1. A user goes to the Proofing space, downloads the file and proofs it.
> 2. If the file needs more work, it is moved back to the Drafts space by
> choosing "Reject to Drafts".
> 3. If the file is OK, it is moved to the Proofing2 by choosing "Submit
to
> Proofing2". This is to mark that the file have been proofed once.
> 4. Then a second user goes to the Proofing2 space, proofs the file.
> 5. if the user agree it is ready to be published, s/he choose "Submit
to
> Published" which move the file to Published space. That means the file
> has been proofed by two users
Nice
- Overall a very robust publishing system... my only question: IF reviewer
vanishes (has happened in the past) can someone get the copy of the file?
in
the step it was left behind (I assume yes) ?

An admin can undo a check-out of everyone and undelete every files.