Do not allow dismissing of notifiations with actions

[rullzer]

If a notification has actions it should not be allowed to be dismissed.

See:

For now I would say we should remove the X because there are actions.

For future work we could consider having types of buttons. And if you have a 'reject' button then the X defaults to that?

CC: @nickvergessen

[nickvergessen]

Well, yes and no. Another solution would be to have a view which shows the things too, in this case a pending share view.

[nickvergessen]

Otherwise the delete all and so on get very complicates

[nickvergessen]

So if we were to follow the path you suggest, I would say:

• If there is 1 delete, that could be the fallback method for X
• Deleting should only be blocked, when there is a non WEB action (open in browser window, e.g. used by talk chat notifications).
• Question for what to with the "Delete all" is still open

[rullzer]

So something else that comes to mind.

• Have a 'dismiss noticiation' interface
• If a notifier implements this we call it with the notification on dismissing of the notification

Then apps can chose what to do themselves?

[nickvergessen]

Sounds good. But we also need to cover the deleteAll case. So in here https://github.com/nextcloud/notifications/blob/master/lib/Handler.php#L106 (adjust the select above to get all columns) create the object and call it on the NotificationManager

And in deleteById use getById before and send it to the NotificationManager: https://github.com/nextcloud/notifications/blob/master/lib/Handler.php#L144

[rullzer]

Basically done with https://github.com/nextcloud/server/pull/18297

[wiswedel]

Basically done with nextcloud/server#18297

Basically ≠ actually, I guess? At least incoming shares are still dismissable in 18.0.1 RC1

[rullzer]

Basically done with nextcloud/server#18297

Basically ≠ actually, I guess? At least incoming shares are still dismissable in 18.0.1 RC1

When you dismiss you rject.

[wiswedel]

When you dismiss you reject.

Not as of 18.0.1 RC2 at least:

The dismissed share does in fact not appear for the sharee, sure, but the share owner still sees the file as shared and assumes, the share went through. The entry remains as oc_share.accepted[0] in the databse forever.

[nickvergessen]

Which is the same as when you share something to a group and one of the user deletes it.

[rullzer]

Yes that is what rejecting is right now. Just saying no. There is currently no way to accept a share afterwards. This is still something that has to be done.

[wiswedel]

This is still something that has to be done.

So something for 18.0.2?

[rullzer]

No that requires major internal changes it is currently not even planned for 19. Right now the behavior is just the same as if you share a file and then remove it afterwards.