[GH-ISSUE #380] Orderable user action buttons #292

Closed
opened 2026-05-07 00:22:41 +02:00 by BreizhHardware · 9 comments

Originally created by @dcousens on GitHub (Aug 14, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/380

The typical preference of action buttons on Android notifications at the moment is, with an attachment.url, the following:

  • Open
  • Browse
  • {User Actions}
  • ...

Where Open and Browse are provided by the ntfy-android application using internal semantics.
The semantics are defined at github.com/binwiederhier/ntfy-android@60f90667d9/app/src/main/java/io/heckel/ntfy/msg/NotificationService.kt (L76-L83) , and for the example above, assumes the download worker didn't fail or wasn't in progress.

Unfortunately, if you have N>1 user actions, you may end up with only the first user action being usable (unless you open the application), with the others being dropped by your device's notification action bar. For me at least, 3 is the limit for my device.

Proposal

I propose that user actions should be have an order priority that we can use to place them before or after the Open and Browse actions. If we used the following values:

Action Default Order Index
Open 1
Browse 2
Download 3
Cancel 4

We could provide an action.order = 0 to put user actions before Open, or action.order = 1 to place them before Browse.
We could provide an action.order = 5 to put them at the end of the list. 5 (or 99) could be the default, so as to not change the current behaviour.

Alternative proposal

If this is unwanted complexity, we could instead change the order of user actions being added to the following:

  • {User Actions}
  • Open
  • Browse
  • ...

If you are interested in this @binwiederhier but only open to a pull request (not implementing it yourself), I am happy to try and take this on.

Originally created by @dcousens on GitHub (Aug 14, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/380 The typical preference of action buttons on Android notifications at the moment is, with an `attachment.url`, the following: - Open - Browse - `{User Actions}` - ... Where `Open` and `Browse` are provided by the `ntfy-android` application using internal semantics. The semantics are defined at https://github.com/binwiederhier/ntfy-android/blob/60f90667d9d252487de21d481507647fb368349d/app/src/main/java/io/heckel/ntfy/msg/NotificationService.kt#L76-L83 , and for the example above, assumes the download worker didn't fail or wasn't in progress. Unfortunately, if you have `N>1` user actions, you may end up with **only the first user action being usable** (unless you open the application), with the others being dropped by your device's notification action bar. For me at least, 3 is the limit for my device. # Proposal I propose that user actions should be have an order priority that we can use to place them before or after the `Open` and `Browse` actions. If we used the following values: | Action | Default Order Index | | -------- | -------- | | Open | 1 | | Browse | 2 | | Download | 3 | | Cancel | 4 | We could provide an `action.order = 0` to put user actions before `Open`, or `action.order = 1` to place them before `Browse`. We could provide an `action.order = 5` to put them at the end of the list. `5` (or `99`) could be the default, so as to not change the current behaviour. # Alternative proposal If this is unwanted complexity, we could instead change the order of user actions being added to the following: - `{User Actions}` - Open - Browse - ... --- If you are interested in this @binwiederhier but only open to a pull request (not implementing it yourself), I am happy to try and take this on.
Author
Owner

@binwiederhier commented on GitHub (Aug 18, 2022):

This obviously only applies to notifications with an attachment AND >1 user actions, because the Android limit for buttons is 3 (as you mentioned above).

I am conflicted: That seems to be a real edge case, since you could just push another message; but I do get that it takes away from the infinite flexibility of designing your notifications the way you want.

Paging @wunter8 for thoughts/input.

<!-- gh-comment-id:1219677741 --> @binwiederhier commented on GitHub (Aug 18, 2022): This obviously only applies to notifications with an attachment AND >1 user actions, because the Android limit for buttons is 3 (as you mentioned above). I am conflicted: That seems to be a real edge case, since you could just push another message; but I do get that it takes away from the infinite flexibility of designing your notifications the way you want. Paging @wunter8 for thoughts/input.
Author
Owner

@wunter8 commented on GitHub (Aug 19, 2022):

Doing the second option, of just having the user actions first, would be pretty easy to implement. Easy enough that I'd say, "Sure, why not?" But do we make it the new default or just a configurable option?

Having custom button ordering per notification would be a much more significant code change, so I'd be less tempted to do that, at least right now

<!-- gh-comment-id:1220209048 --> @wunter8 commented on GitHub (Aug 19, 2022): Doing the second option, of just having the user actions first, would be pretty easy to implement. Easy enough that I'd say, "Sure, why not?" But do we make it the new default or just a configurable option? Having custom button ordering per notification would be a much more significant code change, so I'd be less tempted to do that, at least right now
Author
Owner

@binwiederhier commented on GitHub (Aug 19, 2022):

just having the user actions first
Arguably user defined actions are more important. It feels a little weird, but I think I'd be okay with that.

But do we make it the new default or just a configurable option?

No. It's not important enough for that.

Having custom button ordering per notification would be a much more significant code change, so I'd be less tempted to do that, at least right now

Agreed.

<!-- gh-comment-id:1220734995 --> @binwiederhier commented on GitHub (Aug 19, 2022): > just having the user actions first Arguably user defined actions are more important. It feels a little weird, but I think I'd be okay with that. > But do we make it the new default or just a configurable option? No. It's not important enough for that. > Having custom button ordering per notification would be a much more significant code change, so I'd be less tempted to do that, at least right now Agreed.
Author
Owner

@wunter8 commented on GitHub (Aug 19, 2022):

No. It's not important enough for that.

I presume you mean it's not important enough for a configurable option, so I'll just plan on making it the new default. I just hope it doesn't negatively affect anyone that's used to the way it is right now

<!-- gh-comment-id:1220739829 --> @wunter8 commented on GitHub (Aug 19, 2022): > No. It's not important enough for that. I presume you mean it's not important enough for a configurable option, so I'll just plan on making it the new default. I just hope it doesn't negatively affect anyone that's used to the way it is right now
Author
Owner

@binwiederhier commented on GitHub (Aug 19, 2022):

I just hope it doesn't negatively affect anyone that's used to the way it is right now

We shall see :-)

<!-- gh-comment-id:1220741143 --> @binwiederhier commented on GitHub (Aug 19, 2022): > I just hope it doesn't negatively affect anyone that's used to the way it is right now We shall see :-)
Author
Owner

@binwiederhier commented on GitHub (Nov 19, 2022):

I'm going through tickets right now, and honestly I don't think this is of any/high value to most users. I've never heard anyone complain about the way that action buttons work or are ordered.

So I'm closing this for now. Feel free to comment and we can discuss further.

<!-- gh-comment-id:1320965178 --> @binwiederhier commented on GitHub (Nov 19, 2022): I'm going through tickets right now, and honestly I don't think this is of any/high value to most users. I've never heard anyone complain about the way that action buttons work or are ordered. So I'm closing this for now. Feel free to comment and we can discuss further.
Author
Owner

@dcousens commented on GitHub (Dec 20, 2022):

Unfortunate, but I understand that I appear to be the only signal 📶 for the feature.

<!-- gh-comment-id:1359319472 --> @dcousens commented on GitHub (Dec 20, 2022): Unfortunate, but I understand that I appear to be the only signal :signal_strength: for the feature.
Author
Owner

@computer-geek64 commented on GitHub (May 20, 2023):

I noticed this issue on Android as well, and I would definitely like to see a fix for this if possible. While I agree this seems like an edge case, I don't think having multiple actions and an image in a notification is too unrealistic.
I'd also like to add that instead of developing a mechanism for ordering, a simpler idea might be to simply add additional arguments for the "attach" parameter to enable or disable the default actions of open and browse.

<!-- gh-comment-id:1555928410 --> @computer-geek64 commented on GitHub (May 20, 2023): I noticed this issue on Android as well, and I would definitely like to see a fix for this if possible. While I agree this seems like an edge case, I don't think having multiple actions and an image in a notification is too unrealistic. I'd also like to add that instead of developing a mechanism for ordering, a simpler idea might be to simply add additional arguments for the "attach" parameter to enable or disable the default actions of open and browse.
Author
Owner

@mjmccans commented on GitHub (May 30, 2024):

I too would appreciate this feature, and the suggestion offered by @computer-geek64 above would work for my use case. Another solution would be to have an option when you are setting a user action, perhaps named something like "prefix" or "before", that defaults to "false" but if set to "true" would put the user defined actions before the default actions. That being said, I personally think @computer-geek64's suggestion is better because you will end up with cleaner notifications if you have only one or two user defined actions.

In case it is helpful, I can briefly describe my use case because I don't think it is that odd or unique. I want to receive a notification when my doorbell camera detects a person. The notification has a thumbnail of the activity attached, and I want to also have three actions: (1) view the associated snapshot image, (2) view the associated video clip, and (3) view the live stream from the camera. For my use case the "Open" and "Browse" actions are not useful, and stop me from being able to have the other actions that I need. An ability to turn off the default actions would be fantastic.

Either way, ntfy is fantastic and that you very much for all of the hard work you have put into it.

<!-- gh-comment-id:2140450253 --> @mjmccans commented on GitHub (May 30, 2024): I too would appreciate this feature, and the suggestion offered by @computer-geek64 above would work for my use case. Another solution would be to have an option when you are setting a user action, perhaps named something like "prefix" or "before", that defaults to "false" but if set to "true" would put the user defined actions before the default actions. That being said, I personally think @computer-geek64's suggestion is better because you will end up with cleaner notifications if you have only one or two user defined actions. In case it is helpful, I can briefly describe my use case because I don't think it is that odd or unique. I want to receive a notification when my doorbell camera detects a person. The notification has a thumbnail of the activity attached, and I want to also have three actions: (1) view the associated snapshot image, (2) view the associated video clip, and (3) view the live stream from the camera. For my use case the "Open" and "Browse" actions are not useful, and stop me from being able to have the other actions that I need. An ability to turn off the default actions would be fantastic. Either way, ntfy is fantastic and that you very much for all of the hard work you have put into it.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ntfy#292
No description provided.