Config UI: visualize Messaging

[Maschga]

🖼 visualize messaging section
🧩 migration: split email-uri into host-, port-, user-, password-, from- and to-keys
🧩 migration: split ntfy-uri into host- and topics-keys
🧩 migration: add disable-key to each predefined event
🔕 add toggle to enable or disable specific events
📋 add default title- and message-values to each not-predefined event in the browser's language
👇 custom service: yaml editor: add Format & Save-button (to avoid jumping key: value-pairs when writing yaml code)
💪 use TypeScript

TODO:

• services: removing all services does work in ui but not in backend @naltatis
• test each service:
  • Pushover
  • Telegram
  • Email
  • Shout
  • Ntfy
  • Custom

Events:

Add messaging:

Messaging:

Custom: Format & Save-button:

\cc @naltatis

[naltatis]

Hi @Maschga, here a few considerations regarding the layout of this modal. We have a lot of different things to show here.

• less tabs: on mobile screens the tabs are wrapping which becomes confusing. therefore I'd recommend we organize this in two tabs: Events, Services. Similar to the existing data structure. Maybe adding a number-indicator for better overview of the enabled services.
• events: I've attached a screenshot/mock illustrating how enabling/disabling of specific events could look like. The switch + disable/grayout pattern is already used similarly on the "Issues" page. Technically it's a little tricky since a disabled status does not exist in our data structure yet. We could work around it but this would essentially mean, that the users will lose custom message text once they disable and save them. That's why I'd suggest extending the event data structure and add an optional (non-breaking) disabled attribute. All other options (forcing the user to delete title/msg, storing disabled texts in local-storage) are messy.
• services: as said initially, I'd combine the services into one tab. This functionality did not work on my machine. maybe because I updated the branch before. not sure. My expected for would be: User can click on a "add service" button, select the desired service type (mail, telegram, ...). This will add a service-block with form. User can delete this with a delete button. This is very close to our data structure. For the "service selection" we could use a dropdown button.

This looks very promising. Thanks for your work so far and sorry for my delayed response.

[Maschga]

FYI: Updated description, screenshots and TODO.

@naltatis:
I'm done with your review. 🙃
Unfortunately, there are a lot of commits again.

For the custom service, I had to add a library to get the conversion from string to object and vice versa to work properly, and I added a button because otherwise this conversion kept sorting the keys alphabetically, which caused the lines to jump around.

Regarding TODO:
I don't know if it's enough for the services to work that the Go-backend doesn't log any errors, but I think each service should be tested manually.
What do you think?

[naltatis]

@Maschga I've reviewed and tested the UI code. Lot's of code, but good to understand and easy to follow. Looks really good! Only thing we should change here is the custom service handling (see comment above).

I made a few smaller changes (textarea handling, translations, help links, ...).

I'll now have a closer look at the go changes now and see if I can fix the outstanding todo.

[naltatis]

I don't know if it's enough for the services to work that the Go-backend doesn't log any errors, but I think each service should be tested manually. What do you think?

Since we're not changing the underlying mechanism I dont think it's necessary to test all these service individually. We should test at least one to verify that we didn't fundamentally break the mechanism (e.g. redaction), but if one works the others should work as well.