Hello Rachael,
I've read this several times to try to understand as best as possible, if
I'm missing something let me know.
- Version Numbering:
- Yes, at one time it was possible to have major, minor and micro
numbers for each document version. This caused a number of difficulties
(API, celery) and was removed about a year ago (
https://gitlab.com/mayan-edms/mayan-edms/commit/af51acebf5633a97a0b9e199faf8a3d836f3d614)
as part of the code complexity and clean up initiative to help keep the
code base maintainable by the small number of core devs (
https://github.com/mayan-edms/mayan-edms/issues/56). Could partly be
added back as a model with a OneToOne field to DocumentVersion and CRUD
views. Until a method to replace the new document version upload workflow
is added, setting the document version number would be a separate step
after the version is uploaded.
- Workflows:
- Once a workflow is added to a document type that workflow is
required for the document type. Setting a workflow as optional was not
visualized at the moment the feature was added based on the feedback as
having optional workflows would leave the task of lauching the
workflows to
an user. If it can be implemented in a way that doesn't break backwards
compatibility, it can be something to add in a future minor version. Feel
free to open the ticket to keep track of this.
- Assigning recipients to workflow states is something reasonable. I
would argue in favor of settings groups or roles as recipients instead of
individual users thought. Let's discuss pros & cons in a
separate topic to
define the behavior and add that.
- Access control:
- To modify the visibility of the a document type modify the Access
Control List of that document type, don't grant the view permission to a
role as that will grant it as a global permission. Go to the
document type
list view and click on "ACL" then click on "New ACL", chose the
role which
you want to be able to views the document and grant the document view
permission, it will be granted only for this document type. [Object] ->
[Role] -> [Permission]
- Permissions can't be granted to an user or group, these are
organizational units not permission units. Permissions can only
be granted
to Roles. Users can't belong to a role only groups. [User] -> [Group] ->
[Role]. Users and Group mirror the organization's actual HR structure.
Roles map those organizational structures to the access level in
Mayan via
Roles.
- Document number reservation:
- This could be done in a fork or in the document renaming app
itself. It would entitle adding a number that is to be excluded by the
sequence when it is incremented unless the document being uploaded is the
document with the reserved or hard coded sequence number.
To summarize:
Version number: Specific behavior, not likely to make it into core, custom
development.
Workflows: Optional and recipient, reasonable, likely to be added to core
soon.
Access control: Can be achieve right now.
Document reservation: Can be added to document renaming app.
On Fri, Jan 22, 2016 at 4:20 PM, Rachael Sewell <[email protected]> wrote:
> Roberto,
>
> Version Numbering:
> I had seen in a forum post that there was a way to specify a version
> number. Maybe this no longer exists in the current version, but I'd like to
> have a version number created for each new version that is displayed in the
> version list view. We will be using the following format: ** to *A to *B
> ... AB and so on. This version numbering system can be changed to a simple
> integer increment (0, 1, 2 ...) if necessary. Is this feature something
> that already exists today, or would it need to be added directly to the
> Document app?
>
> Workflows:
> I created a sample workflow with 4 states:
>
> Submitted, Level 1, Level 2, and Final Signature
>
> With these transitions:
>
> To Level 1: Submitted -> Level 1
> To Level 2: Level 1 -> Level 2
> To Final Signature: Level 2 -> Final Signature
>
> However, it seems that this workflow can't be assigned optionally on a per
> document basis. It seems it just applied to all document types. Also, I
> don't see an owner that I can assign to each state. For an example
> workflow, we would need to assign a specific user to sign the document and
> that person would sign by advancing the state to the next level. Ideally
> there would be an approve button to do this for ease of use. However, that
> is not a requirement. So far, I don't see where I can assign users to a
> workflow at all?
>
> Access Control Lists:
>
> We have documents that are considered confidential and have a list of
> people that are allowed to view them. I reviewed the access control lists
> feature but it appears that I can't make a document viewable by a list of
> users. Can you explain how this feature works? Would it allow creating a
> list of users that consists of both a predefined group (Example:
> Management) and a User (Example: Employee)?
>
> Lastly,
> I would like to create a document number reservation to allow a document
> number to be added to the document before uploading. I am using the
> Document_renaming app to change the label of a document (this is our
> document number). We have specs and memos. Memos are always written by the
> same author and so the next incremental number is obvious. Our specs are
> written by many users so the next document would not be known ahead of
> time. Since we commonly include this document number in the footer of our
> documents, we need to reserver a spec. I assume this would be a custom app,
> but I wonder if many parts of the Checkouts app could be reused?
>
>
> Rachael
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Mayan EDMS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"Mayan EDMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
