Advanced Configuration

Domains

An iKnowBase installation may serve multiple uses at the same time. For example, it may serve an external site (http://www.example.com), an intranet (http://intra.example.com), a partner site (https://partner.example.com) and a customer service site (https://service.example.com).

An iKnowBase Domain defines properties that apply to a particular host name, to allow the user experience to differ between them.

The Default Domain

To avoid having to make a domain for every possible hostname:port combination, you can designate a domain as the default domain. The default domain will apply to all requests that do not match any other domain.
Note that having a default domain is required for sending e-mail, since most e-mail functionality is unrelated to a user request, and hence it is not possible to find the proper domain in any other way.

Custom Access Control

For a domain you may override or extend the default access control for content modification and deletion. For example, for an integrated solution you can check the metadata in the external document before permitting any modification.

The custom access control must be implemented as a PL/SQL procedure that must be specified per domain.

The signature of the plug-in is:

CREATE OR REPLACE PROCEDURE custom_access_control (
   site_id         IN     NUMBER,
   document_id     IN     NUMBER,
   user_id         IN     NUMBER,
   modify          IN OUT NUMBER,
   delete          IN OUT NUMBER
)
Parameter Description
site_id Not used
document_id Document ID of document to be checked
user_id User ID of user making the request
modify Return 0 to disallow modifications; 1 to allow.
delete Return 0 to disallow delete; 1 to allow.

Public user

For public sites, such as the typical internet site on www.example.com, clients are not logged on. In order to be able to perform the required access control, iKnowBase require you to specify a “public user” which is used for clients which are not logged on. By giving this user access to the required public documents, public (not logged on) clients will also see this content.

Further, sometimes you want to make sure that all users always see the same image of a site. For example, when searching on the www.example.com site, you do not want logged on users to find their private content from the intranet. By selecting “always run as this user” for the corresponding domain, every request will look like a public (not logged on) request.

Weight on free-text search

iKnowBase utilizes the advanced Oracle Text search engine. This engine lets you specify different weight to different search criteria, so that certain search hits are prioritized over others.

The domain properties let you specify the search criteria weights used for searches originating at the specified domain.

Use of search weights is for advanced setups. In general, higher values give higher weight.

Attribute Security Function

The attribute security function enables you to implement logic which decides whether document attributes are savable or just visible. The attribute security function is called upon opening an existing document in an iKnowBase Form and saving an existing document, both through a Form, through the WebDAV service and through the Service API.

When the end user opens an existing document in an iKnowBase Form, read-only document attributes are displayed, but are not available for update. The status of a document may change after the end user has opened in an iKnowBase Form, and document attributes may have become read-only even though available for update in the iKnowBase Form. When the end user saves an existing document from iKnowBase Form, changes to read-only document attributes are ignored.

If an end user tries to save an Office document to an iKnowBase document for which the file document attribute is read-only, he gets an error message.

If a method in the iKnowBase Service API is used for updating an existing iKnowBase document, the save operation will fail if one of the read-only document attributes is changed. In this situation, an error message is logged to the IKB_ERROR_TAB table.

Enable and Disable the Attribute Security Function

You enable the attribute security function by setting the attribute_security_function constant to the name of the attribute security function in the IKB_GLOBAL_PREFS database package. Example:

attribute_security_function CONSTANT varchar2(92) := 'iknowbase.sample_attribute_security';

You disable the attribute security function by setting the attribute_security_function constant to empty string in the IKB_GLOBAL_PREFS database package:

attribute_security_function CONSTANT varchar2(92) := '';

Note: The attribute_security_function constant must be declared and initialized.

Signature of the Attribute Security Function

The document attribute rules should be implemented in the database function as specified by the attribute_security_function constant.

It should follow the following signature:

FUNCTION sample_attribute_security (p_params ot_attribute_security) 
RETURN ct_secured_attributes;
Parameter Description
p_params Information about the attribute security request, containing information like the document id, parent document id, user id, id of the iKnowBase Form, and document type id.
RETURN An array of attributes that should be read-only. Note: The attribute ot_secured_attribute.document_reference is only for internal use, and you are not required to assign a value to it.

Run custom access control

Custom access control enable you to define an additional control to the default iKnowBase access control when validating if a user has read access to a document or not. If enabled, a customable function is added to all queries used for this type validation. Be aware if enabled it will be executed across all viewers and domains. The only place you can override it is by adding a custom access control at viewer definition level.

Enable and Disable the custom access control

You enable custom access control by setting the run_custom_access_control constant to TRUE in the IKB_GLOBAL_PREFS database package. When set to true, a conditional compile is executed and the custom function is enabled for the schema. Example:

run_custom_access_control CONSTANT boolean := TRUE;

You disable the custom access control by setting the run_custom_access_control constant to FALSE in the IKB_GLOBAL_PREFS database package:

run_custom_access_control CONSTANT boolean  := FALSE;

Note: run_custom_access_control must be declared and initialized. By default, an empty function is provided with return code = 0.

Signature of run_custom_access_control

It has the following signature:

run_custom_access_control (
                           p_document_id   IN         NUMBER,
                           p_user_id       IN         NUMBER,
                           p_acl_guid      IN         RAW,
                           p_acl_id        IN         NUMBER,
                           p_owner_id        IN         NUMBER) return number;
Parameter Description
p_document_id Document id
p_user_id User identificator in iKnowBase
p_acl_guid The GUID of the ACL if the document has an ACL
p_acl_id The ID of the ACL if the document has an ACL
p_owner_id The Owner ID of the document
RETURN 1 will give access even if the user has no access to the document, 0 means the user must have ordinary access to the document