Alfresco Filtered Search – How to display facet values of a date filter as date buckets or ranges

Filtered or faceted search within Alfresco allows users to filter and customize their results by applying multiple filters to their search results in a navigational way. Filtered search breaks up search results into multiple categories and allows the user to drill down or further restrict their search results based on those filters.

You can configure filtered search either by using the configuration files or by using the Share Search Manager.

With the Search Manager you can see details of existing search filters and also create new filters. In the Search Manager you can quickly create your own custom filters with a wide range of options available.

Create a new filter that uses a date property to filter results; you will see that the facet values for this date filter are not grouped in date buckets or ranges. Instead the facet values for the date property are displayed based on the full time stamp. For example see the Release Date and Valid To Date filter values in the following screenshot.

If you want to display the facet values of a date filter as date buckets or ranges, similar to how facet values are displayed for Created and Modified dates then take a look at the date buckets display handler configuration in the “solr-facets-context.xml” file and configure a similar handler for your date filter.

Take a look at the following configuration for date buckets display handler in the solr-facets-context.xml file:

   <bean id="facet.dateFacetFields" class="org.springframework.beans.factory.config.SetFactoryBean">

      <property name="sourceSet">

         <set>

            <value>@{http://www.alfresco.org/model/content/1.0}created</value>

            <value>@{http://www.alfresco.org/model/content/1.0}modified</value>

         </set>

      </property>  

   </bean>

   <bean id="facet.dateBuckets" class="org.springframework.beans.factory.config.MapFactoryBean">

      <property name="sourceMap">

               <map>

                  <!-- Bucket => yesterday TO today -->

                  <entry key="[NOW/DAY-1DAY TO NOW/DAY+1DAY]" value="faceted-search.date.one-day.label" />

                  <!-- Bucket => Last week TO today -->

                  <entry key="[NOW/DAY-7DAYS TO NOW/DAY+1DAY]" value="faceted-search.date.one-week.label" />

                  <!--  Bucket => Last month TO today -->

                  <entry key="[NOW/DAY-1MONTH TO NOW/DAY+1DAY]" value="faceted-search.date.one-month.label" />

                  <!--  Bucket => Last 6 months TO today -->

                  <entry key="[NOW/DAY-6MONTHS TO NOW/DAY+1DAY]" value="faceted-search.date.six-months.label" />

                  <!--  Bucket => Last year TO today -->

                  <entry key="[NOW/DAY-1YEAR TO NOW/DAY+1DAY]" value="faceted-search.date.one-year.label" />

               </map>

      </property>

   </bean>

   <bean id="facet.dateBucketsDisplayHandler" class="org.alfresco.repo.search.impl.solr.facet.handler.DateBucketsDisplayHandler" parent="baseFacetLabelDisplayHandler" >

      <constructor-arg index="0">

         <ref bean="facet.dateFacetFields" />

      </constructor-arg>

      <constructor-arg index="1">

         <ref bean="facet.dateBuckets" />

      </constructor-arg>

   </bean>

After configuring a custom date buckets display handler similar to the one defined in “solr-facets-context.xml” file, the facet values of the date filter will be displayed as date buckets or ranges. For an example see the Release Date and Valid To Date filter values in the following screenshot.

Kerberos authentication is not working; now what?

Debugging Kerberos authentication should be approached in a two-step process. The first is to make sure the Active Directory Kerberos users are properly created and Kerberos is configured correctly. You will use the “klist” and “kinit” commands to verify the Kerberos setup. The second, is to login into your Alfresco instance with Kerberos set as the only authentication option in your Authentication Chain. If the login fails you should turn on Kerberos debugging. This breaks the debugging into two separate phases; #1) the Kerberos install/configuration on your Active Directory server and #2) your Alfresco configuration and edited configuration files.

Phase #1:

Verify that the Kerberos users are properly created and Kerberos is configured correctly.

cd /etc

klist -k httpredhat.keytab

Keytab name: FILE:httpredhat.keytab

KVNO Principal

---- --------------------------------------------------------------------------

   0 HTTP/redhat.formtek.local@FORMTEK.LOCAL

                                 

klist -k cifsredhat.keytab

Keytab name: FILE:cifsredhat.keytab

KVNO Principal

---- --------------------------------------------------------------------------

   0 CIFS/redhat.formtek.local@FORMTEK.LOCAL

kinit -k –V -t /etc/keys/cifsredhat.keytab "CIFS/redhat.formtek.local"

Authenticated to Kerberos v5 

kinit -k –V -t /etc/keys/httpredhat.keytab "HTTP/redhat.formtek.local"

Authenticated to Kerberos v5

Phase #2:

If Phase #1 is verified and returning the proper values but your Alfresco authentication login fails you can now debug Kerberos issues using the log4j properties in the alfresco.log file. The file is located in ‘<Alfresco_Home>/tomcat/webapps/alfresco/WEB-INF/classes’ and is named ‘log4j.properties’.

log4j.logger.org.alfresco.web.app.servlet.KerberosAuthenticationFilter=debug

log4j.logger.org.alfresco.repo.webdav.auth.KerberosAuthenticationFilter=debug

NOTE: Make sure you add this to the end of the file or verify that there is only a single instance of these entries. 

The following is a sample login output:

16:16:17,818 DEBUG [app.servlet.KerberosAuthenticationFilter] New Kerberos auth request from 192.168.1.90 (192.168.1.90:22350)

16:16:18,036 DEBUG [app.servlet.KerberosAuthenticationFilter] User user1 logged on via Kerberos

How to Speed Up the Alfresco Shutdown Script on Linux

If you are running Alfresco One on a Linux platform with the bundled Tomcat configuration and you are frequently experiencing a slower-than-expected shut down of the Tomcat process, here’s a tip to configure Alfresco to force the Tomcat process to shut down more quickly.

When you use the ‘alfresco.sh stop’ or ‘alfresco.sh stop tomcat’ command, the tomcat/scripts/ctl.sh script is called to shut down the Tomcat process. The ‘stop_tomcat()’ subroutine in this script, in turn, calls the Tomcat shutdown.sh script and passes in two arguments (‘300’ and ‘-force’) in the following section of the script:

 stop_tomcat() {
    is_tomcat_running
    RUNNING=$?
    if [ $RUNNING -eq 0 ]; then
        echo "$0 $ARG: $TOMCAT_STATUS"
        exit
    fi
        if [ $TOMCAT_ASTOMCATUSER -eq 1 ]; then
            $TOMCAT_BINDIR/daemon.sh stop
        else
            $TOMCAT_BINDIR/shutdown.sh 300 -force
        fi

 

This instructs the Tomcat shutdown script to wait (or sleep) up to 300 seconds before using the ‘kill’ command to force kill the process if it is still running. If your Tomcat shutdown process is making its way into this section of script – for whatever reason, and you are not willing to wait up to 5 minutes for the process to be killed, you can reduce the ‘sleep’ argument (i.e., 300) in the tomcat/scripts/ctl.sh script to a more tolerable amount of time (e.g., 30 or 60 seconds). Although you may not want to do this in your production Alfresco installation, consider using this tip in your test/development installation if the Tomcat shutdown time becomes an issue for you.