Another notification improvement suggestion
-
The recent improvements to notifications are great, but I have one more candidate that I think could be improved.
If I have multiple installs of the same app (a good example might be Wordpress, or LAMP) on different locations, it might be nice if an upgrade notification for all those locations was grouped into one, rather than triggering a notification per location.
Rather than this:
Title: $appname at $applocation updated to $appversion (package version $packageversion)
Body: The application installed at https://$applocation was updated.Changelog:
...
How about this?
Title: $appname at len($locations) locations updated to $appversion (package version $packageversion)
Body: The application installed at the following locations was updated:Changelog:
...
I guess this is very low priority, and might be a bit tricky to accomplish easily, but I think it would be a very worthwhile addition to larger installs with many apps of the same type.
-
The recent improvements to notifications are great, but I have one more candidate that I think could be improved.
If I have multiple installs of the same app (a good example might be Wordpress, or LAMP) on different locations, it might be nice if an upgrade notification for all those locations was grouped into one, rather than triggering a notification per location.
Rather than this:
Title: $appname at $applocation updated to $appversion (package version $packageversion)
Body: The application installed at https://$applocation was updated.Changelog:
...
How about this?
Title: $appname at len($locations) locations updated to $appversion (package version $packageversion)
Body: The application installed at the following locations was updated:Changelog:
...
I guess this is very low priority, and might be a bit tricky to accomplish easily, but I think it would be a very worthwhile addition to larger installs with many apps of the same type.
@robin I have seen this suggestion before but when I took a shot at time last time around it was quite complicated!
The main issue iirc was when the notification should be raised. The app updates happen in parallel (3 at a time). This means the update of each app will finish at various times. In additional, they may fail or not. They may also be updating to different versions. One idea is to have some "cron" task which raises notifications. It looks into the audit log or something but this means that the notifications will be delayed (or maybe if the task is frequent enough people won't notice). Another idea is to have a hook to raise a notification after all the app updates are completed. This is possible but tricky because have to coalesce all these update tasks which are run in parallel and have some some joining code. Maybe I missed some other simple approach.
-
@robin I have seen this suggestion before but when I took a shot at time last time around it was quite complicated!
The main issue iirc was when the notification should be raised. The app updates happen in parallel (3 at a time). This means the update of each app will finish at various times. In additional, they may fail or not. They may also be updating to different versions. One idea is to have some "cron" task which raises notifications. It looks into the audit log or something but this means that the notifications will be delayed (or maybe if the task is frequent enough people won't notice). Another idea is to have a hook to raise a notification after all the app updates are completed. This is possible but tricky because have to coalesce all these update tasks which are run in parallel and have some some joining code. Maybe I missed some other simple approach.
@girish Here's also an interesting bash helper function
https://notify17.net/use-cases/n17-helper-bash/In this case, could be tied to box code or externally to n8n.
/cc @BrutalBirdie -
@robin I have seen this suggestion before but when I took a shot at time last time around it was quite complicated!
The main issue iirc was when the notification should be raised. The app updates happen in parallel (3 at a time). This means the update of each app will finish at various times. In additional, they may fail or not. They may also be updating to different versions. One idea is to have some "cron" task which raises notifications. It looks into the audit log or something but this means that the notifications will be delayed (or maybe if the task is frequent enough people won't notice). Another idea is to have a hook to raise a notification after all the app updates are completed. This is possible but tricky because have to coalesce all these update tasks which are run in parallel and have some some joining code. Maybe I missed some other simple approach.
@girish Yeah, I can understand this would be complicated. And like I say, it's not super important, so feel free to just stick it on the backburner...
I don't know if you store additional metadata about notifications, so excuse me if I'm wildly idiotic, but I wonder if you could store a JSON object or something along with the notification's data, containing the following:
- that it's an update notification
- of a given app id
- to a given app version
- applied to a list of 'n' locations
like:
extra_data: { "type": "app_update", "app_id": "com.foo.Bar", "app_version":"1.0.0", "installed_locations":[...] }Then, you'd want to scan unread notifications for a matching:
- type (app_update)
- of the same app id/version
- and if it all matched, append to the locations, and regenerate the body based on the installed_locations & changelog, rather than submitting a new one.
Not straightforward, and not really a reusable solution, though...
-
@girish Yeah, I can understand this would be complicated. And like I say, it's not super important, so feel free to just stick it on the backburner...
I don't know if you store additional metadata about notifications, so excuse me if I'm wildly idiotic, but I wonder if you could store a JSON object or something along with the notification's data, containing the following:
- that it's an update notification
- of a given app id
- to a given app version
- applied to a list of 'n' locations
like:
extra_data: { "type": "app_update", "app_id": "com.foo.Bar", "app_version":"1.0.0", "installed_locations":[...] }Then, you'd want to scan unread notifications for a matching:
- type (app_update)
- of the same app id/version
- and if it all matched, append to the locations, and regenerate the body based on the installed_locations & changelog, rather than submitting a new one.
Not straightforward, and not really a reusable solution, though...
@robin while technically the docker image is shared of course between app instances of the same package, the update itself with data migration and such is quite isolated from one another. So I am not sure if it makes sense conceptually to combine those into one notification at all.
Also note that if you have various instances of the same app package installed, but one or more are set to manually update, you end up with the same app package but multiple versions of that happily alongside each other and I think that might make such combined notifications more confusing, since you would have to scan the locations then, and the locations are already currently in the notification title as such. Maybe those should be more highlighted instead, possibly even with the app icon (only adding value if you have set a custom app icon to distinguish instances)
-
@robin while technically the docker image is shared of course between app instances of the same package, the update itself with data migration and such is quite isolated from one another. So I am not sure if it makes sense conceptually to combine those into one notification at all.
Also note that if you have various instances of the same app package installed, but one or more are set to manually update, you end up with the same app package but multiple versions of that happily alongside each other and I think that might make such combined notifications more confusing, since you would have to scan the locations then, and the locations are already currently in the notification title as such. Maybe those should be more highlighted instead, possibly even with the app icon (only adding value if you have set a custom app icon to distinguish instances)
@nebulon Kind of depends on the app type, too, I guess? The one I really notice this stand out on is for LAMP. I have maybe 4-5 of these, all serving static sites. I don't really care when they update, but whenever they do, I get a bunch of notifications for them all at once.
I don't know. I guess I see your point, and maybe it's fine to just leave it be. Ultimately, I guess if you don't design for people to have too many things of the same type, it probably won't matter anyway.
