-
-
Notifications
You must be signed in to change notification settings - Fork 645
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
Archive messages #748
Comments
Thanks for the suggestion! Since you mentioned about selective retention, I am considering between the individual message approach like you proposed or #376 or a hybrid approach, but personally I think this is a useful feature if you have multiple apps or messages of various importance and do not want to have too much clutter. I think the typical scenario is a user have an app that are much more time-sensitive than others even though the others are more important. The messages can be automatically cleaned up leaving the UI to the user much more balanced in terms of not being cluttered with no longer relevant messages. @kaitallaoua Can you look at the issue I referenced and if it can fit in your scenario since other users have requested that feature? Thanks. Internal: I think this should be easy to just add a "soft" delete endpoint and an additional parameter in /message to get the soft deleted ones, the server side should not be hard but I don't know how to do it with the android client.. |
I personally do not need automatic pruning at this time, but both could function together I suppose. Archived/marked messages could be immune to the prune, or configurable. My preferred flow is to read notifications when I get the chance, then delete all. But my important ones get deleted too. Cumbersome to individually delete ones I don't need when they outpace the fewer important ones. And if i forget, I end up deleting them all anyway :( My use case is proxmox notifications, along with other foss app notifications. I really, really want to keep/archive zfs events/faults. Right now I screenshot the gotify message which is really cumbersome lmao, then delete all. Or shift the flow to mark this app immune to auto prune, and don't click delete all anymore, let auto prune do the work. Not fan, as I like to clear them out as i've read them/resolved the issue. Don't want the 'main' list to accumulate too much. |
Thanks for the update, I will look into this some time this week, I think a soft delete is good idea even if we might not have immediate resource available to write the android client. I have been thinking about making the gotify cli work for data manipulation tasks like you mentioned too, I think it is more flexible if you can just do something like |
Is your feature request related to a problem? Please describe.
Notifications vary in importance and retention needs. It would be nice to archive/divert a message away before deleting all messages (yes I read your comment and agree about short message lifetime, but some are nice to save).
Describe the solution you'd like
Ability to archive the message. Archived messages should not be deleted when clicking "DELETE ALL" messages (that I like to click 😄 ). Similar to how https://github.com/usememos/memos does it ( just one large 'Archived' tab that contains them all).
But of course these archived messages should still be delete-able, either moving them back to "main" messages, or a "DELETE ALL ARCHIVED" or whatever.
Describe alternatives you've considered
At least individually or in bulk selection: export feature that downloads a json file or whatever of the messages for retention.
Additional context
I am aware of and read:
#518
gotify/android#303
gotify/android#260
The text was updated successfully, but these errors were encountered: