mirror of
https://git.code.sf.net/p/seeddms/code
synced 2024-11-26 15:32:13 +00:00
Merge branch 'seeddms-4.3.x' into seeddms-5.0.x
This commit is contained in:
commit
e56e6f5c8b
|
@ -25,6 +25,7 @@
|
|||
- various translation updates
|
||||
- check for document expiration when showing search result and folder content
|
||||
- more rest api functions
|
||||
- do not send notification mails to disabled users
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
Changes in version 4.3.23
|
||||
|
|
2
Makefile
2
Makefile
|
@ -1,5 +1,5 @@
|
|||
VERSION=5.0.1
|
||||
SRC=CHANGELOG inc conf utils index.php languages views op out controllers README.md README.Notification README.Ubuntu drop-tables-innodb.sql styles js TODO LICENSE Makefile webdav install restapi
|
||||
SRC=CHANGELOG inc conf utils index.php languages views op out controllers doc drop-tables-innodb.sql styles js TODO LICENSE Makefile webdav install restapi
|
||||
# webapp
|
||||
|
||||
EXTENSIONS := \
|
||||
|
|
39
doc/README.ReviewApproval.md
Normal file
39
doc/README.ReviewApproval.md
Normal file
|
@ -0,0 +1,39 @@
|
|||
Review/Approval
|
||||
------------------
|
||||
|
||||
The traditional Review/Approval process has been around for a long time
|
||||
already and is still available, though the new workflow engine has been
|
||||
introduced.
|
||||
|
||||
Review/Approval is a very simple, but in many cases sufficient, workflow
|
||||
to review and approve document versions. Review and approval is done by users
|
||||
in behalf of themself or the group they belong to. A document version
|
||||
is reviewed or approved if all users and groups in charge of it, have
|
||||
found the document version to be ready and worth for release. If a single
|
||||
user rejects it, it will not change its status to 'released' but to 'rejected'.
|
||||
|
||||
Review is always done before approval, but a document version may not have
|
||||
to run through both processes.
|
||||
A version can use just the approval process without a review before,
|
||||
and it can also skip the approval process and just run through review. In
|
||||
the second case the document will be released immidiately after successful
|
||||
review.
|
||||
|
||||
If a group is in charge for reviewing/approving a document, it will be
|
||||
sufficient if one member of that group takes action.
|
||||
|
||||
Internally SeedDMS keeps a record of all approval/review actions done on
|
||||
a document version. When a document version is uploaded with both processes
|
||||
in place, then for each user/group a list of log entries is created. Any
|
||||
action on the document will add a new entry to the log. Those entries
|
||||
contain the action (release/reject), a user comment and the current date.
|
||||
Each entry will also trigger an internal function which checks, whether
|
||||
the last action causes a document state change. Such a state change happens
|
||||
when all reviews or approvals are done, or if a review/approval is rejected.
|
||||
If a user or a group is deleted and some documents are still waiting for
|
||||
a review/approval, this will also be logged and the review/approval will
|
||||
no longer be needed to release the document.
|
||||
|
||||
Before a document leaves the approval or review state any review/approval
|
||||
or reject can be changed. So if a user initially approves a document and
|
||||
later changes her/his mind, he/she can still reject the document.
|
109
doc/README.Synology.txt
Normal file
109
doc/README.Synology.txt
Normal file
|
@ -0,0 +1,109 @@
|
|||
*********************************************
|
||||
How to set up SeedDMS Preview on Synology NAS
|
||||
*********************************************
|
||||
|
||||
Introduction
|
||||
############
|
||||
SeedDMS provides a function creating a preview of each document which is displayed on the document page.
|
||||
|
||||
Synology stations do not support the creation of the previews by default due to a missing Ghostscript implementation. Therefore
|
||||
loading of a document page can use a lot of time because SeedDMS tries to create the missing preview images each time the document
|
||||
page is being loaded.
|
||||
|
||||
Prerequisites
|
||||
#############
|
||||
In order to complete the steps outlined below, you must be able to carry out the following tasks:
|
||||
|
||||
* Use the command line and know essential commands
|
||||
* Install a 3rd party package system and install packages using this system
|
||||
|
||||
To complete the installation, the following prerequisites on your Synology must be met:
|
||||
|
||||
* IPKG or OPKG (OPKG preferred) installed
|
||||
* Pear Package SeedDMS_Preview already installed
|
||||
|
||||
Installation and configuration
|
||||
##############################
|
||||
|
||||
In the following steps, you will first install the required packages, followed by doing the neccesary configurations. These steps
|
||||
must be done on the terminal.
|
||||
|
||||
Install Ghostscript
|
||||
***************************
|
||||
|
||||
The first step is to install Ghostscript to make ImageMagick capable of converting PDF files to images. Use IPKG or OPKG to complete this
|
||||
step.
|
||||
|
||||
Make Ghostscript available to PHP
|
||||
*****************************************
|
||||
|
||||
To check where Ghostscript is installed run *which gs* to get the installation path. Now check if this path is visible to PHP. To check this,
|
||||
use phpinfo and find **_SERVER["PATH"]**. If you can't find /opt inside, PHP can't see applications installed there. You can now either try to
|
||||
update the paths or just make a symlink.
|
||||
To create the symlink, cd to /usr/bin and type *ln -s /opt/bin/gs gs*. Verify the created symlink.
|
||||
|
||||
Fix Ghostscript package bug
|
||||
****************************************
|
||||
|
||||
Unfortunately the version delivered by OPKG has a bug, making Ghostscript failing to work properly. The bug requries fixing at the time
|
||||
of the writing are the following:
|
||||
|
||||
* Resource path pointing to a wrong version (9.10 instead of 9.16)
|
||||
|
||||
First, fix the resource path. Go to /opt/bin and find **gs** in there. Open the file with VI. Change the GS_LIB path from */opt/share/ghostscript/9.10/Resource*
|
||||
to */opt/share/ghostscript/9.16/Resource*. This will now allow Ghostscript to find it's files in the proper path.
|
||||
|
||||
Fix ImageMagick
|
||||
********************
|
||||
|
||||
Not only Ghostscript is affected by bugs, the default configuration files are missing. Unfortunately some work is required here as well.
|
||||
|
||||
To check where ImageMagick looks for it's files, invoke the command *convert -debug configure logo: null:*. You will see some paths shown, these
|
||||
are the paths where ImageMagic tries to locate it's configuration files. The first path shown will point to */usr/share/ImageMagick-6* followed by the
|
||||
name of an XML file. At the very end of the output you will see which configuration file has been loaded, in the default setting there will be an error.
|
||||
|
||||
Point to */usr/share* and check if you can find the **ImageMagick-6** directory. If is not present, create it. Cd into the directory.
|
||||
|
||||
Next step is to fill the directory with files. Use the following list to download the files (credit goes to Thibault, http://blog.taillandier.name/2010/08/04/mediawiki-sur-son-nas-synology/).
|
||||
|
||||
* wget http://www.imagemagick.org/source/coder.xml
|
||||
* wget http://www.imagemagick.org/source/colors.xml
|
||||
* wget http://www.imagemagick.org/source/configure.xml
|
||||
* wget http://www.imagemagick.org/source/delegates.xml
|
||||
* wget http://www.imagemagick.org/source/english.xml
|
||||
* wget http://www.imagemagick.org/source/francais.xml
|
||||
* wget http://www.imagemagick.org/source/locale.xml
|
||||
* wget http://www.imagemagick.org/source/log.xml
|
||||
* wget http://www.imagemagick.org/source/magic.xml
|
||||
* wget http://www.imagemagick.org/source/mime.xml
|
||||
* wget http://www.imagemagick.org/source/policy.xml
|
||||
* wget http://www.imagemagick.org/source/thresholds.xml
|
||||
* wget http://www.imagemagick.org/source/type-ghostscript.xml
|
||||
* wget http://www.imagemagick.org/source/type-windows.xml
|
||||
* wget http://www.imagemagick.org/source/type.xml
|
||||
|
||||
Testing
|
||||
*************
|
||||
|
||||
Now you should be ready to test. Put a PDF file in a directory, cd into this directory.
|
||||
|
||||
To test convert directly, invoke the following command (replace file.pdf with your filename, replace output.png with your desired name):
|
||||
|
||||
**convert file.pdf output.png**
|
||||
|
||||
If everything goes well you should now receive a png file which can be opened. There may be a warning message about iCCP which can be ignored.
|
||||
|
||||
If you want to test Ghostcript as well, invoke the follwing command:
|
||||
|
||||
**gs -sDEVICE=pngalpha -sOutputFile=output.png -r144 file.pdf**
|
||||
|
||||
This command should go through without any errors and as well output a png file.
|
||||
|
||||
If the tests above are successful, you are ready to use SeedDMS Preview. Go to your SeedDMS Installation and open a folder. For the first test you
|
||||
may take a folder with less files in it. Be patient while the previews are generated. You may check the process using *top* on the terminal.
|
||||
|
||||
At the end your document page should show the previews like shown below:
|
||||
|
||||
.. figure:: preview.png
|
||||
:alt: Document previews
|
||||
:scale: 75%
|
53
doc/README.WebDAV
Normal file
53
doc/README.WebDAV
Normal file
|
@ -0,0 +1,53 @@
|
|||
WebDAV
|
||||
-----------------------------------------------
|
||||
|
||||
SeedDMS has support for WebDAV which allows to easily add, delete,
|
||||
move, copy and modify documents. All operating systems have support
|
||||
for WebDAV as well, but the implemtations and their behaviour varys
|
||||
and consequently you may run into various problems. If this happens
|
||||
just file a bug report at https://sourceforge.net/projects/seeddms
|
||||
|
||||
The folder structure in SeedDMS is similar to a regular file system
|
||||
but it is not identical. SeedDMS distinguishes between a document
|
||||
and its content, while a file system knows just files.
|
||||
In SeedDMS a document is uniquely identified
|
||||
by its document id and not neccessarily by its name. A filesystem
|
||||
requires a unique paths for each file. Two identical files in the
|
||||
same folder are not possible. SeedDMS can handle identifcally named
|
||||
documents in one folder. In order to prevent any problems arising from
|
||||
this, you should always disallow identical document names in the
|
||||
settings. By definition a file in WebDAV is mapped on the latest
|
||||
version of a document in SeedDMS. There is no way to access previous
|
||||
versions of a document via WebDAV. Whenever you modify a file,
|
||||
a new version will be created. Unfortunately, this has some very
|
||||
nasty side effects when you often save a file, because any save
|
||||
operation will create a new version. This is because the WebDAV
|
||||
server replaces the content of document instead of creating a new
|
||||
version if a document is saved again.
|
||||
|
||||
Various programms have differnt strategies to save files to disk and
|
||||
prevent data lost under all circumstances. Those strategies often don't
|
||||
work very well an a WebDAV-Server. The following will list some of those
|
||||
strategies.
|
||||
|
||||
VIM
|
||||
=========================
|
||||
|
||||
vim does a lot more than just reading and writing the file you want
|
||||
to edit. It creates swap and backup files for data recovery if vim crashes
|
||||
or is being kill unexpectivly. On a low bandwidth connection this can
|
||||
slow down the editing. For that reason you should either not create the
|
||||
swap file at all or create it outside the WebDAV server. A second problem
|
||||
arises from how vim modifіes the file you are editing. Before a file
|
||||
is saved a backup is created and the new content is written into a new
|
||||
file with the name of the original file. On a file system you
|
||||
won't see a difference between the file before and after saveing, though
|
||||
is actually a new one. In SeedDMS you won't notice a difference either
|
||||
if just looking at the document name. It's still the same, but the
|
||||
document id has changed. So saving a document will delete the
|
||||
old document and create a new one instead of creating a new version of
|
||||
the old document. If you don't want this behaviour, then tell vim
|
||||
to not create the backup. Creating the backup file in a directory
|
||||
outside of WebDAV doesn't help in this case.
|
||||
|
||||
vi "+set nobackup" "+set nobackuwrite" -n test.txt
|
BIN
doc/preview.png
Normal file
BIN
doc/preview.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 11 KiB |
|
@ -74,7 +74,7 @@ class SeedDMS_EmailNotify extends SeedDMS_Notify {
|
|||
*/
|
||||
function toIndividual($sender, $recipient, $subject, $message, $params=array()) { /* {{{ */
|
||||
global $settings;
|
||||
if ($recipient->getEmail()=="") return 0;
|
||||
if ($recipient->isDisabled() || $recipient->getEmail()=="") return 0;
|
||||
|
||||
if (!is_object($recipient) && strcasecmp(get_class($recipient), "SeedDMS_Core_User")) {
|
||||
return -1;
|
||||
|
|
Loading…
Reference in New Issue
Block a user