Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve system notifications #237

Closed
4 tasks done
GentlemanHal opened this issue Jul 16, 2018 · 2 comments
Closed
4 tasks done

Improve system notifications #237

GentlemanHal opened this issue Jul 16, 2018 · 2 comments
Assignees
Labels
complicated Changes that are difficult or time consuming to implement improvement Changes that improve an existing feature

Comments

@GentlemanHal
Copy link
Member

GentlemanHal commented Jul 16, 2018

Some ideas for improving system notifications:

  • Show a notification when a tray returns an error (e.g. Timeout)
  • Show a notification when a project starts building
  • Allow the user to select which notifications to show
  • Show a notification when a project is fixed
@GentlemanHal GentlemanHal added the improvement Changes that improve an existing feature label Jul 16, 2018
@GentlemanHal GentlemanHal added this to the Settings update milestone Jul 1, 2020
@GentlemanHal GentlemanHal self-assigned this Dec 8, 2020
GentlemanHal added a commit that referenced this issue Dec 21, 2020
@GentlemanHal GentlemanHal added the complicated Changes that are difficult or time consuming to implement label Jan 27, 2021
@GentlemanHal GentlemanHal removed their assignment Jan 27, 2021
@GentlemanHal
Copy link
Member Author

GentlemanHal commented Jan 27, 2021

This requires some more thought. We filter projects on the server and we allow the user to select which projects are interesting.

To be able to correctly identify all project transitions we would need to return all projects and filter on the client. This however could result in a huge amount of additional data being sent between the client and server.

Edit: We could also figure out transitions server side and have a the transition in the response. This however would still require the request to include all the previously fetched projects as the server is stateless. We do currently send the IDs of all the previously seen projects so the "include new projects" feature works so this still might be a better idea.

By default we only filter out healthy projects, so in that case we could assume missing projects are healthy. Which realistically is probably safe, but in theory they could have actually been removed from the server. However this approach no longer works if the filter has been changed to filter out more that one prognosis, and it also feels like the code could get quite messy.

@GentlemanHal GentlemanHal self-assigned this Oct 22, 2022
@cowley05
Copy link
Contributor

cowley05 commented Oct 25, 2022

We discussed this issue and came up with these 3 options...
Were currently going with option 1 as its simplest to change and none of them are ideal.

(sorry about the crudely written notes and bad images but its the original copy)

image
image
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complicated Changes that are difficult or time consuming to implement improvement Changes that improve an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants