Advanced Configuration | ||
---|---|---|
Previous | Next | |
Building iKnowBase Applications | Using Apache Solr for Content Search |
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.
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.
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. |
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 specifiy 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.
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.
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 iKnowBase Form, iKnowBase MS Office Add-in, and iKnowBase 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.
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.
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 information 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. |
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.
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.
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 |
Previous | Top | Next |
Building iKnowBase Applications | Using Apache Solr for Content Search |