Hi Roberto, Google Groups sent my first attempt to reply to Nirvana. :(
Thank you for your detailed answers. I apologize for my English. It is not enough to be diplomatic. No insult intended at anytime. Am Donnerstag, 20. September 2012 08:56:30 UTC+2 schrieb Roberto Rosario: > > > The main layout for every view is: main menu on top, secondary toolbar and > actions for the currently selected object in the top of the sidebar at the > right side and alternative actions at the bottom of the sidebar. To upload > a new version of a document, select a previously uploaded document, go to > the versions tab and on the bottom of the right sidebar there should be an > "upload new document version" menu entry. Yes the documentation on that > feature is a little vague. Since it takes time away from doing support > and writing code, what I usually do is take a few days prior to the > release of a new version to work on the documentation, if something didn't > make the cut it is usually added in the next release. > I found the option just minutes before my presentation about Mayan, on my 1900x1200px monitor at home the link had always been below the right bottom of the screen. > > To see if I understood correctly: Provide a PDF version of the uploaded > .docx document if the user doesn't has editing permissions? > Correct. As a comfortable alternative to do this manually. > > This can be done using the ACL (access control list) feature, where you > can restrict what actions any user can do to any specific document. You > can even set the default ACL to assign upon document creation (which > permissions to assign to the creator of the document, or any other specific > user, group of users, or role) > The Mayan's rights management is as powerful as complex. For managing it "en passant" it seems a litle too complex, e.g. providing 5 or more sites of acl, roles and group options. > > This would require a rule base system that automatically assigns tags to > document based on programmatic criteria set by de admin (kind of like the > smart link or the indexes). Something similar to this is in the TO DO list > for the next mayor version, but is not even designed yet. > To me it looks like a very important feature to give the tags not just a .png, but a meaning so you can search for all new documents, for all awaiting review and so on... > > This sort of functionality is better handled by a workflow engine like the > one being developed for Mayan, that changes the document properties and > access control list based on the used defined states of a document > (uploaded, approved, rejected). This functionality passed the design > phase and there is some model code but it is slated for the next mayor > release. > A dms always has a context in which the documents are embedded, so some rudimentary workflow managment (and "check out" certainly is a beginning) is necessary. > > This sounds like a dashboard. Removal of the current static home page > showing the pyramid logo to replace it with a dashboard is already under > way ( > https://github.com/rosarior/mayan/blob/development/docs/releases/0.13.rst), > but for inclusion on the next mayor version. > Exactly. Without one you will be lost in a jungle of documents with no clue about there status, importance etc. > Reading confirmations like email reading confirmations? > Yes. So you can monitor if a new employee has read (not understood) the essential documents e.g. to start working in an ambulance. Or who has not read an important note about misproduced drugs. > > Getting certified is not a big priority for the project at this time (at > least for me personally) because of well, personal reasons. Having tried > to get previous software certified taught me that some (if not all) > certification processes are either scams to get money and provide a false > sense of elitism for the company whose software get certified selectively > or are poorly defined that the required implementation for compliance are > very open to individual interpretation (for example check HIPAA in > regards to record privacy) or cannot be effectively implemented. Either > way they all lead down the same path: a disproportional amount of money and > time spent trying to get certified and an a selective situation where > only a specific group of software gets certified and allowed in certain > industries, even if these lack in terms of technical quality. > I would NEVER recommend anyone to certify. But in many branches you are forced more or less to certify your unit to stay in the market. So a DMS should support such needs, e.g. demanded in EN ISO 9oo1. Stefan --
