Jira Server: persist search query

[Dschoordsch]

Functionally similar to persistJiraSearchQuery and persistGitHubSearchQuery.

Acceptance criteria

• add generic table to persist integration specific settings (see Integration task architecture spec'd #5968)
• add mutation persistIntegrationSearchQuery and add logic for Jira Server
• add logic to UI and TaskIntegration so it is used
• create ticket to migrate persistJiraSearchQuery and persistGitHubSearchQuery over

[jordanh]

Include in next sprint?: N
See the discussion in Planning for Sprint #​​96

Powered by Parabol

[Dschoordsch]

Story points: 13
See the discussion in Sprint Poker #​​1

Powered by Parabol

[Dschoordsch]

Include in next sprint?: Y
See the discussion in Sprint Poker #​​1

Powered by Parabol

[igorlesnenko]

@Dschoordsch Our search queries have different format for different integrations, and may get even more differences in the future if we want to persist more filters.

For example, for JiraServer we persist the following information:

queryString
isJQL
projectKeyFilters

For GitHub it is only:

queryString

if we want a generic mutation persistIntegrationSearchQuery we probably need to submit the whole query as single JSON field and read an array of JSON on the UI

teamMember {
  integrations {
    atlassian {
      searchQueries
    }
  }

This way we can probably also implement generic logic on the UI.

Does that sound okay to you?

[igorlesnenko]

I also suggest to use a separate table IntegrationSearchQuery

id 
service
query: jsonb
lastUsedAt

As currently, we load all the queries and manually check uniqueness, do sorting, slicing array etc.
This all could be done with a single insert on conflict update

[Dschoordsch]

@igorlesnenko I like the idea of leaving the conflict resolution up to the database. What I would maybe add is a providerId so if a user for whatever reason changes from one hosted Jira Server to a different one, it will not reuse the old search queries.

I'm not 100% certain anymore whether we should have integration specific tables or one generic one. I personally dream of a generic one because in the ideal case for a new integration you would only need to implement the TaskIntegrationManager and adapt the UI.

On the other hand we could achieve this also by having integration specific tables and treat these as being owned by the integration, i.e. only the integration manager itself reads and writes to it.