search

pushbits / server

A simple server for push notifications via Matrix (and a minimalistic alternative to Pushover and Gotify) 🚀📯
https://www.pushbits.io
ISC License
305 stars 18 forks source link

Topic is changed after container restart #58

Closed ich777 closed 1 year ago

ich777 commented 1 year ago

Hi, first of all I would like to thank you for developing such a great piece of software, really appreciate your work on this and make heavy use of Pushbits! :)

Now to my issue: I've noticed is that the Topic is reset to Application n when restarting the container. Is this done on purpose? Could this be changed since it would be nice to set a custom topic that is not changed back to the application number.

I also have two side question, wouldn't it make also sense to ship CLI with the server container too since this would make the usage from the container much easier by simply connecting to the console from the container and issuing cli. Would it be okay for you if I create a Unraid template for your container so that people are able to easily set up your container?

Many Regards, Christoph

eikendev commented 1 year ago

Hi @ich777, thanks for opening this issue!

The topic is reset on purpose, yes, but I'm open to change this behavior if there is a good reason for it. Would it make sense to make the topic configurable in the PushBits config?

Regarding the CLI, we can have it in the container, but let's open a separate issue for this.

An Unraid template would be neat. If this is not a huge effort, very happy for you to give it a shot. Thanks!

ich777 commented 1 year ago

@eikendev thank you for the response and again, thank you for that great piece of software, I really, really, like it! :)

The main reason or better speaking benefit, at least to me and in my specific use case is that I can set the topic to a custom URL which is always on top on the Element Desktop app. For example I have a notification group, actually a few groups, where I notify people about version updates from specific applications and if the topic is set to a specific URL it would be really easy for them to download the application, see the changelog, visit the application itself and so on.

From my perspective an option in the config to turn off the update from the Topic would be nice.

Regarding the CLI, we can have it in the container, but let's open a separate issue for this.

Will do that tomorrow if possible, getting pretty late over here.

An Unraid template would be neat. If this is not a huge effort, very happy for you to give it a shot. Thanks!

Sure thing, will notify when it's done and available in the CA App, do you have a donation link that I can link in this template?

eikendev commented 1 year ago

I've opened #59. Can you confirm this patch fixes your issue?

do you have a donation link that I can link in this template?

Not yet, don't think this is necessary so far.

ich777 commented 1 year ago

@eikendev thank you! Compiled PushBits based on PR #59 and can confirm it is working perfectly fine, please note that I've only tested resetroomtopic: false.

ich777 commented 1 year ago

@eikendev thank you for merging the PR! The template is also done for Unraid, is there a plan when the Docker image will be updated since otherwise it will throw an error if users download the config.example.yml because of the added repairbehavior: configuration.

Attached a screenshot what the template will be look like: grafik

Here is also a screenshot how it will look like when it's installed on Unraid: grafik

eikendev commented 1 year ago

Nice! I wrote it down for the weekend, will update you once I get there.

ich777 commented 1 year ago

Thank you, looking forward to the update so that I can push the template to the CA App so that it is easily accessible for all Unraid users.

Another side question, would it be somehow possible to ignore extra options from the config.yml if they are passed through since like it is now the application or container simply would not start because it finds configurations which are not recognized <- this is really a minor thing and I also can see why this is like it is now.

eikendev commented 1 year ago

Hm, not sure I would like this from a design perspective: Leaving invalid configurations silent could lead to unintended behavior, e.g., if the administrator sets an option which is only supported by a later version, yet believing that this option is now correctly set. What would be the use case from your side?

ich777 commented 1 year ago

I completely understand that but since you've already merged the PR for repairbehavior: and now that the config.example.yml has the change in it the container won't run if users use the content from config.example.yml.

That's why I also have to wait for the update from the container since otherwise this would be a broken release. In it's current state the container and the config.example.yml are incompatible and will leave the container in a broken state and it won't start. Can you please push a container update ASAP to solve this issue?

eikendev commented 1 year ago

Fixed in 77765e77a9ecf4f633316e11a835bb19357d2929.