| Info | ||
|---|---|---|
| ||
In complex installations it is often desirable to have multiple ways to view the core types of data: Members, Activities, and Learning Plans a.k.a., Applications. For example, there may be multiple contexts in which a user may need to view or search Member data, and the relevant filter criteria, result columns, and access control business rules may be different in each one. System Administrators can use advanced configuration features to create separate search screens for each scenario, without needing any custom programming in the core application. |
Supported Entities
- /wiki/spaces/DOCS/pages/580681819
- /wiki/spaces/DOCS/pages/619544577
- Learning Plan Instance Search
- Member Search (DRAFT)
Common Functionality
Member Search was implemented first and contains some special features not supported in the other cases.
...
Search Form Configuration
...
"searchFields": [...]
...
Each implementation of the search framework contains a base search model that can expose information that is not represented as Workflow Attributes. These properties can be targeted by a search field.
"target": "model.OwnerName"
...
To search against Workflow Attributes, use the "entity-scoped" syntax:
"target": "ActivityInstance.Activity Type"
...
Each search field is given a label, and the label can be a fixed string or can be pulled from the Glossary.
"label": "Glossary.Singular(Activity)"
...
"searchType": "<value>"
ExactMatch: (default) the value in the database exactly matches value entered into search formTextboxBeginsWith: the value in the database starts with the search valueContains: the value in the database contains the search valueIncludeChildren: (Member Search only) searches against the specified Member and it's "children" in the Organization Hierarchy
...
Search values can be entered into the search form using a variety of different mechanisms.
"criteriaType": "<value>"
Textbox: (default)Picklist: renders as a dropdown list- (Must also specify
"pickListName": "<name of list>")
- (Must also specify
MultiSelectList: renders as a multi-select listbox- (Must also specify
"pickListName": "<name of list>")
- (Must also specify
MemberAttribute: renders a Member Lookup attribute for choosing a specific Member
(Member Search specific)
RolePickListRoleStatusPickListMemberNameMemberType- MemberStatusPickList
MemberId
(Activity Instance Search specific)
ActivityTypeMemberKeywordDateRangeNumberRangeAutoComplete
...
Search Results Configuration
...
"resultFields": [...]
...
Each implementation of the search framework contains a base search model that can expose information that is not represented as Workflow Attributes. These properties can be displayed in the results table.
"source": "model.OwnerName"
...
To display Workflow Attributes in the results grid, use the "entity-scoped" syntax:
"source": "ActivityInstance.Activity Type"
...
Custom formatting can be used to display a link:
"format": "<a href=\"...\">{ActivityInstance.Id}</a>"
...
To give a column a label that is controlled by a Glossary term:
"label": "Glossary.Singular(Activity)"
...
Custom actions or links for each search result
...
"links": [...]
...
Each custom link can use a FontAwesome icon
"icon": "fa-eye"
...
Each custom link can be given a custom CSS class, which can be used to add dynamic behavior to that link. (This is an advanced configuration and may require development assistance)
"triggerClass": "jq-some-class-name"
...
Custom Page Buttons
...
"toolbarButtons": [...]
...
"order": "1"
...
Each button can be given a custom CSS class, which can be used to add dynamic behavior to that button. (This is an advanced configuration and may require development assistance)
"cssClass": "jq-some-class-name"
...
Forced Filters
...
{
"target": "model.CurrentStepId",
"values": [1, 2, 3]
}
...
{
"operator": "Or",
"filters": [
{
"target": "ActivityOffering.Offering Primary Contact",
"matchesAssociationTypes": [
"CurrentUser"
]
},
{
"target": "model.OwnerMemberId",
"matchesAssociationTypes": [
"CurrentUser",
"Organization"
]
}
}
...
Additional Directives
...
"pageInstructions": "<p>Lorem ipsum...</p>"
"noResultsMessage": "No records matched the criteria"
"searchButtonLabel": "Filter"
...
"showWorkflowButtons": true
...
"defaultSort": "Activity.Title"
"defaultSortDirection": "Ascending"
...
"defaultPageSize": 20
"searchResultCap": 2000
...
| Child pages (Children Display) |
|---|
...
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
| title | Terminology |
|---|
The terms "queue" and "search" are both to describe this feature, but indicate different use cases.
A queue is a page that shows users a list of things that they should work on next. This is often used to represent things like a "review queue" where the default criteria return the list of things the user needs to worry about.
A search is a page that displays multiple search criteria fields and allows users to run ad-hoc searches.
...
More information about this topic can be found here: /wiki/spaces/DOCS/pages/3808526732