This page documents special considerations for getting the Document Management component fully working.
Use this page when you have installed IFS Document Management and want to ensure that everything will work properly.
The ticket temp path is used when files are checked in or checked out (or
using other terms, uploaded and downloaded), for viewing or editing, in IFS
Document Management. Basically, a check in and check out process is done in
several steps.
Below, a "ticket" is a random string of letters and numbers that acts as a secret
between client and server. "FTS" is the File Transfer Service (a Java Servlet,
built into ifsapp.ear and running inside the application server) used
for the actual file transfers. The way the ticket temp path works together with
tickets is that, if the ticket temp path is set to c:\docman, folders
with a name like c:\docman\ifs\filsrv\123nhsdni879jklpoqzc will be
created, where 123nhsdni879jklpoqzc is an example value of one
specific ticket.
Check In Process
- First, the client requests a ticket to allow a file to be checked in against a
certain document revision. If the logged in user has the necessary access to the
document revision, the client will get a ticket back. On the server, a new
ticket folder will be created for files to be uploaded.
- Second, the client uploads the file to the server through the FTS, sending in
the ticket as an argument, a kind of "proof" that it is allowed to check in the
file. It is in this step that the ticket temp path is actually used, as an
intermediate storage location for uploaded files before the file is checked in
to a document file repository.
- Third, the client tells the server to finalize the check in of the file. The
server reads the file from the ticket folder and writes it to the document file
repository. After this, the ticket folder is deleted.
Check Out Process
Check out basically works in the other direction:
- First, the client requests a ticket to allow a file to be checked out for a
certain document revision. If the logged in user has the necessary access to the
document revision, the client will get a ticket back. The server will read the
file from the document file repository, placing it in a ticket folder.
- Second, the client makes a request to the FTS, again sending in the ticket as
an argument, together with the name of the file to be downloaded.
- Third, once the file has been downloaded, the client tells the server to
remove the ticket folder from the ticket temp path.
Cleaning up unused tickets
Tickets that for some reason fails to be removed can be removed by
scheduling a task:
Configuring the ticket temp path
The ticket temp path is defined in the IFS Installer, when installing IFS
Applications on the server. The value is saved inside ifsapp.ear as
well as in the default value DOCUMENT_TICKET_TEMP_PATH
in Docman.
When multiple cluster nodes are used, and when one or more cluster nodes are
running on two or more hosts, then the configuration of the ticket temp path
will be more complicated. The reason is that all cluster nodes must be able to
read and write files and folders under the ticket temp path. There are two main
prerequisites in such a scenario:
- Firstly, the ticket temp path needs to be a shared folder. It will either be a
folder on one of the node machines that will "own" a folder that will be shared
on the network, or it will be a folder on a separate machine (even better) that
will own it, and share it to the other nodes.
- Secondly, you need to set up the permissions to the shared folder correctly.
This will differ for different operating systems:
- On Windows platforms, the default account running the AS Node Manager (which in turn starts the servers, which also will run using the same account) is the "Local System" account. It is not possible to grant access to a share on another computer, to this account, so it cannot be used for setups where many computers need to access the share. Therefore, a named domain account needs to be set up and used to run the AS Node Manager service. Then read and write access to the share used as the ticket temp path can granted to the named account.
- On Linux and Unix platforms, the account will be the named account "ifs". Like when using Windows, it must be possible to grant access to the shared folder, to this account.
The exact permissions needed are:
- Creating and deleting folders (under the ticket temp path folder, which acts
as the root folder for all tickets, each ticket will be created as a folder).
- Reading files from ticket folders under the ticket temp path
- Writing files from ticket folders under the ticket temp path
- Listing and checking for files in ticket folders under the ticket temp path
- Deleting files from ticket folders under the ticket temp path (the files are
deleted along with the ticket folder that contains them)
However, most probably it is better to give "read and write access" on a higher
level than to try to find more fine grained access levels to the shared folder
(to reduce the risk in missing a specific access that is needed, like for
example being able to delete files and folders).
From a security standpoint, it is recommended to keep the ticket folder on its own drive (logical or physical) on the application server. In this way, it is less likely that an attacker can get access to critical parts of the file system on the application server. As an alternative the path can also be a network share, with the sole purpose of storing the temporary files. Please note however that using a network share might have performance implications in installations with a high load (many file transfers at any given time). A local drive is therefore the best approach. If the application server has a lot of memory one could even create an in-memory drive, and use that, for extremely good performance. If a separate drive cannot be achieved, try to set up file system security such that the account running the application server cannot access operating system files when it is not necessary.
For functional information and information on how you install the Office Add-In for IFS Document Management (referred to as "the add-in" below), refer to the end-user documentation (Topics / Create and Maintain Document / Office Add-In).
The add-in uses XML Translation Files. These files are compiled into the installation package by R&D such that when you install you get the language files currently available. However, it is possible to manually install new files on the client by placing them in a special folder on each client. You can open this folder through the add-in itself by opening Settings and then clicking on the Manage Language Files... button. After placing new language files here you must restart the Office application you had open before you will see the new languages in the drop down.
The installation package for the add-in currently comes precompiled from R&D, i.e. there is no need to compile it for each customer. However, it can be useful to know how the installation package end up in the IFS Start page, in case something goes wrong. This is done in two steps:
When a patch and new installer package is released by R&D you can either copy it to the client repository folder in IFS Home manually, or you can run the client build to get it there. After this is done, the user can click the installation link on Add-Ins sub-page again to update the installed add-in through the ClickOnce mechanism.
For functional information and information on how you install the Lotus Notes Add-In for IFS Document Management (referred to as "the add-in" below), refer to the end-user documentation (Topics / Create and Maintain Document / Lotus Notes Add-In).
https://<IFSApplicationServer>:<Port>/client/docman/LotusNotesWidget/ifs.docman.lotusnotes.updatesiteNote: If the above URL does not work, download the zip file
located at https://<IFSApplicationServer>:<port>/add-on/docman/LotusNotesWidget/ifs.docman.lotusnotes.updatesite.zip
and follow the instructions in the ReadMe.txt file.
ifs.docman.lotusnotes.featureIFS Document Management Widget for Lotus Notes.
The add-in uses XML Translation Files. These files are compiled into the installation package by R&D such that when you install you get the language files currently available. However, it is possible to manually install new files on the client by placing them in a special folder on each client. You can open this folder through the add-in itself by opening Settings and then clicking on the Manage Language Files... button. After placing new language files here you must restart the Lotus Notes client application you had open before you will see the new languages in the drop down.
The installation package for the add-in currently comes precompiled from R&D, i.e. there is no need to compile it for each customer. However, it can be useful to know how the installation package end up in the IFS Start page, in case something goes wrong. This is done in two steps:
When a patch and new installer package is released by R&D you can either copy it to the client repository folder in IFS Home manually, or you can run the client build to get it there. After this is done, the user can click the installation link on Add-Ins sub-page again to update the installed add-in. This can also be achieved by drag-n-drop of the install link in the Add-Ins sub page to the Widget Panel in Lotus Notes.
The AutoVue integration is built of the component DOCVUE as well as dynamic code in DOCMAN and DOCMAW. You will find information on how to install and configure the AutoVue integration in the DOCVUE documentation.
For certain scenarios and for certain customers we have compiled a document with useful tips and tricks for increasing performance and for optimizing the system. Read about it in the document Performance and Optimization of Document Management.
This section describes pre defined roles, activities and system privileges needed for this component. Each script contains only objects handled by this component and may need to be further developed or combined with roles defined in other components to work properly, according to the need of the customer installation.
security_docman_batch_transfer.ins
This script creates a role, DOCMAN_BATCH_TRANSFER_WIZARD, and adds permissions
to it for running the Activity BatchTransferHelper. This Activity is needed by
"the Wizard that moves document files between file repositories", in Batch Mode,
in the windows client. To grant this permission set, only add the new role
toward the users that should be allowed access. NOTE! In order to do what is
needed, the Activity is very powerful and bypasses all Document Issue Access.
This means that this should not be granted to all users; only "docman admins"
should get this role granted.
security_docman_administrator.ins
This script creates a role called DOCMAN_ADMINISTRATOR, to which the system
privilege DOCMAN ADMINISTRATOR is granted. This role can be then granted to
end-users who need admin rights over the application, allowing them to behave as
App-Owner. Making normal users such "power users" must be done with a lot of
caution.
security_document_explorer.ins
This script creates a role called DOCUMENT_EXPLORER, and adds the permissions to
it for running the Business Object Explorer in the IEE client for Documents. To
grant this permission set, only add the new role toward the users that should be
allowed access.
security_document_attachment.ins
This script creates a role called DOCUMENT_ATTACHMENT, and adds the permissions
to it for running the Document Attachment Pane in the Enterprise Explorer. To
grant this permission set, only add the new role toward the users that should be
allowed access.
Business Object Explorer - Document RMB option
Security methods
In the Business Object Explorer, the user has the possibility to enable and
disable several RMB options, by granting or revoking the attached security
setting for the following database object methods:
- RMB Create Folder... requires the database method
DOC_FOLDER_API.Create_New_Folder.
- RMB Delete Folder requires the database method DOC_FOLDER_API.Delete_Folder.
- RMB Delete Folder Structure requires the database method
DOC_FOLDER_API.Delete_Folder_And_Children.
For miscellaneous information and instructions, check out this page.
For information and instructions on how to setup digital signatures for Document Management, check out this page.