Support for redirect actions

[PVince81]

Have the ability to specify a URL for action buttons.

I believe there is already a URL there so maybe just a flag to tell the handler that the URL is not ajax but really a page that needs to be opened.

Then adjust the JS notification handler to work as such.

Would also need adjusting in clients.
We could also embed those in emails.

@jvillafanez @michaelstingl thoughts ?

[michaelstingl]

@PVince81 context? (maybe ping me for ☕️ the next days…)

[PVince81]

Context is here owncloud/password_policy#18 but I can explain it to you.

In general notifications can have action buttons. So far the design said they are "ajax" actions, basically some curl request to send to a URL with a given method. They were not designed to open the URL in the browser, just do ajax/XHR.

The proposed enhancement is to also add a flag/mechanism to use the action buttons as a "open in browser" action. This would make it possible to have more than a single link.
Also from the UX perspective, seeing a button would encourage action, even if the button would link to the same link as the notification.

[PVince81]

@ogoffart please have a look. I heard desktop clients already display the buttons, so if we add this feature the clients would need adjusting as well.

I'm not sure yet about how to represent it in the action JSON. To be discussed.

[ogoffart]

If you just change the meaning of the "link" property, this will break the current client (the client would just do a request to that url, but not open a browser).
If you leave the link property empty, that would make current client to have an useless button. If you change the "type" of the link to anything but GET PUT POST or DELETE, the button would also have no effect.

There could be an "actions2" list in which actions could have a type which is "REDIRECT" or something like that which would mean to open the browser.

Note that this would by default not be autenticated. If we want to authenticate, we'd need to interoperate with something like discussed in owncloud/client#633

[PVince81]

Another idea is to have the result of the URL request to be a 302 redirect. The drawback is that you cannot distinguish between a legit redirect from the web server (due to env) from one returned by OC. That is unless we use a custom header like "Content-Location".

[PVince81]

@jvillafanez let's spend 0.5md to examine the different proposals and let them be reviewed by the client teams.

[ogoffart]

I don't particularly like the idea of a 302 redirect that would mean opening the browser instead. First, that would still not work with older sync client.
And it looks like a hack since this is not really what HTTP redirect is supposed to mean.

[PVince81]

We need a solution that:

• doesn't break on older clients or at least doesn't make it worse than now
• can be implemented in future client versions

[ogoffart]

From one of my previous comments:

There could be an "actions2" list in which actions could have a type which is "REDIRECT" or something like that which would mean to open the browser.

This would fit both criteria: old client would ignore the actions2 list. And new client can make it work. (I'm talking about the desktop client. I don't know about mobiles ones)

The old items in the old action could contains a hidden='true' action which would mean that the new client don't show this old action, in case we still want to show an action that does something only on the old clients.