Topic is changed after container restart about server HOT 10 CLOSED

Fixed in 77765e7.

from server.

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!

from server.

@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?

from server.

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.

from server.

@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.

from server.

@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:

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

from server.

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

from server.

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.

from server.

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?

from server.

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?

from server.