Allow saving of filters

[HollaG]

Is your feature request related to a problem? Please describe.
There already exists two "default" custom views for users. Let's allow users to save a custom selection of filters.

Describe the solution you'd like
A save button can be provided (location TBC). This could open a dialog asking the user to choose a label. Upon save, this would appear in the current dropdown (for contributions / currently active). As we have no backend, we can potentially simply save the configs in localstorage (non-sensitive, anyway)

[Eclipse-Dominator]

Good idea!

Right now, we can "transfer" filters via image URLs, as shown here. This means we could technically store all filters and repositories by saving the URL.

Adding a customizable view is a good enhancement, but here are some key considerations:

• What should be saved versus what can be saved?
• Some filters depend on the repository. How should these be stored to ensure consistency?

Would love to hear your thoughts on how you'd approach handling such filters!

[HollaG]

Some initial ideas~

• As mentioned, we can store the url parameters (perhaps in LocalStorage - it doesn't have to be secure)
• It should be repository-specific. We can allow users to set a custom name for the saved filter.
  a potential enhancement is that we can allow them to choose a default view / default filter to be applied on load
• CR D operations should be allowed ( no need for update as they can simply delete the filter and re-add it)

we could use the following schema:
[in localstorage]
key=repositoryname
value: type

{ 
  name: String,
  filter: String // the url
}[]

[HollaG]

Upon further inspection, there already exists a repo-url-cache-service.ts that caches repository names. We can make use of the same name to save the custom filters.

[HollaG]

Behaviour upon filters becoming invalid
Use case: when a label or milestone gets deleted / closed
Option 1: ignore and filter based on other options

• this is the current behaviour, same when sharing URL

Option 2: Remove the saved filter set

• THere is currently no behaviour implemented in the URL parser to tell if there is an invalid filter applied.
• This could perhaps be a new PR to remove it from the URL as well upon detecting invalid filter

[nknguyenhc]

Some initial ideas~

• As mentioned, we can store the url parameters (perhaps in LocalStorage - it doesn't have to be secure)
• It should be repository-specific. We can allow users to set a custom name for the saved filter.
  a potential enhancement is that we can allow them to choose a default view / default filter to be applied on load
• CR D operations should be allowed ( no need for update as they can simply delete the filter and re-add it)

we could use the following schema: [in localstorage] key=repositoryname value: type

{ 
  name: String,
  filter: String // the url
}[]

Not sure if milestones and labels are a strong-enough reason for making preset filters repo-specific, but making the preset filters repo-specific only makes it more confusing. There are cases where users want to make preset filters that can applied across repos. Furthermore, user can switch to another preset filters if he needs to change the preset filter.