Overview

As of today, search in Document app is quite poor and relies on search made in the old Docman. Docman search do work but has a few pitfalls:

• it's ugly when users comes from Document.
• the search is hard to configure (to by default, if you are looking for document "ID", it's painful to add the criteria before search).
• the search result has fixed columns and it's inconvenient.

This story is about adding a dedicated search screen into Document app.

The access to search is the same as today, the top right field where the global search can be typed and direct access to filters with "Advanced":

Search screen

Search

The underlying REST route will be something like GET /docman_folders/:id/search?...

By default, the search screen propose all the document properties for search. The Hard Coded properties (that are used) as well as the custom ones defined by the project.

In addition to the document properties, there are 2 special search criteria that are available:

• The actual filename
• The file type (file, embedded, wiki, link, ...)

The behaviour of the search is the same that is already available with usage of patterns, see the existing search capabilities:

When searching with multiple criteria (for instance ID & title) the search will be done with a AND: `id=1234 AND title="foo*"` there is no way to make a `OR` query at this stage of implementation.

Search is contextual to the folder where the query is done (ie. search is done in the currently selected sub folder)

The search criteria can be selected (see bellow) but the order is fixed. The first criterion are the one of the mock-up,then custom (project defined) properties are displayed in alphabetical order of the Label.

The search can be bookmarked and shared with a peer.

When the search is done in a specific folder, the breadcrumb is recalled (folders are clickable) and there is a link to search in the root folder (search criteria are kept).

Results

Results are rendered as a table. By default, all the used document properties (hard coded & project defined) are displayed. If the number of columns is too large, there is an horizontal scroll. In addition to the properties, there are 2 special columns that are displayed:

• The document path (parent folders)
• The filename when the document is of type "File"

The results are paginated. The default page is 50, not configurable.

The displayed columns can be selected (see bellow) but the order is fixed. The first columns are the one displayed in the mock-up (ID, title, etc) then custom (project defined) properties are displayed in alphabetical order of the label.

When hovering a row, the quicklook button is displayed at the right of the screen (even when the user scrolls). The "quicklook" view cannot be bookmarked.

Sort

Results can be sorted by clicking on the corresponding column (only one column can be selected at the time of this story). The first click on a column sort ASC (a -> z, 1 -> 9, ...) a second click on the column sort DESC (z -> a, 9 -> 1, ...).

By default, sort is done on Last update date DESC (even if the column is not displayed) so the last documents are displayed first.

Search configuration

By default, all the fields are available for search and on table results. However if there are a lot of them, it might difficult to use so, instead of having a full configuration for both project and users (that would be costly to implement) a first configuration level is to allow document administrators to configure the fields that can be used in search and in table results.

As this configuration should only affect a very few number of projects, we decided to limit the feature coverage to the absolute minimum:

• it's not possible to choose the order of the columns
• when a new metadata is added, it should be added manually to the configuration to appears in search criteria and columns
• the configuration is not inherited when projects are duplicated (create project from another one)
• It's not possible to import/export this configuration via XML