You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've just stumbled upon #3 and #1 and I thought: why not simply execute a user provided script if an update is available? Then the user can decide if they want to send a mail, try an automated update or do something completely different.
Each software entry could take an optional script path to be executed. The script should accept the new version nr. and release download URL as arguments. Would be easier to implement than #1 and #3 and also more flexible imho...
The text was updated successfully, but these errors were encountered:
juk0de
changed the title
Script execution as alternative to notfication
Script execution as alternative to notification
Nov 12, 2023
Hey @juk0de
a User-Provider script is a great idea. Agree that it would replace #1 and #3 (or leave the decision to the user).
I would not see a user provided script this alternative, but additional/optional step after sending a notification. Or, if you see this as requirement: provide an additional parameter per software entry sendGotification that enables/disables the gotify notification sending, per software.
So I see two features in this:
user provided script as additional, optional step
toggle to disable notifications individually per software entry.
Unfortunately I currently do not find time to implement this.
However I can offer to review pull requests if you like to implement one (or both) of the features :-).
I've just stumbled upon #3 and #1 and I thought: why not simply execute a user provided script if an update is available? Then the user can decide if they want to send a mail, try an automated update or do something completely different.
Each software entry could take an optional script path to be executed. The script should accept the new version nr. and release download URL as arguments. Would be easier to implement than #1 and #3 and also more flexible imho...
The text was updated successfully, but these errors were encountered: