Content
View differences
Updated by Marc Alcobé 4 months ago
**As a** mobile app user **As** a \[enter role of user\]
**I want to** access a dedicated global search module \[enter objective\]
**so that** I can search across work packages and projects from one central place in the app. \[enter desired result\]
**Acceptance criteria**
* A dedicated “Search” entry point is available in \[TBD\] Should the main navigation (e.g., bottom navigation bar) with global search and the work done on <mention class="mention" data-id="71053" data-type="work_package" data-text="###71053">###71053</mention>.
* Tapping packages tab be the search icon opens a full-screen global search module. same like in Wrike, Jira or Asana apps?
* The Make work package search module contains:
* A search input field with focus on open.
* Tabs for:
* Work packages
* Now work packages should be searchable by ID also.
* Projects
* Projects have new filters for favorites, status and type.
* The module is independent from Home and other modules (no embedded search behavior). possible in the global search.
* When navigating back, Make searching projects possible in the user returns to the previous module. global search.
* The search state (query + selected tab + filters) is preserved during \[TBD\] Include filters in the same session unless explicitly cleared.
* The global search bar of from the home page opens or open directly the new separate search module. search.
* Mimic \[TBD\] Find a way to mimic a similar behaviour to the recently viewed list on search opening.
* This will not sync with the recently viewed list of the search on the web app.
* We limit the recently viewed list opening (or decide to 20 work packages.
wait until API implementation).
* We need to store \[TBD\] Review the data per user and instance that is persisted even after logout.
* The widget on filters available in the home page "Recently edited" also becomes "Recently viewed" with this logic.
global search.
**Technical notes**
* Introduce a dedicated route/screen for Global Search.
* Search input should:
* Support debounced requests.
* Support clearing input (clear icon).
* Tab state and filter state should be maintained locally (state management solution depending on architecture).
* Ensure API endpoints support cross-entity querying (or separate calls per tab).
* Performance: Search requests must be optimized to avoid excessive calls. <br>
**Permissions and visibility considerations**
* All authenticated users with permission to view at least one searchable entity (work packages, projects, time logs). _To whom is this feature visible?_
* Tabs should only be visible if the user has permission for the respective entity. _When is it not visible?_
**Translation considerations**
* Key terms:
* Global search
* Search
* Work packages
* Projects
* Time logs
* Recently viewed
* Filters
* Status
* Type
* Project
* Log date
_Key terms and phrases in the key languages_
**Out of scope**
* Advanced search operators (AND/OR, etc.)
* <mention class="mention" data-id="71053" data-type="work_package" data-text="###71053">###71053</mention>
* _Time logs (TBD)_
* _Time logs have new filters for log date and project._ <br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._
**I want to** access a dedicated global search module
**so that** I can search across work packages and projects from one central place in the app.
**Acceptance criteria**
* A dedicated “Search” entry point is available in
* Tapping
* The
* A search input field with focus on open.
* Tabs for:
* Work packages
* Now work packages should be searchable by ID also.
* Projects
* Projects have new filters for favorites, status and type.
* The module is independent from Home and other modules (no embedded search behavior).
* When navigating back,
* The search state (query + selected tab + filters) is preserved during
* The
* Mimic
* This will not sync with the recently viewed list of the search on the web app.
* We limit the recently viewed list
* The widget on
* Introduce a dedicated route/screen for Global Search.
* Search input should:
* Support debounced requests.
* Support clearing input (clear icon).
* Tab state and filter state should be maintained locally (state management solution depending on architecture).
* Ensure API endpoints support cross-entity querying (or separate calls per tab).
* Performance: Search requests must be optimized to avoid excessive calls.
**Permissions and visibility considerations**
* All authenticated users with permission to view at least one searchable entity (work packages, projects, time logs).
* Tabs should only be visible if the user has permission for the respective entity.
**Translation considerations**
* Key terms:
* Global search
* Search
* Work packages
* Projects
* Time logs
* Recently viewed
* Filters
* Status
* Type
* Project
* Log date
* Advanced search operators (AND/OR, etc.)
* <mention class="mention" data-id="71053" data-type="work_package" data-text="###71053">###71053</mention>
* _Time logs (TBD)_
* _Time logs have new filters for log date and project._
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._