Documentation updates.
This commit is contained in:
Roberto Rosario
@@ -10,12 +10,12 @@ and installing it from PyPI with the following commands:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ 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
|
||||
$ virtualenv venv
|
||||
$ source venv/bin/activate
|
||||
$ pip install mayan-edms
|
||||
$ mayan-edms.py initialsetup
|
||||
$ mayan-edms.py runserver
|
||||
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
|
||||
virtualenv venv
|
||||
source venv/bin/activate
|
||||
pip install mayan-edms
|
||||
mayan-edms.py initialsetup
|
||||
mayan-edms.py runserver
|
||||
|
||||
Point your browser to 127.0.0.1:8000 and use the automatically created admin
|
||||
account.
|
||||
@@ -26,7 +26,6 @@ account.
|
||||
Features <topics/features>
|
||||
Installation <topics/installation>
|
||||
Deploying <topics/deploying>
|
||||
Getting started <topics/getting_started>
|
||||
Release notes and upgrading <releases/index>
|
||||
Concepts <topics/index>
|
||||
Development <topics/development>
|
||||
@@ -37,7 +36,6 @@ account.
|
||||
FAQ <topics/faq>
|
||||
Contact <topics/contact>
|
||||
|
||||
|
||||
.. _Django: http://www.djangoproject.com/
|
||||
.. _Free Open Source: http://en.wikipedia.org/wiki/Open_source
|
||||
.. _Electronic Document Management System: https://en.wikipedia.org/wiki/Document_management_system
|
||||
|
||||
@@ -36,16 +36,38 @@ would be able to view the ``2015 Payroll report.txt`` document.
|
||||
Inherited access control
|
||||
========================
|
||||
|
||||
It is also possible to grant a permission to a role for a specific document type.
|
||||
It is also possible to grant a permission to a role for a specific document type (:doc:`document_types`).
|
||||
Under this scheme all users in groups belonging to that role will inherit that
|
||||
permission for all documents of that type.
|
||||
|
||||
.. blockdiag::
|
||||
|
||||
blockdiag {
|
||||
document_type [ label = 'Document type' ];
|
||||
role [ label = 'Role' ];
|
||||
permission [ label = 'Permission' ];
|
||||
|
||||
role -> document_type <- permission;
|
||||
}
|
||||
|
||||
Example:
|
||||
|
||||
Role ``RH Supervisors`` are given the permission ``document view`` for the
|
||||
.. blockdiag::
|
||||
|
||||
blockdiag {
|
||||
document_type [ label = 'Payroll reports', width=200 ];
|
||||
role [ label = 'Accountants' ];
|
||||
permission [ label = 'View document' ];
|
||||
|
||||
role -> document_type <- permission;
|
||||
}
|
||||
|
||||
The role ``Accountants`` is given the permission ``document view`` for the
|
||||
document type ``Payroll reports``. Now all users in groups belonging to the
|
||||
``RH Supervisors`` role can view all documents of the type ``Payroll reports``
|
||||
without having to have that permissions granted for each particular Payroll report document.
|
||||
If access control for the Payroll reports documents need to be updated it only needs
|
||||
to be done for the document type class object and not for each document of the type
|
||||
Payroll report.
|
||||
``Accountants`` role can view all documents of the type ``Payroll reports``
|
||||
without needing to have that permissions granted for each particular
|
||||
``Payroll reports`` type document.
|
||||
|
||||
If access control for the ``Payroll reports`` documents needs to be updated it
|
||||
only needs to be done for the document type and not for each document of the type
|
||||
``Payroll reports``.
|
||||
|
||||
14
docs/topics/checkouts.rst
Normal file
14
docs/topics/checkouts.rst
Normal file
@@ -0,0 +1,14 @@
|
||||
=========
|
||||
Checkouts
|
||||
=========
|
||||
|
||||
Checkouts are a way to block certain accesses or actions of a document for a
|
||||
period of time.
|
||||
|
||||
An user can choose to checkout a document to work on an update and block new
|
||||
versions of that document to be uploaded by other users. Document are checked
|
||||
out for a certain amount of time and if not manually checked in by the original
|
||||
user, will be checked in automatically by the system.
|
||||
|
||||
To be able to check in documents that were checked out by other users, the
|
||||
permission 'Forcefully check in documents' is required.
|
||||
@@ -4,29 +4,160 @@ 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 asume you installed **Mayan EDMS** as mentioned in the :doc:`installation` chapter.
|
||||
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.
|
||||
|
||||
Install more system dependencies::
|
||||
Switch to superuser::
|
||||
|
||||
sudo apt-get install nginx supervisor redis-server postgresql
|
||||
sudo -i
|
||||
|
||||
- Postgresql pg_hba.conf
|
||||
- Postgresql user
|
||||
- Postgresql database
|
||||
Install all system dependencies::
|
||||
|
||||
Switch and activate the `virtualenv` where you installed **Mayan EDMS**. Install
|
||||
the Python client for redis and uWSGI::
|
||||
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
|
||||
|
||||
pip install redis uwsgi
|
||||
Change the directory to where the project will be deployed::
|
||||
|
||||
Update the settings/local.py file::
|
||||
cd /usr/share
|
||||
|
||||
Create the Python virtual environment for the installation::
|
||||
|
||||
virtualenv mayan-edms
|
||||
|
||||
Activate virtual env::
|
||||
|
||||
source mayan-edms/bin/activate
|
||||
|
||||
Install Mayan EDMS::
|
||||
|
||||
pip install mayan-edms
|
||||
|
||||
Install the Python client for Redis, uWSGI, and PostgreSQL::
|
||||
|
||||
pip install redis uwsgi psycopg2
|
||||
|
||||
Create the database for installation::
|
||||
|
||||
sudo -u postgres createuser -P mayan (provide password)
|
||||
sudo -u postgres createdb -O mayan mayan
|
||||
|
||||
Create the directories for the logs::
|
||||
|
||||
mkdir /var/log/mayan
|
||||
|
||||
Change the current directory to be the one of the installation::
|
||||
|
||||
cd mayan-edms
|
||||
|
||||
Make a convenience symlink::
|
||||
|
||||
ln -s lib/python2.7/site-packages/mayan .
|
||||
|
||||
Create an initial settings file::
|
||||
|
||||
mayan-edms.py createsettings
|
||||
|
||||
Update the ``mayan/settings/local.py`` file::
|
||||
|
||||
DATABASES = {
|
||||
'default': {
|
||||
'ENGINE': 'django.db.backends.postgresql_psycopg2',
|
||||
'NAME': 'mayan',
|
||||
'USER': 'mayan',
|
||||
'PASSWORD': '<password used when creating postgreSQL user>',
|
||||
'HOST': 'localhost',
|
||||
'PORT': '5432',
|
||||
}
|
||||
}
|
||||
|
||||
BROKER_URL = 'redis://127.0.0.1:6379/0'
|
||||
CELERY_ALWAYS_EAGER = False
|
||||
CELERY_RESULT_BACKEND = 'redis://127.0.0.1:6379/0'
|
||||
|
||||
Migrate the database or initialize the project::
|
||||
|
||||
- NGINX site
|
||||
- SUPERVISOR uwsgi
|
||||
- SUPERVISOR worker
|
||||
mayan-edms.py initialsetup
|
||||
|
||||
Disable the default NGINX site::
|
||||
|
||||
rm /etc/nginx/sites-enabled/default
|
||||
|
||||
Create the NGINX site file for Mayan EDMS, ``/etc/nginx/site-available/mayan``::
|
||||
|
||||
server {
|
||||
listen 80;
|
||||
server_name localhost;
|
||||
|
||||
location / {
|
||||
include uwsgi_params;
|
||||
uwsgi_pass unix:/usr/share/mayan-edms/uwsgi.sock;
|
||||
|
||||
client_max_body_size 30M; # Increse if your plan to upload bigger documents
|
||||
proxy_read_timeout 30s; # Increase if your document uploads take more than 30 seconds
|
||||
}
|
||||
|
||||
location /static {
|
||||
alias /usr/share/mayan-edms/mayan/media/static;
|
||||
expires 1h;
|
||||
}
|
||||
|
||||
location /favicon.ico {
|
||||
alias /usr/share/mayan-edms/mayan/media/static/appearance/images/favicon.ico;
|
||||
expires 1h;
|
||||
}
|
||||
}
|
||||
|
||||
Enable the NGINX site for Mayan EDMS::
|
||||
|
||||
ln -s /etc/nginx/sites-available/mayan /etc/nginx/sites-enabled/
|
||||
|
||||
Create the supervisor file for the uWSGI process, ``/etc/supervisor/conf.d/mayan-uwsgi.conf``::
|
||||
|
||||
[program:mayan-uwsgi]
|
||||
command = /usr/share/mayan-edms/bin/uwsgi --ini /usr/share/mayan-edms/uwsgi.ini
|
||||
user = root
|
||||
autostart = true
|
||||
autorestart = true
|
||||
redirect_stderr = true
|
||||
|
||||
Create the supervisor file for the Celery worker, ``/etc/supervisor/conf.d/mayan-celery.conf``::
|
||||
|
||||
[program:mayan-worker]
|
||||
command = /usr/share/mayan-edms/bin/python /usr/share/mayan-edms/bin/mayan-edms.py celery --settings=mayan.settings.production worker -Ofair -l ERROR
|
||||
directory = /usr/share/mayan-edms
|
||||
user = www-data
|
||||
stdout_logfile = /var/log/mayan/worker-stdout.log
|
||||
stderr_logfile = /var/log/mayan/worker-stderr.log
|
||||
autostart = true
|
||||
autorestart = true
|
||||
startsecs = 10
|
||||
stopwaitsecs = 10
|
||||
killasgroup = true
|
||||
priority = 998
|
||||
|
||||
[program:mayan-beat]
|
||||
command = /usr/share/mayan-edms/bin/python /usr/share/mayan-edms/bin/mayan-edms.py celery --settings=mayan.settings.production beat -l ERROR
|
||||
directory = /usr/share/mayan-edms
|
||||
user = www-data
|
||||
numprocs = 1
|
||||
stdout_logfile = /var/log/mayan/beat-stdout.log
|
||||
stderr_logfile = /var/log/mayan/beat-stderr.log
|
||||
autostart = true
|
||||
autorestart = true
|
||||
startsecs = 10
|
||||
stopwaitsecs = 1
|
||||
killasgroup = true
|
||||
priority = 998
|
||||
|
||||
Collect the static files::
|
||||
|
||||
mayan-edms.py collectstatic --noinput
|
||||
|
||||
Make the installation directory readable and writable by the webserver user::
|
||||
|
||||
chown www-data:www-data /usr/share/mayan-edms -R
|
||||
|
||||
Restart the services::
|
||||
|
||||
/etc/init.d/nginx restart
|
||||
/etc/init.d/supervisor restart
|
||||
|
||||
@@ -193,7 +193,7 @@ Source Control
|
||||
|
||||
The project is publicly accessible, hosted and can be cloned from **GitLab** using::
|
||||
|
||||
$ git clone https://gitlab.com/mayan-edms/mayan-edms.git
|
||||
git clone https://gitlab.com/mayan-edms/mayan-edms.git
|
||||
|
||||
|
||||
Git branch structure
|
||||
@@ -225,14 +225,14 @@ Steps to deploy a development version
|
||||
-------------------------------------
|
||||
.. code-block:: bash
|
||||
|
||||
$ git clone https://gitlab.com/mayan-edms/mayan-edms.git
|
||||
$ cd mayan-edms
|
||||
$ git checkout development
|
||||
$ virtualenv venv
|
||||
$ source venv/bin/activate
|
||||
$ pip install -r requirements.txt
|
||||
$ ./manage.py initialsetup
|
||||
$ ./manage.py runserver
|
||||
git clone https://gitlab.com/mayan-edms/mayan-edms.git
|
||||
cd mayan-edms
|
||||
git checkout development
|
||||
virtualenv venv
|
||||
source venv/bin/activate
|
||||
pip install -r requirements.txt
|
||||
./manage.py initialsetup
|
||||
./manage.py runserver
|
||||
|
||||
|
||||
Setting up a development version using Vagrant
|
||||
@@ -244,14 +244,14 @@ Start and provision a machine using:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ vagrant up
|
||||
vagrant up
|
||||
|
||||
To launch a standalone development server
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ vagrant ssh
|
||||
vagrant ssh
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ cd ~/mayan-edms/
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ source venv/bin/activate
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ ./manage.py runserver 0.0.0.0:8000
|
||||
@@ -261,7 +261,7 @@ To launch a development server with a celery worker and Redis as broker
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ vagrant ssh
|
||||
vagrant ssh
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ cd ~/mayan-edms/
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ source venv/bin/activate
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ ./manage.py runserver 0.0.0.0:8000 --settings=mayan.settings.celery_redis
|
||||
@@ -270,7 +270,7 @@ Then on a separate console launch a celery worker from the same provisioned Vagr
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ vagrant ssh
|
||||
vagrant ssh
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ cd ~/mayan-edms/
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ source venv/bin/activate
|
||||
vagrant@vagrant-ubuntu-trusty-32:~$ DJANGO_SETTINGS_MODULE='mayan.settings.celery_redis' celery -A mayan worker -l DEBUG -Q checkouts,mailing,uploads,converter,ocr,tools,indexing,metadata -Ofair -B
|
||||
@@ -348,18 +348,17 @@ Documentation
|
||||
-------------
|
||||
|
||||
The documentation is written in `reStructured Text`_ format and resides in the
|
||||
``docs`` directory. In order to build it, you will first need to install
|
||||
Sphinx_. ::
|
||||
``docs`` directory. In order to build it, you will first need to install the
|
||||
documentation editing dependencies (Sphinx_, etc)::
|
||||
|
||||
$ pip install -r requirements/documentation.txt
|
||||
pip install -r requirements/documentation.txt
|
||||
|
||||
|
||||
Then, to build an HTML version of the documentation, simply run the following
|
||||
Then, to build an HTML version of the documentation, run the following command
|
||||
from the **docs** directory::
|
||||
|
||||
$ make livehtml
|
||||
make livehtml
|
||||
|
||||
Your ``docs/_build/html`` directory will then contain an HTML version of the
|
||||
The ``docs/_build/html`` directory will then contain an HTML version of the
|
||||
documentation.
|
||||
|
||||
You can also generate the documentation in formats other than HTML.
|
||||
@@ -378,20 +377,20 @@ This is the sequence of step I use to produce an installable package:
|
||||
|
||||
1. Make sure there are no lingering packages from previous attempts::
|
||||
|
||||
$ rm dist -R
|
||||
rm dist -R
|
||||
|
||||
2. Generate the packaged version (will produce dist/mayan-edms-2.0.0.tar.gz)::
|
||||
2. Generate the packaged version (will produce dist/mayan-edms-x.y.z.tar.gz)::
|
||||
|
||||
$ python setup.py sdist
|
||||
python setup.py sdist
|
||||
|
||||
3. Do a test install::
|
||||
|
||||
$ cd /tmp
|
||||
$ virtualenv venv
|
||||
$ source venv/bin/activate
|
||||
$ pip install <path of the Git repository>/dist/mayan-edms-2.0.0.tar.gz
|
||||
$ mayan-edms.py initialsetup
|
||||
$ mayan-edms.py runserver
|
||||
cd /tmp
|
||||
virtualenv venv
|
||||
source venv/bin/activate
|
||||
pip install <path of the Git repository>/dist/mayan-edms-x.y.z.tar.gz
|
||||
mayan-edms.py initialsetup
|
||||
mayan-edms.py runserver
|
||||
|
||||
|
||||
Wheel package
|
||||
@@ -403,13 +402,13 @@ Wheel package
|
||||
|
||||
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)::
|
||||
|
||||
$ pip wheel --no-index --no-deps --wheel-dir dist dist/mayan-edms-2.0.0.tar.gz
|
||||
$ pip wheel --no-index --no-deps --wheel-dir dist dist/mayan-edms-x.y.z.tar.gz
|
||||
|
||||
3. Do a test install::
|
||||
|
||||
$ cd /tmp
|
||||
$ virtualenv venv
|
||||
$ source venv/bin/activate
|
||||
$ pip install <path of the Git repository>/dist/mayan_edms-2.0.0-py2-none-any.whl
|
||||
$ pip install <path of the Git repository>/dist/mayan_edms-x.y.z-py2-none-any.whl
|
||||
$ mayan-edms.py initialsetup
|
||||
$ mayan-edms.py runserver
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
Concepts
|
||||
========
|
||||
|
||||
Introductions to all the key parts of Mayan EDMS you'll need to know:
|
||||
Introductions to all the key parts of **Mayan EDMS** you'll need to know:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
@@ -12,6 +12,7 @@ Introductions to all the key parts of Mayan EDMS you'll need to know:
|
||||
sources
|
||||
acls
|
||||
transformations
|
||||
checkouts
|
||||
versioning
|
||||
signatures
|
||||
indexes
|
||||
|
||||
@@ -2,21 +2,92 @@
|
||||
Indexes
|
||||
=======
|
||||
|
||||
Indexes are an automatic method to hierarchically organize documents in relation to their properties.
|
||||
Indexes are an automatic method to hierarchically organize documents in
|
||||
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 templates
|
||||
===============
|
||||
Index are hierachical 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.
|
||||
|
||||
Since multiple indexes can be defined, the first step is to create an empty index.
|
||||
Administrators then define the tree template showing how the index will be structured.
|
||||
Each branch can be a pseudo folder, which can hold other child 'folders' or
|
||||
a document container which will have all the links to the documents that
|
||||
matched the criteria of the document container.
|
||||
Example:
|
||||
|
||||
Index instances
|
||||
===============
|
||||
- Document type: ``Product sheet``
|
||||
- Metadata type: ``Product year``, associated as a required metadata for the document type ``Product sheet``.
|
||||
|
||||
The template is the skeleton from which an instance of the index is then
|
||||
auto-populated with links to the documents depending on the rules of each
|
||||
branch of the index evaluated against the metadata and properties of the documents.
|
||||
- Index: ``Product sheets per year``, and associated to the document type ``Product sheet``.
|
||||
- Index slug: ``product-sheets-per-year``. Slugs are internal unique identifiers that can be used by other **Mayan EDMS** modules to reference each index.
|
||||
- Index tree template as follows:
|
||||
|
||||
.. blockdiag::
|
||||
|
||||
blockdiag {
|
||||
index [ label = 'Product sheets per year', width=180 ];
|
||||
root [ label = 'Root (Has document links? No)', width=450];
|
||||
level_2 [ label = '{{ document.metadata_value_of.product_year }} (Has document links? Yes)', width=450];
|
||||
|
||||
group {
|
||||
label = "Tree template";
|
||||
color = "#dddddd";
|
||||
style = dashed;
|
||||
root; level_2;
|
||||
}
|
||||
|
||||
index -> root
|
||||
root -> level_2 [folded];
|
||||
}
|
||||
|
||||
Now every time a new ``Product sheet`` is uploaded a hierarchical unit with the value
|
||||
of the metadata type ``Product year`` is created and a link to the uploaded ``Product sheet`` added to it.
|
||||
|
||||
Example:
|
||||
|
||||
Suppose three ``Product sheets`` are uploaded with the following values as their
|
||||
``Product year`` metadata: 2001, 2002, 2001 respectively. The result index
|
||||
that will be generate based on the tree template would be as follows:
|
||||
|
||||
.. blockdiag::
|
||||
|
||||
blockdiag {
|
||||
index [ label = 'Product sheets per year', width=180 ];
|
||||
year_1 [ label = '2001', width = 60 ];
|
||||
year_2 [ label = '2002', width = 60 ];
|
||||
document_1 [ label = 'Product A data sheet (2001)', width = 200 ];
|
||||
document_2 [ label = 'Product B data sheet (2002)', width = 200 ];
|
||||
document_3 [ label = 'Product C data sheet (2001)', width = 200 ];
|
||||
|
||||
group {
|
||||
label = "Index content";
|
||||
color = "#dddddd";
|
||||
style = dashed;
|
||||
year_1, year_2, document_1, document_2, document_3;
|
||||
}
|
||||
|
||||
index -> year_1;
|
||||
index -> year_2;
|
||||
year_1 -> document_1;
|
||||
year_2 -> document_2;
|
||||
year_1 -> document_3;
|
||||
|
||||
}
|
||||
|
||||
Mirroring
|
||||
=========
|
||||
|
||||
Indexes can be exported as `FUSE <https://en.wikipedia.org/wiki/Filesystem_in_Userspace>`_
|
||||
filesystems. Using the management command ``mountindex`` we could export the
|
||||
previous example index as follows::
|
||||
|
||||
mkdir -p ~/indexes/products
|
||||
mayan-edms.py mountindex product-sheets-per-year ~/indexes/products
|
||||
|
||||
The ``~/indexes/products`` directory will now have a directory and files structure
|
||||
identical to that of the index. Once indexes are mounted with this command, they
|
||||
behave like any other filesystem directory and can even be further shared
|
||||
via the network with network file system software like
|
||||
`Samba <https://www.samba.org/>`_ or
|
||||
`NFS <https://en.wikipedia.org/wiki/Network_File_System>`_.
|
||||
|
||||
Indexes and mirrored indexes are Read Only as they are generated as a result of
|
||||
prior activities like document uploads, metadata changes.
|
||||
|
||||
@@ -2,48 +2,32 @@
|
||||
Installation
|
||||
============
|
||||
|
||||
**Mayan EDMS** should be deployed like any other Django_ project and preferably using virtualenv_.
|
||||
**Mayan EDMS** should be deployed like any other Django_ project and
|
||||
preferably using virtualenv_.
|
||||
|
||||
Being a Django_ and a Python_ project familiarity with these technologies is
|
||||
required to understand why **Mayan EDMS** does some of the things it does the way
|
||||
it does them.
|
||||
Being a Django_ and a Python_ project, familiarity with these technologies is
|
||||
recommended to better understand why **Mayan EDMS** does some of the things it
|
||||
does.
|
||||
|
||||
Before installing **Mayan EDMS**, the binary requirements must be installed first.
|
||||
Bellow are the step needed for a test install.
|
||||
|
||||
Binary dependencies
|
||||
===================
|
||||
|
||||
Ubuntu
|
||||
------
|
||||
|
||||
If using a Debian_ or Ubuntu_ based Linux distribution getting the executable requirements is as easy as::
|
||||
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
|
||||
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
|
||||
|
||||
Initialize a ``virtualenv`` to deploy the project:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ virtualenv venv
|
||||
$ source venv/bin/activate
|
||||
$ pip install mayan-edms
|
||||
|
||||
By default **Mayan EDMS** will create a single file SQLite_ database, which makes
|
||||
it very easy to start using **Mayan EDMS**. Populate the database with the
|
||||
project's schema doing:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ mayan-edms.py initialsetup
|
||||
$ mayan-edms.py runserver
|
||||
|
||||
Point your browser to http://127.0.0.1:8000. If everything was installed
|
||||
correctly you should see the login screen and panel showing a randomly generated
|
||||
admin password.
|
||||
|
||||
Mac OSX
|
||||
-------
|
||||
|
||||
**Mayan EDMS** is dependant 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/>`.
|
||||
or `Homebrew <http://brew.sh/>`_.
|
||||
|
||||
|
||||
Use MacPorts to install binary dependencies
|
||||
@@ -101,45 +85,44 @@ to /usr/bin/ with ...
|
||||
|
||||
LIBREOFFICE_PATH = '/Applications/LibreOffice.app/Contents/MacOS/soffice'
|
||||
|
||||
Testing the install
|
||||
-------------------
|
||||
Actual project installation
|
||||
===========================
|
||||
|
||||
To create a custom settings file for **Mayan EDMS**, create a Python (.py) file
|
||||
in the directory: venv/lib/python2.7/site-packages/mayan/settings/ with the following basic content::
|
||||
Initialize a ``virtualenv`` to deploy the project:
|
||||
|
||||
# venv/lib/python2.7/site-packages/mayan/settings/my_settings.py
|
||||
.. code-block:: bash
|
||||
|
||||
from __future__ import unicode_literals
|
||||
virtualenv venv
|
||||
source venv/bin/activate
|
||||
pip install mayan-edms
|
||||
|
||||
from .local import *
|
||||
By default **Mayan EDMS** will create a single file SQLite_ database, which makes
|
||||
it very easy to start using **Mayan EDMS**. Populate the database with the
|
||||
project's schema doing:
|
||||
|
||||
<Your customized settings>
|
||||
.. code-block:: bash
|
||||
|
||||
To test your settings launch **Mayan EDMS** using::
|
||||
mayan-edms.py initialsetup
|
||||
mayan-edms.py runserver
|
||||
|
||||
$ mayan-edms.py runserver --settings=mayan.settings.my_settings
|
||||
Point your browser to http://127.0.0.1:8000. If everything was installed
|
||||
correctly you should see the login screen and panel showing a randomly generated
|
||||
admin password.
|
||||
|
||||
Note: Background tasks and scheduled tasks will not run when using the test server.
|
||||
|
||||
|
||||
Production use
|
||||
--------------
|
||||
==============
|
||||
|
||||
After making sure everything is running correctly, stop the `runserver` command.
|
||||
Deploy **Mayan EDMS** using the webserver of your preference. For more information
|
||||
on deployment instructions and examples, checkout Django's official documentation
|
||||
on the topic https://docs.djangoproject.com/en/1.6/howto/deployment/
|
||||
on the topic https://docs.djangoproject.com/en/1.7/howto/deployment/
|
||||
For a simple production deployment setup follow the instructions in the
|
||||
:doc:`deploying` chapter.
|
||||
|
||||
|
||||
Other database managers
|
||||
-----------------------
|
||||
|
||||
If you want to use a database manager other than SQLite_ install any
|
||||
corresponding python database drivers and add the corresponding database settings
|
||||
to your settings file (see above) as shown here: https://docs.djangoproject.com/en/1.6/ref/settings/#std:setting-DATABASES
|
||||
|
||||
|
||||
.. _Debian: http://www.debian.org/
|
||||
.. _Django: http://www.djangoproject.com/
|
||||
.. _Download: https://github.com/mayan-edms/mayan-edms/archives/master
|
||||
|
||||
@@ -2,13 +2,31 @@
|
||||
Smart links
|
||||
===========
|
||||
|
||||
Smart links are a way to link documents without changing how they are organized
|
||||
in their respective indexes. Smart links are useful when two documents are
|
||||
related somehow but are of different type or different hierarchical units.
|
||||
|
||||
Smart links are usefull for navigation between documents. They are rule
|
||||
based, but don't create any organizational structure. They just show the documents
|
||||
that match the rules as evaluated against the metadata of the currently
|
||||
displayed document.
|
||||
Example: A patient record can be related to a prescription drug information
|
||||
document, but they each belong to their own :doc:`indexes`.
|
||||
|
||||
Smart links are usefull when a patient file in a patients index needs to be linked
|
||||
to the medical documentation of a prescription the patient is using, but that medical
|
||||
documentation is in it's own prescription index. Smart links can provide a reference
|
||||
between documents of different indexes without any change in the indexes' structures.
|
||||
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
|
||||
are automatic references between documents.
|
||||
|
||||
Example:
|
||||
|
||||
- Document type: ``Patient records``
|
||||
- Metadata type: ``Prescription``, associated as an optional metadata for the document type ``Patient records``.
|
||||
|
||||
- Document type: ``Prescription information sheets``
|
||||
|
||||
A smart link with the following condition, will automatically links patient
|
||||
records to the prescription information sheets based on the value of the
|
||||
metadata type of the patient record.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
foreign label is equal to {{ document.metadata_value_of.prescription }}
|
||||
|
||||
@@ -2,10 +2,17 @@
|
||||
Sources
|
||||
=======
|
||||
|
||||
Document sources define from where documents will be uploaded or gathered.
|
||||
To add a document source go to the ``Setup`` section, then to the ``Sources`` section.
|
||||
To obtain the fastest working setup, create a new source of type ``Web form``.
|
||||
``Web forms`` are just HTML forms with a ``Browse`` button that will open the file upload
|
||||
dialog when clicked. Name it something simple like ``Local documents`` and select whether or not
|
||||
compressed files uploaded from this source will be automatically decompressed and
|
||||
their content treated as individual documents.
|
||||
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.
|
||||
|
||||
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
|
||||
manager system.
|
||||
|
||||
@@ -14,4 +14,4 @@ translation issue, it will be your resposibility 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
|
||||
closed if not activity is observed from the original poster.
|
||||
closed if no activity is observed from the original poster in a period of time.
|
||||
|
||||
@@ -8,7 +8,5 @@ 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
|
||||
revert to a previous version of the document is provided.
|
||||
|
||||
To upload a new document version, select an existing document, click on the
|
||||
version tab of the document, and click on the 'upload new version' on the
|
||||
side bar. A new view very similar to the new document upload view will
|
||||
appear, showing the same interactive document sources that have been defined.
|
||||
Only the interactive document sources (:doc:`sources`) (``Web`` and ``Staging folders``) are
|
||||
avaiable to upload new document versions.
|
||||
|
||||
Reference in New Issue
Block a user