Custom document search attributes are associated with a document type. They specify which pieces of document data will be made searchable for documents of that type. When you take action on a document in the workflow engine, a background process extracts the custom search attributes from the document and adds them to a database table where they can be queried as part of a custom document search. These custom search attributes are defined and associated along with document types in WorflowData XML files, and are added to Rice via the XML ingester. They are defined within (using XPath notation) /data/ruleAttributes/ruleAttribute tags, and are associated with specific document types within /data/documentTypes/documentType/attributes/attribute tags.

A custom search attribute's logic is defined in a Java class that implements the SearchAttribute interface. A SearchableAttribute implementation defines:

There is a built in SearchAttribute implementation, SearchableXMLAttribute, that is highly configurable via XML and will meet most requirements. If there is need for more complex or specific behavior, a custom SearchAttribute implementation can be written and utilized as well.

DocumentSearchAttributes is much like XMLRuleAttributes, except that DocumentSearchAttributes is responsible for drawing input fields on the Document Search form and collecting data for the query, as opposed to analyzing data for routing evaluation (done by XMLRuleAttributes).

<visibility>
    <column visible="false"/>

</visibility>

<visibility>
    <field visible="false"/>
</visibility>

Use code like this in the XML file to display column(s) and field(s) based on the user's workgroup:

<visibility>
    <field>
        <isMemberOfWorkgroup>WorkflowAdmin</isMemberOfWorkgroup>
    </field>
    <column>
        <isMemberOfWorkgroup>WorkflowAdmin</isMemberOfWorkgroup>
    </column>
</visibility>

The example above indicates that the field and column only display for users who are a member of the workgroup, WorkflowAdmin.

A shortcut to configure the visibility for both fields and columns is the <fieldAndColumn> tag. A <fieldAndColumn> example:

<visibility>
    <fieldAndColumn>
        <isMemberOfWorkgroup>WorkflowAdmin</isMemberOfWorkgroup>
    </fieldAndColumn>
</visibility>

Declaring <type> as hidden is equivalent to setting visibility to false. An example of <type> and <visibility>, equivalent to a hidden field:

<searchingConfig>
    <fieldDef name="department" title="Department">
        <display>
            <type>text</type>
        </display>
        <visibility>
            <field visible="false"/>
        </visibility>
        <fieldEvaluation>
            <xpathexpression>normalize-space(substring-before(//department, ' '))</xpathexpression>
        </fieldEvaluation>
    </fieldDef>

</searchingConfig>


<!-- The above is equivalent to the following searching configuration -->

<searchingConfig>
    <fieldDef name="department" title="Department">
        <display>
            <type>hidden</type>
        </display>
        <fieldEvaluation>
            <xpathexpression>normalize-space(substring-before(//department, ' '))</xpathexpression
>
        </fieldEvaluation>
    </fieldDef>

</searchingConfig>

You can modify the search criteria and the display of the search screen by passing in URL parameters. Only use this method when the configuration desired is preferable and not required. If a particular piece of the search criteria is required, please see the section below titled, Using a Custom Search Criteria Processor.

http://yourlocalip:8080/DocumentSearch.do?searchableAttributes=firstname:John,lastname:Smith

The best way to do custom criteria processing is to implement a custom class that extends the class org.kuali.rice.kew.docsearch.DocumentSearchCriteriaProcessor. This file is ingested as a Workflow Attribute in KEW, using the <type> of DocumentSearchCriteriaProcessorAttribute. Once the Workflow Attribute is ingested, you can set the name value of the ingested attribute on one or more document type xml definitions in the Attributes section. A document type can only have one Criteria Processor Attribute.

Creating a child class of the DocumentSearchCriteriaProcessor class, a client can override various methods to modify the behavior of the search. The DocumentSearchCriteriaProcessor class can access the WorkflowUser object of the user performing the search. By having access to these objects, a custom processor class could implement dynamic hiding and showing of specific criteria fields based on ordinary user’s data or search field data.

public class CustomDocumentSearchCriteriaProcessor extends DocumentSearchCriteriaProcessor {

/**
     
  *  Always hide the header bar on all search screens
     
  */
   
    @Override
    public boolean isHeaderBarDisplayed() {
        return Boolean.FALSE;
    
    }

    

/**
  *  Always hide all criteria and buttons on the advanced search screen
     
  */
    
    @Override
    public Boolean isAdvancedSearchCriteriaDisplayed() {
        return Boolean.FALSE;
    }


/**
  *  Hide the Initiator Criteria field on both Basic and Advanced Search screens
  */
    @Override
    public List<String> getGlobalHiddenFieldKeys() {
        List<String> hiddenKeys = super.getGlobalHiddenFieldKeys();
        hiddenKeys.add(DocumentSearchCriteriaProcessor.CRITERIA_KEY_INITIATOR);
        return hiddenKeys;
    }


/**
  *  Hide the Document Title criteria field on the basic search screen
  *  Hide the searchable attribute field with name 'givenname' on the basic search screen
  */
    @Override
    public List<String> getBasicSearchHiddenFieldKeys() {
        List<String> hiddenKeys = super.getAdvancedSearchHiddenFieldKeys();
        hiddenKeys.add(DocumentSearchCriteriaProcessor.CRITERIA_KEY_DOCUMENT_TITLE);
        hiddenKeys.add("givenname");
        return hiddenKeys;
    }


/**
  *  Hide the Document Title criteria field on the advanced search screen
  *  Hide the searchable attribute field with name 'givenname' on the basic search screen
  */
    
    @Override
    public List<String> getAdvancedSearchHiddenFieldKeys() {
        List<String> hiddenKeys = super.getAdvancedSearchHiddenFieldKeys();
        hiddenKeys.add(DocumentSearchCriteriaProcessor.CRITERIA_KEY_DOCUMENT_TITLE);
        hiddenKeys.add("givenname");
        return hiddenKeys;
    
    }
}

To implement a custom result set limit, simply override the method getDocumentSearchResultSetLimit() from the StandardDocumentSearchGenerator class.

An example of a custom XML result processor:

<ruleAttribute>
    <name>KualiContractsAndGrantsDocSearchResultProcessor</name>

    <className>org.kuali.rice.kew.docsearch.xml.DocumentSearchXMLResultProcessorImpl</className>
    <label>Contracts &amp; Grants Document Search Result Processor</label>
    <description>Attribute to allow for custom search results for Contracts &amp; Grants documents</description>
    <type>DocumentSearchXMLResultProcessorAttribute</type>
    <searchResultConfig overrideSearchableAttributes="false" showStandardSearchFields="false">
        <column name="docTypeLabel" />
        <column name="docRouteStatusCodeDesc" />
        <column name="initiator" />
        <column name="dateCreated" />
    </searchResultConfig>

</ruleAttribute>

The result of the code displayed above is a Search Result table with these columns:

The key for the search result customization is focused on the elements and column tag(s) under the <searchResultConfig>.

Attributes that are included in the <searchResultConfig> tag:

Attributes that can be added in a <column> tag:

For <column> with sortable = true, the field title becomes a link and when a user clicks the link, KEW sorts the results by that column.

An example of a custom ruleAttribute:

<ruleAttribute>
    <name>KualiContractsAndGrantsDocSearchResultProcessor</name>

    <className>org.kuali.rice.kew.docsearch.xml.DocumentSearchXMLResultProcessorImpl</className>
    <label>Contracts &amp; Grants Document Search Result Processor</label>
    <description>Attribute to allow for custom search results for Contracts &amp; Grants documents</description>
    <type>DocumentSearchXMLResultProcessorAttribute</type>
    <searchResultConfig overrideSearchableAttributes="true" showStandardSearchFields="false">
        <column name="docTypeLabel" />
        <column name="docRouteStatusCodeDesc" />
        <column name="initiator" />
        <column name="dateCreated" />
        <column name="proposal_number" />
        <column name="chart" />
        <column name="organization" />
        <column name="proposal_award_status" />
        <column name="agency_report_name" />
    </searchResultConfig>
</ruleAttribute>

You may also use a custom Document Search Result Processor by extending the class org.kuali.rice.kew.docsearch.StandardDocumentSearchResultProcessor and overriding individual methods.

Validates that the authenticated user is or isn't the initiator of the document.

Validates that the authenticated user is or isn't Route Log Authenticated.

Route Log Authenticated means that one of these is true:

Route Log Authenticated checks for security but does not simulate or check future requests.

Validates based on a custom-defined class. Class must have implemented the SecurityAttribute interface class. There are two methods of defining a security attribute:

Validate that the authenticated User ID of the given idType is equivalent to the searchable attribute field with the given name.

The following id types are valid:

Validate that the authenticated user is a member of the workgroup with the given name.

Validate that the authenticated user has the given role. The existence and names of these roles are determined by your setup in KEW. (You can create these roles when you implement WebAuthenticationService.) Typically, the roles mirror your organization structure.

For example, you may choose to expose these roles:

If the role is marked as allowed=true, than anyone with that role passes the security constraint. If the role is marked as allowed=false, then if the individual has the given disallowed role but none of the allowed roles, he or she fails the security check.