Document spell check and format cleanup. Small content fixes.
This commit is contained in:
Roberto Rosario
@@ -22,16 +22,16 @@ or startup problems.
|
||||
|
||||
Frontend UI
|
||||
-----------
|
||||
The frontend UI HTML has been refactored to use Bootstrap. Along with this
|
||||
The frontend UI HTML has been re-factored to use Bootstrap. Along with this
|
||||
update a lot of legacy HTML and CSS was removed, greatly simplifying the
|
||||
existing template and allowing the removal of some.
|
||||
|
||||
Theming and rebranding
|
||||
Theming and re-branding
|
||||
----------------------
|
||||
All the presentation logic and markup has been moved into it's own app, the
|
||||
'appearance' app. All modifications required to customize the entire look of
|
||||
the **Mayan EDMS** can now be done in a single app. Very little markup remains
|
||||
in the other apps, and it's usually because of necesity, namely the widgets.py
|
||||
in the other apps, and it's usually because of necessity, namely the widgets.py
|
||||
modules.
|
||||
|
||||
Improved page navigation interface
|
||||
@@ -52,7 +52,7 @@ system that favor font icon was added.
|
||||
|
||||
Document preview generation
|
||||
---------------------------
|
||||
The image conversion system was refactored from the ground up and uses a much
|
||||
The image conversion system was re-factored from the ground up and uses a much
|
||||
smarted caching system. The document image cache has it's own Django file
|
||||
storage driver and no longer default to the system /tmp directory. By moving
|
||||
the document image cache to a Django file storage, the cache doesn't need to
|
||||
@@ -97,7 +97,7 @@ app are no longer required. These are:
|
||||
* sendfile
|
||||
* slate
|
||||
|
||||
ACL system refactor
|
||||
ACL system re-factor
|
||||
-------------------
|
||||
The Access Control System has been greatly simplified and optimized. The
|
||||
logistics to grant and revoke permissions are now as follows: Only Roles can
|
||||
@@ -131,12 +131,12 @@ document types is the new recommended method.
|
||||
Removal of anonymous user support
|
||||
---------------------------------
|
||||
Allowing anonymous users access to your document repository is no longer
|
||||
support. Admininstrator wanting to make a group of documents public are
|
||||
support. Administrators wanting to make a group of documents public are
|
||||
encouraged to create an user, group and role for that purpose.
|
||||
|
||||
Metadata validators refactor
|
||||
Metadata validators re-factor
|
||||
----------------------------
|
||||
The metadata validator have been splitted into: Validators and Parsers.
|
||||
The metadata validators have been split into: Validators and Parsers.
|
||||
Validators will just check that the input value conforms to certain
|
||||
specification, raising a validation error is not and blocking the user from
|
||||
submitting data. The Parsers will transform user input and store the result as
|
||||
@@ -211,7 +211,7 @@ failure tolerance: https://pypi.python.org/pypi/django-sabot
|
||||
|
||||
RGB tags
|
||||
--------
|
||||
Previously tags could only choose from a predertermined number of color. This
|
||||
Previously tags could only choose from a predetermined number of color. This
|
||||
release changes that and tags be of any color. Tags now store the color
|
||||
selected in HTML RGB format. Existing tags are automatically converted to this
|
||||
new scheme.
|
||||
@@ -225,10 +225,10 @@ default document type and default document source are both called 'Default'.
|
||||
|
||||
Link unbinding
|
||||
--------------
|
||||
Suppport for allowing 3rd party apps to unbind links binded by the core apps
|
||||
Support for allowing 3rd party apps to unbind links binded by the core apps
|
||||
was added to further improve re-branding and customization.
|
||||
|
||||
Statistics refactor
|
||||
Statistics re-factor
|
||||
-------------------
|
||||
Statistics gathering and generation has been overhauled to allow for the
|
||||
creation of scheduled statistics. This allows statistics computation to be
|
||||
@@ -287,7 +287,7 @@ Admin changes
|
||||
Installation admins are no longer required to have the `superusers` or `staff`
|
||||
Django account flags. All setup tasks are now governed by a permission which
|
||||
can be assigned to a role. This creates a clear separation between an install
|
||||
administrator and the server administrator in which the installtion was
|
||||
administrator and the server administrator in which the installation was
|
||||
performed.
|
||||
|
||||
OCR functions split
|
||||
@@ -318,7 +318,7 @@ Other changes
|
||||
|
||||
* Merge of document_print and document_hard_copy views.
|
||||
* New class based and menu based navigation system.
|
||||
* Repurpose the installtion app.
|
||||
* Re-purpose the installation app.
|
||||
* New class based transformations.
|
||||
* Usage of Font Awesome icons set.
|
||||
* Move document text content display code to the OCR app.
|
||||
@@ -351,7 +351,7 @@ Other changes
|
||||
* default_app_config for each app.
|
||||
* Natural key support for many models allowing database migrations using dumped data.
|
||||
* Separate documentation requirements file to allow for contributor who only want to work on documentation.
|
||||
* Centralized testing with a new managament command, `runtests`.
|
||||
* Centralized testing with a new management command, `runtests`.
|
||||
* Addition of a tox configuration.
|
||||
* Email test body capture.
|
||||
* Email subject and from values storage.
|
||||
@@ -379,7 +379,7 @@ Using PIP
|
||||
|
||||
Type in the console::
|
||||
|
||||
$ pip install mayan-edms==2.0
|
||||
$ pip install -U mayan-edms
|
||||
|
||||
the requirements will also be updated automatically.
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ App modules
|
||||
|
||||
- events.py
|
||||
|
||||
Define event class instances that are later commited to a log by custom
|
||||
Define event class instances that are later committed to a log by custom
|
||||
code.
|
||||
|
||||
- exceptions.py
|
||||
@@ -55,7 +55,7 @@ App modules
|
||||
- handlers.py
|
||||
|
||||
Contains the signal handlers, functions that will process a given signal
|
||||
emited from this or other apps. Connect the handler functions to the
|
||||
emitted from this or other apps. Connect the handler functions to the
|
||||
corresponding signal in the ready() method of the MayanAppConfig subclass in
|
||||
apps.py
|
||||
|
||||
@@ -98,7 +98,7 @@ App modules
|
||||
|
||||
- settings.py
|
||||
|
||||
Define the config settings instances that the app will use.
|
||||
Define the configuration settings instances that the app will use.
|
||||
|
||||
- signals.py
|
||||
|
||||
|
||||
@@ -12,11 +12,12 @@ Mailing list
|
||||
------------
|
||||
|
||||
Search for information in the `archives of the mayan-edms mailing list`_, or
|
||||
`post a question`_. If you prefer news servers, use the gateway provided by Gmane_.
|
||||
`post a question`_. If you prefer news servers, use the gateway provided by
|
||||
Gmane_.
|
||||
|
||||
**Mayan EDMS** community developers do their best to reply to basic questions.
|
||||
Be sure to check the list archives as it may already containt the answers to your
|
||||
questions.
|
||||
Be sure to check the list archives as it may already containt the answers to
|
||||
your questions.
|
||||
|
||||
Twitter
|
||||
-------
|
||||
|
||||
@@ -8,7 +8,8 @@ Contributors
|
||||
How to contribute?
|
||||
------------------
|
||||
|
||||
You can help further the development of **Mayan EDMS** by testing, reporting bugs, submitting documentation or code patches.
|
||||
You can help further the development of **Mayan EDMS** by testing, reporting
|
||||
bugs, submitting documentation or code patches.
|
||||
|
||||
Lead developer
|
||||
--------------
|
||||
|
||||
@@ -5,9 +5,9 @@ Deploying
|
||||
Like other Django based projects **Mayan EDMS** can be deployed in a wide variety
|
||||
of ways. The method provided below is only a bare minimum example.
|
||||
These instructions are independent of the instructions mentioned in the
|
||||
:doc:`installation` chapter but asume you have already made a test install to
|
||||
test the compability of your operating system. These instruction are for Ubuntu
|
||||
15.04.
|
||||
:doc:`installation` chapter but assume you have already made a test install to
|
||||
test the compatibility of your operating system. These instruction are for
|
||||
Ubuntu 15.04.
|
||||
|
||||
Switch to superuser::
|
||||
|
||||
@@ -15,7 +15,10 @@ Switch to superuser::
|
||||
|
||||
Install all system dependencies::
|
||||
|
||||
apt-get install nginx supervisor redis-server postgresql libpq-dev libjpeg-dev libmagic1 libpng-dev libreoffice libtiff-dev gcc ghostscript gpgv python-dev python-virtualenv tesseract-ocr unpaper poppler-utils -y
|
||||
apt-get install nginx supervisor redis-server postgresql \
|
||||
libpq-dev libjpeg-dev libmagic1 libpng-dev libreoffice \
|
||||
libtiff-dev gcc ghostscript gpgv python-dev python-virtualenv \
|
||||
tesseract-ocr unpaper poppler-utils -y
|
||||
|
||||
Change the directory to where the project will be deployed::
|
||||
|
||||
@@ -33,9 +36,9 @@ Install Mayan EDMS::
|
||||
|
||||
pip install mayan-edms
|
||||
|
||||
Install the Python client for Redis, uWSGI, and PostgreSQL::
|
||||
Install the Python client for PostgreSQL, Redis, and uWSGI::
|
||||
|
||||
pip install redis uwsgi psycopg2
|
||||
pip install psycopg2 redis uwsgi
|
||||
|
||||
Create the database for installation::
|
||||
|
||||
|
||||
@@ -19,18 +19,28 @@ Project philosophies
|
||||
How to think about **Mayan EDMS** when doing changes or adding new features,
|
||||
why things are the way they are in **Mayan EDMS**.
|
||||
|
||||
- Functionality must be as market/sector independent as possible, code for the 95% of use cases.
|
||||
- Each user must be able to configure and customize it to their needs after install.
|
||||
- Abstract as much as possible, each app must be an expert in just one thing, for other things they should use the API/classes/functions of other apps.
|
||||
- Assume as little as possible about anything outside the project (hardware, OS, storage).
|
||||
- Provide Python based abstraction so that a default install runs with a single step.
|
||||
- Functionality must be as market/sector independent as possible, code for the
|
||||
95% of use cases.
|
||||
- Each user must be able to configure and customize it to their needs after
|
||||
install.
|
||||
- Abstract as much as possible, each app must be an expert in just one thing,
|
||||
for other things they should use the API/classes/functions of other apps.
|
||||
- Assume as little as possible about anything outside the project
|
||||
(hardware, OS, storage).
|
||||
- Provide Python based abstraction so that a default install runs with a single
|
||||
step.
|
||||
- No hard dependencies on binaries unless there is no other choice.
|
||||
- Provide “drivers” or switchable backends to allow users to fine tune the installation.
|
||||
- Call to binaries only when there is no other choice or the Python choices are not viable/mature/efficient.
|
||||
- Each app is as independent and self contained as possible. Exceptions, the basic requirements: navigation, permissions, common, main.
|
||||
- If an app is meant to be used by more than one other app it should be as generic as possible in regard to the project and another app will bridge the functionality.
|
||||
- Provide “drivers” or switchable backends to allow users to fine tune the
|
||||
installation.
|
||||
- Call to binaries only when there is no other choice or the Python choices are
|
||||
not viable/mature/efficient.
|
||||
- Each app is as independent and self contained as possible. Exceptions, the
|
||||
basic requirements: navigation, permissions, common, main.
|
||||
- If an app is meant to be used by more than one other app it should be as
|
||||
generic as possible in regard to the project and another app will bridge the functionality.
|
||||
|
||||
- Example: since indexing (document_indexing) only applies to documents, the app is specialized and dependant on the documents app.
|
||||
- Example: since indexing (document_indexing) only applies to documents, the
|
||||
app is specialized and depends on the documents app.
|
||||
|
||||
|
||||
Coding conventions
|
||||
@@ -162,7 +172,7 @@ Classes:
|
||||
Strings
|
||||
~~~~~~~
|
||||
Quotation character used in **Mayan EDMS** for strings is the single quote.
|
||||
Double quote is used for multiline comments or HTML markup.
|
||||
Double quote is used for multiple line comments or HTML markup.
|
||||
|
||||
Migrations
|
||||
~~~~~~~~~~
|
||||
@@ -174,7 +184,7 @@ General
|
||||
Code should appear in their modules in alphabetic order or in their order of
|
||||
importance if it makes more sense for the specific application. This makes
|
||||
visual scanning easier on modules with a large number of imports, views or
|
||||
classes. Class methods that return a value should be prepended with a
|
||||
classes. Class methods that return a value should be pretended with a
|
||||
``get_`` to differentiate from an object’s properties. When a variable refers
|
||||
to a file it should be named as follows:
|
||||
|
||||
@@ -199,7 +209,8 @@ The project is publicly accessible, hosted and can be cloned from **GitLab** usi
|
||||
Git branch structure
|
||||
--------------------
|
||||
|
||||
**Mayan EDMS** follows simplified model layout by Vincent Driessen in his `Successful Git Branching Model`_ blog post. Git-flow_ is a great tool for managing the repository in this way.
|
||||
**Mayan EDMS** follows a simplified model layout based on Vincent Driessen's
|
||||
`Successful Git Branching Model`_ blog post.
|
||||
|
||||
``develop``
|
||||
The "next release" branch, likely unstable.
|
||||
@@ -218,7 +229,6 @@ prior to opening a Merge Request on GitLab_.
|
||||
|
||||
.. _Git: http://git-scm.org
|
||||
.. _`Successful Git Branching Model`: http://nvie.com/posts/a-successful-git-branching-model/
|
||||
.. _git-flow: https://github.com/nvie/gitflow
|
||||
|
||||
|
||||
Steps to deploy a development version
|
||||
@@ -373,7 +383,7 @@ Installable package
|
||||
Source file package
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This is the sequence of step I use to produce an installable package:
|
||||
This is the sequence of step used to produce an installable package:
|
||||
|
||||
1. Make sure there are no lingering packages from previous attempts::
|
||||
|
||||
@@ -396,9 +406,9 @@ This is the sequence of step I use to produce an installable package:
|
||||
Wheel package
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
1. Install wheel::
|
||||
1. Install the development requirements::
|
||||
|
||||
$ pip install wheel
|
||||
$ pip install -r requirements/development.txt
|
||||
|
||||
2. Create wheel package using the source file package (Until issue #99 of wheel is fixed: https://bitbucket.org/pypa/wheel/issue/99/cannot-exclude-directory)::
|
||||
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
Document types
|
||||
==============
|
||||
|
||||
The basic unit of data in **Mayan EDMS** is the ``document type``. A document type
|
||||
can be interpreted also as a document category, a document class, or a
|
||||
The basic unit of data in **Mayan EDMS** is the ``document type``. A document
|
||||
type can be interpreted also as a document category, a document class, or a
|
||||
document template. Document types need to be created before documents can be
|
||||
uploaded. It is not possible to upload documents without assigning them a
|
||||
document type. Examples of document type: **invoices**, **blueprints**,
|
||||
|
||||
@@ -4,7 +4,8 @@ Features
|
||||
|
||||
* :doc:`Document versioning <../topics/versioning>`.
|
||||
|
||||
* Store many versions of the same document, download or revert to a previous version.
|
||||
* Store many versions of the same document, download or revert to a previous
|
||||
version.
|
||||
|
||||
* :doc:`Electronic signature verification <../topics/signatures>`.
|
||||
|
||||
@@ -18,39 +19,48 @@ Features
|
||||
|
||||
* Office document format support.
|
||||
|
||||
* **Mayan EDMS** can detect the presence of Libre Office and use it to support word processing files, spreadsheets and presentations.
|
||||
* **Mayan EDMS** can detect the presence of Libre Office and use it to support
|
||||
word processing files, spreadsheets and presentations.
|
||||
|
||||
* User defined metadata fields.
|
||||
|
||||
* Several metadata fields can be matched to a document type as per technical, legal or structural requirements such as the `Dublin core`_.
|
||||
* Several metadata fields can be matched to a document type as per technical,
|
||||
legal or structural requirements such as the `Dublin core`_.
|
||||
|
||||
* Dynamic default values for metadata.
|
||||
|
||||
* Metadata fields can have an initial value, which can be static or determined by an user provided template code snippet.
|
||||
* Metadata fields can have an initial value, which can be static or determined
|
||||
by an user provided template code snippet.
|
||||
|
||||
* Documents can be uploaded from different sources.
|
||||
|
||||
* Local file or server side file uploads, multifunctional copier, or even via email.
|
||||
* Local file or server side file uploads, multifunctional copier, or even via
|
||||
email.
|
||||
|
||||
* Batch upload many documents with the same metadata.
|
||||
|
||||
* Clone a document's metadata for speedier uploads and eliminate repetitive data entry.
|
||||
* Clone a document's metadata for speedier uploads and eliminate repetitive
|
||||
data entry.
|
||||
|
||||
* Previews for a great deal of image formats.
|
||||
* Previews for many file formats.
|
||||
|
||||
* **Mayan EDMS** provides document image preview generation for many popular file formats.
|
||||
* **Mayan EDMS** provides image preview generation for many popular file
|
||||
formats.
|
||||
|
||||
* Full text searching.
|
||||
|
||||
* Documents can be searched by their text content, their metadata or any other file attribute such as name, extension, etc.
|
||||
* Documents can be searched by their text content, their metadata or any other
|
||||
file attribute such as name, extension, etc.
|
||||
|
||||
* Configurable document grouping.
|
||||
|
||||
* Automatic linking of documents based on metadata values or document properties.
|
||||
* Automatic linking of documents based on metadata values or document
|
||||
properties.
|
||||
|
||||
* :doc:`Roles support <../topics/permissions>`.
|
||||
|
||||
* It is possible to create an unlimited amount of different roles not being restricted to the traditional admin, operator, guest paradigm.
|
||||
* It is possible to create an unlimited amount of different roles not being
|
||||
restricted to the traditional admin, operator, guest paradigm.
|
||||
|
||||
* :doc:`Fine grained permissions system <../topics/permissions>`.
|
||||
|
||||
@@ -62,20 +72,25 @@ Features
|
||||
|
||||
* Automatic OCR processing.
|
||||
|
||||
* The task of transcribing text from documents via OCR can be distributed among several physical or virtual computers to decrease load and increase availability.
|
||||
* The task of transcribing text from documents via OCR can be distributed
|
||||
among several physical or virtual computers to decrease load and increase
|
||||
availability.
|
||||
|
||||
* Multilingual user interface.
|
||||
|
||||
* **Mayan EDMS** being written using the Django_ framework, can be translated to practically any language spoken in the world.
|
||||
For a list of translated languages have a look at the Transifex_ project location.
|
||||
* **Mayan EDMS** being written using the Django_ framework, can be translated
|
||||
to practically any language spoken in the world. For a list of translated
|
||||
languages have a look at the Transifex_ project location.
|
||||
|
||||
* Multilingual OCR support.
|
||||
|
||||
* Current language of the document is passed to the corresponding OCR engine to increase the rate of data vs. recognition errors.
|
||||
* The current language of the document is passed to the corresponding OCR
|
||||
engine to increase the text recognition rate.
|
||||
|
||||
* :doc:`Plugable storage backends <../topics/file_storage>`.
|
||||
|
||||
* Very easy to use 3rd party plugins such as the ones available for Amazon EC2.
|
||||
* It is very easy to use 3rd party plugins such as the ones available for
|
||||
Amazon EC2.
|
||||
|
||||
* Color coded tagging.
|
||||
|
||||
@@ -83,7 +98,8 @@ Features
|
||||
|
||||
* Workflows.
|
||||
|
||||
* Keep track of the state a document, along with the log of the previous state changes.
|
||||
* Keep track of the state of documents, along with the log of the previous
|
||||
state changes.
|
||||
|
||||
|
||||
.. _`Dublin core`: http://dublincore.org/metadata-basics/
|
||||
|
||||
@@ -25,4 +25,4 @@ storage in this case is decoupled and its behavior is controlled
|
||||
not by the project but by the ``Storage`` module class. All the other
|
||||
modules don't make any assumptions about how the actual document files are
|
||||
stored. This way files can be saved locally, over the network or even across
|
||||
the internet and everything will still operate exactly the same.
|
||||
the Internet and everything will still operate exactly the same.
|
||||
|
||||
@@ -7,7 +7,7 @@ relation to their properties (:doc:`metadata`, label, MIME type, etc). To use
|
||||
indexes you need to first create an index template. Once created, associate
|
||||
the index to one or more :doc:`document_types`.
|
||||
|
||||
Index are hierachical models so a tree template needs to be specified for them.
|
||||
Index are hierarchical models so a tree template needs to be specified for them.
|
||||
This tree template will contain references to document metadata or properties
|
||||
that will be replaced with the actual value for those metadata or properties.
|
||||
|
||||
|
||||
@@ -17,7 +17,8 @@ Binary dependencies
|
||||
Ubuntu
|
||||
------
|
||||
|
||||
If using a Debian_ or Ubuntu_ based Linux distribution, get the executable requirements using::
|
||||
If using a Debian_ or Ubuntu_ based Linux distribution, get the executable
|
||||
requirements using::
|
||||
|
||||
sudo apt-get install libjpeg-dev libmagic1 libpng-dev libreoffice libtiff-dev gcc ghostscript gpgv python-dev python-virtualenv tesseract-ocr unpaper poppler-utils -y
|
||||
|
||||
@@ -25,7 +26,7 @@ If using a Debian_ or Ubuntu_ based Linux distribution, get the executable requi
|
||||
Mac OSX
|
||||
-------
|
||||
|
||||
**Mayan EDMS** is dependant on a number of binary packages and the recommended
|
||||
**Mayan EDMS** is dependent on a number of binary packages and the recommended
|
||||
way is to use a package manager such as `MacPorts <https://www.macports.org/>`_
|
||||
or `Homebrew <http://brew.sh/>`_.
|
||||
|
||||
@@ -37,7 +38,9 @@ With MacPorts installed run the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo port install python-dev gcc tesseract-ocr unpaper python-virtualenv ghostscript libjpeg-dev libpng-dev poppler-utils
|
||||
sudo port install python-dev gcc tesseract-ocr unpaper \
|
||||
python-virtualenv ghostscript libjpeg-dev libpng-dev \
|
||||
poppler-utils
|
||||
|
||||
Set the Binary paths
|
||||
********************
|
||||
|
||||
@@ -9,7 +9,7 @@ document types. Then when a document is uploaded, a value for that metadata
|
||||
can be entered. There are two kinds of metadata type to document type relations:
|
||||
optional and required. When a metadata type is optional for a document type,
|
||||
it can be left blank for a document being uploaded and the upload will still
|
||||
be successfull. On the other hand required metadata type must be given a value
|
||||
be successful. On the other hand required metadata type must be given a value
|
||||
or it will not be possible to upload the document at hand.
|
||||
|
||||
Examples of metadata type: Invoice number, color, employee id.
|
||||
@@ -19,10 +19,10 @@ The data entry of metadata types can be set to allow any value to be provided
|
||||
configuration option and users will be presented with a drop down list of options
|
||||
instead of the default text entry box.
|
||||
|
||||
If metadata types are setup to allow any value to be entered a ``validation`` option
|
||||
can be choosen to block the entry of invalid data. Metadata types also provide
|
||||
``parsers`` which will not block the entry of data but are able to interpret and
|
||||
modify the value provided by the user to a conform to a specific format.
|
||||
An example of a provided parser is the date parser which will interpret and
|
||||
correct dates provided by users regardless of the format in which they are
|
||||
If metadata types are setup to allow any value to be entered a ``validation``
|
||||
option can be chosen to block the entry of invalid data. Metadata types also
|
||||
provide ``parsers`` which will not block the entry of data but are able to
|
||||
interpret and modify the value provided by the user to a conform to a specific
|
||||
format. An example of a provided parser is the date parser which will interpret
|
||||
and correct dates provided by users regardless of the format in which they are
|
||||
entered.
|
||||
|
||||
@@ -3,9 +3,9 @@ Permissions
|
||||
===========
|
||||
|
||||
**Mayan EDMS** provides very fine control over which actions users can
|
||||
perform. Action control works by allowing ``roles``, that are composed of ``groups``
|
||||
of ``users`` to be granted a ``permission`` such that the holder of that permission
|
||||
can exercise it throughout the entire system.
|
||||
perform. Action control works by allowing ``roles``, that are composed of
|
||||
``groups`` of ``users`` to be granted a ``permission`` such that the holder of
|
||||
that permission can exercise it throughout the entire system.
|
||||
|
||||
.. blockdiag::
|
||||
|
||||
@@ -19,8 +19,7 @@ can exercise it throughout the entire system.
|
||||
user -> group -> role <- permission;
|
||||
}
|
||||
|
||||
In other words, users themselves
|
||||
can't hold a permission, permissions are granted only to roles. Users can't
|
||||
directly belong to a role, they can only belong to a group. Groups can be
|
||||
members of roles. Roles are system permission units and groups are
|
||||
business organizational units.
|
||||
In other words, users themselves can't hold a permission, permissions are
|
||||
granted only to roles. Users can't directly belong to a role, they can only
|
||||
belong to a group. Groups can be members of roles. Roles are system permission
|
||||
units and groups are business organizational units.
|
||||
|
||||
@@ -13,7 +13,7 @@ Smart links are rule based, but don't create any organizational structure.
|
||||
Smart links just show the documents that match the rules as evaluated against
|
||||
the metadata or properties of the currently displayed document.
|
||||
|
||||
Indexes are automatic hierachical units used to group documents, smart links
|
||||
Indexes are automatic hierarchical units used to group documents, smart links
|
||||
are automatic references between documents.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -6,13 +6,22 @@ Document sources define places from which documents can be uploaded or gathered.
|
||||
|
||||
The current document sources supported are:
|
||||
|
||||
- Web - ``HTML`` forms with a ``Browse`` button that will open the file dialog when clicked to allow selection of files in the user's computer to be uploaded as documents.
|
||||
- Staging folder - Folder where networked attached scanned can save image files. The files in these staging folders are scanned and a preview is generated to help the process of upload.
|
||||
- POP3 email - Provide the email, server and credential of a ``POP3`` based email to be scanned periodically for email. The body of the email is uploaded as a document and the attachments of the email are uploaded as separate documents.
|
||||
- IMAP email - Same as the ``POP3`` email source but for email accounts using the ``IMAP`` protocol.
|
||||
- Watch folder - A filesystem folder that is scanned periodically for files. Any file in the watch folder is automaticall uploaded.
|
||||
- Web - ``HTML`` forms with a ``Browse`` button that will open the file dialog
|
||||
when clicked to allow selection of files in the user's computer to be
|
||||
uploaded as documents.
|
||||
- Staging folder - Folder where networked attached scanned can save image
|
||||
files. The files in these staging folders are scanned and a preview is
|
||||
generated to help the process of upload.
|
||||
- POP3 email - Provide the email, server and credential of a ``POP3`` based
|
||||
email to be scanned periodically for email. The body of the email is uploaded
|
||||
as a document and the attachments of the email are uploaded as separate
|
||||
documents.
|
||||
- IMAP email - Same as the ``POP3`` email source but for email accounts using
|
||||
the ``IMAP`` protocol.
|
||||
- Watch folder - A filesystem folder that is scanned periodically for files.
|
||||
Any file in the watch folder is automatically uploaded.
|
||||
|
||||
Document source can be configure to allow document bundles to uploaded as
|
||||
compressed files which are decompressed and their content uploaded as separate
|
||||
documents. This feature is usefull when migrating from another document
|
||||
documents. This feature is useful when migrating from another document
|
||||
manager system.
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
Tags
|
||||
====
|
||||
|
||||
Tags allow giving documents a toggable property. Documents can also be tagged
|
||||
with more than one tag. Once tagged, documents can be searched also by their tags
|
||||
and from the tags main menu a list of all the documents with a particular tag
|
||||
can be obtained easily. Aside from their texts, tags can be assigned a particular
|
||||
color.
|
||||
Tags allow giving documents a binary property. Documents can also be tagged
|
||||
with more than one tag. Once tagged, documents can be searched also by their
|
||||
tags and from the tags main menu a list of all the documents with a particular
|
||||
tag can be obtained easily. Aside from their texts, tags can be assigned a
|
||||
particular color.
|
||||
|
||||
@@ -2,10 +2,10 @@
|
||||
Transformations
|
||||
===============
|
||||
|
||||
Transformation are persistent manipulations to the previews of the stored documents.
|
||||
For example: a scanning equipment may only produce landscape PDFs.
|
||||
Transformation are persistent manipulations to the previews of the stored
|
||||
documents. For example: a scanning equipment may only produce landscape PDFs.
|
||||
In this case an useful transformation for that document source would be to
|
||||
rotate all documents scanned by 270 degress after being uploaded, this way
|
||||
rotate all documents scanned by 270 degrees after being uploaded, this way
|
||||
whenever a document is uploaded from that scanner it will appear in portrait
|
||||
orientation. Transformations do not physically modify the document file but
|
||||
are just associated with the document's temporary graphical representation.
|
||||
|
||||
@@ -10,8 +10,8 @@ respective language in which you are interested.
|
||||
|
||||
Feel free to open translation issues inside **Transifex** itself if you have a
|
||||
question about the usage or meaning of a source text string. If you open a
|
||||
translation issue, it will be your resposibility to close it after you get an
|
||||
translation issue, it will be your responsibility to close it after you get an
|
||||
answers that satisfies your question. Administrator will not close new issues
|
||||
as they have no way to determine if your question has been properly answered.
|
||||
However to avoid cluter, answered questions will be scanned periodically and
|
||||
However to avoid clutter, answered questions will be scanned periodically and
|
||||
closed if no activity is observed from the original poster in a period of time.
|
||||
|
||||
@@ -5,8 +5,8 @@ Document versioning
|
||||
**Mayan EDMS** has the ability to store different versions of the same
|
||||
document. A comment field is provided to allow users to summarize the new
|
||||
version changes in comparison with the previous one. If a new version was
|
||||
uploded by mistake or such new version is no longer necessary the option to
|
||||
uploaded by mistake or such new version is no longer necessary the option to
|
||||
revert to a previous version of the document is provided.
|
||||
|
||||
Only the interactive document sources (:doc:`sources`) (``Web`` and ``Staging folders``) are
|
||||
avaiable to upload new document versions.
|
||||
available to upload new document versions.
|
||||
|
||||
Reference in New Issue
Block a user