Public Access Catalog

Use

The OpenProdoc Public Access Catalog (sometimes refered in this documentation with the traditional term OPAC ), allows people external to the company institution to look for in an easy way the documents (or folders) stored in OpenProdoc without the need of an user. Public Access Catalog allows to select the document (or folder) type to search for, to key in the search criteria and select the format to list the results.

The use of the OPAC requires to adjust parameters for and easy use and also for adding security,because we are allowing access to unkown people that could access to confidential documentation or damage something by error or intentionally. The parameters are defined by means of a properties file with the elements defined in the next list. At the end of the page it's include an example (The lines starting by # are comments and are ignored, as the blank lines) :

With the "OPAC" functionality it's possible to create forms as:

Athena design created by Lucycons3 and Nosturi

Syntax

This file follows the standard format of the properties files (label/element+"="+Value), with comments ( the lines starting wiith the character '#'). The meaning of each entry (that can't be repeated) is:

• DocTipesList : Names of the Document types by which the user is allowed to search. It must be noted that if the param Inheritance is enabled ( equal to 1), automatically all the subtipes of any of the selected document types will be included in the search. For searching folder (using Url OPACf), you must include folders types.
• FieldsToInclude : Names (Internal names not the user names) of the metadata/fields (of any type included in the previous list) by which the user is allowed to search. In the form will be showed (and searched for) the subset of the listed metadata of the type selected. That is each time you select a type, the form will be updated showing the subset of fields of the type included in the list. This list has no relation with the fields shown in the results form, that depend on the reports selected in ResultForm.
• FieldsComp : Search / compare operators for each metadata. By default it is equality (EQ) ie it searches for all documents (or folders) whose value of that metadata is equal to the one entered. The possible values are 2 letter characters: = EQ, <> NE,> GT,> = GE, < LT, <= LE, Contains CT. Different values can be assigned such that for example a date-type metadata is searched for values greater than that entered using GE. The CT operator allows you to search for metadata that CONTAINS the entered value, which facilitates the search but slows it down and can generate too many results.
• BaseFolder : Folder tree below which searches will be performed. The rest of the documents stored outside that tree will not be returned.
• Inheritance : If this parameter is enabled (1) the search will include all subtypes of documents of the selected document type. If it is disabled, it will only include the selected type. This option does NOT affect performance, so the criteria for using it is purely functional.
• ResultForm : Identifier codes (PDId) of documents of type Reports (PD_REPORTS) that will be used to present the results. At least 1 must be included.
• MaxResults : Maximum number of results to be returned (0 = "no limit", actually 1 million).
• FormSearchCSS : Identifier code (PDId) of the CSS file to be used for the query form. The predefined styles on the page are detailed in OPAC CSS Styles
• FormSearchLogo : URL of the logo to be presented in the query form. It can be external (eg: "http://intranet.empres.com/img/Logo.jpg") or internal (eg "SendDoc?Id = 44345543-757656") using as the value of the Id parameter, the unique code PDId of an image in OpenProdoc. It should be verified that this document is visible to all users.
• User : User with which the OpenProdoc queries will be performed. It should be checked that this user has access to the documents but no permissions of another type, since the Query Point makes a real connection that could allow you to perform operations. The recommendation is to create a specific user to query and assign a Role without any permission (with which he can only search)
• Pass : Password (clear) of the query user.
• Title : Header of the search form.
• DTLabel : Label of the drop-down list of document types(or folder types) on which the search can be performed.
• OrderOPAC : List fields for ordering results, followed by ASCending or DESCending ordering criteria (Ej: PDDate,DESC,PDId,ASC).
• FTLabel : label of the full text search field for documents. (Only for searching documents)
• FormatLabel : Label of the results Reports drop-down list (defined in the ResultForm parameter)
• HelpForDocType : Text of the pop-up help that will be displayed when you are in the document (or folder) type selection combo box. Can contain html control characters.
• HelpForFullText : Text of the pop-up help in the field of full text search of the documents. Can contain html control characters.(Only for searching documents)
• HelpForFormatType : Text of the pop-up help that will be displayed when you are in the reports format selection combo box. Can contain html control characters.
• UrlHelp : Url of the personalized help page for the OPAC that will be presented to the users by clicking the help button.

The process of parameterizing the OPAC is to create a text file with the indicated parameters (you can use as base the included example and modify it), entering the appropriate values to the installation of OpenProdoc.

It's necessary to modify the configuration file (Prodoc.properties or the name used) and add two lines:

User=User1

Pass=PassUsr1

Where User1 y PassUsr1 would be the data of a user with access to the configuration documents (OPAC y OPAC_CS) described in the next point. It's recommended that the user used had a limited rol and a mimimum of permissions, becaue it's only needed read access to the configuration files. As any other change in the configuration file (Prodoc.properties), dthe server MUST be restarted so it can read the new configuration.

Next, you must create (or modify the included example) the CSS to adapt it to the style of the corresponding institution or company. Then add the CSS to the OpenProdoc repository and note the generated PdId. That PdId is the one that should be referenced as parameter FormSearchCSS in the OPAC configuration file. You should then upload that query configuration file.

With the generated ID, the OpenProdoc url (eg http://localhost:8080/ProdocWeb2/OPAC?Id= + the new document ID uploaded, for example http://localhost:8080/ProdocWeb2/OPAC?Id=566b6464a654-9696e68d686)

For searching folders use the OpenProdoc url (eg http://localhost:8080/ProdocWeb2/OPACf?Id= + the new document ID uploaded, for example http://localhost:8080/ProdocWeb2/OPACf?Id=566b6464a654-9696e68d686)

OpenProdoc will present a page according to the parameters defined in that file, including style sheet, literals, document types, etc. In that page the users, without entering access data (user / password), can choose one of the document types they want to search for, enter words from the content or known metadata, choose the format of the results and search. When the search button is clicked, Openprodoc will connect using the user indicated in the parameterization, will search according to the included criteria and return the results in the chosen format. The format can be html to present with a more aesthetic format, txt or csv for an automatic treatment, or xml to be able to interchange or to process.

Since all appearance is parametrizable, including typologies of documents, metadata, etc., and is aimed at sporadic users, it is reasonable to assume that a personalized help is needed. For that you have a button that will open the html page whose url is indicated in a configuration. It could be an external page or an html document stored in OpenProdoc.

It should be noted that the configuration file, like any Openprodoc document can be edited and versioned, always being used to compose the OPAC the last published version. However the upgrade may take some time, because to improve performance the configuration is not updated immediately.

Since the parameterization is based on one Openprodoc document and the style in another, it is possible to have several parameterizations simultaneously, presenting different document sets, different interface language, different style or different query user. Providing each group of users with the appropriate url (which will only differ in the Document Identifier) many different OPACSs can be simultaneously offered with very little effort.

If you need to modify the default html template for OPAC more than just using CSS, or to adapt the html to different browsers, it's possible to use different html templates. For using this functionality you must include additional entries in the OPAC confguration file:

• NumHtmlOpac: Number of alternatives HTML for supporting specific needs or formats of browsers or just for using a different template form the internal one. After this parameter, you must include the same numbers defined in NumHtmlOpac of pairs of the next parameters.
• ListAgent[i]=Text1|Text2|...: You must include as many entris as defined in NumHtmlOpac starting in 0, that is: ListAgent0, ListAgent1, ListAgent2,.. . If the description of "User-Agent" of the browser CONTAINS any of the text "Text1", "Text2",.., then the html template for the OPAC will be a document stored in OpenProdoc with PDID spedified in HtmlAgent[i]. If the Text is *, then OpenProdoc will not check other values and will return the html specified in HtmlAgent[i] for any browser.
• HtmlAgent[i]=PDID Document: Identifier of the html document to use of template uf the User-Agent contains any of the text specified in ListAgent. The numbers must be start in 0, that is: HtmlAgent0, HtmlAgent1, HtmlAgent2,...

If the User-Agent of the browser do nt contains any of the texts of the entries, then OpenProdoc will use the internal html template.

Example

OPAC Configuration File Example:

Share Reports and Documents

It is possible to share dynamically generated reports from the OPAC. To do this, within the Reports there is a variable @OPD_URLOPACREPORT that stores data from the OPAC used to generate a report, the type of report and the Search parameters. That variable, which contains a dynamically generated url (Ex .: http://localhost:8080/ProdocWeb2/OPAC2?OPAC_Id=OPAC_DocEx&DT=Picture&FORMAT_REP=15dc854acbf-3fedc1977572a008&Picture_Author=Joaquin%20Hierro) that can be included in the report and be shared with other users. If these users have access to that url, they will be able to see the report, which will be calculated in real time. As it is calculated in real time, it should be taken into account that it can return more or fewer documents (depending on whether they are added or removed from OpenProdoc after a while).

Additionally, there is the possibility to share a retrieved document in a report. For this, a url with the structure can be built in the report: http://localhost:8080/ProdocWeb2/OPAC2?OPAC_Id=OPACId&DT=TipoDocument&PDId=PDIdDocumento , where:

• OPACId: Identifier of the OPAC used.
• TypeDocument: Recovered document type. It can be dynamically generated in the report using @OPD_VAL_DocType.
• PDIdDocumento: PDId identifier of the document. It can be dynamically generated in the report using @OPD_VAL_PDId.

Example: http://localhost:8080/ProdocWeb2/OPAC2?OPAC_Id=OPAC_DocEx&DT=Picture&PDId=172ad6d6fc2-3fef4815f4e4d451

In both cases, the Urls are checked by the OPAC function (although it is not being used in its usual way), so the security and access control are the same as with the OPAC. Information that cannot be retrieved from the OPAC cannot still be retrieved through these urls. If its content is manipulated to gain access to non-public information, it will be rejected, and may return errors or nothing at all.