close fullscreen

Ticket

+status
closed
help edit space_dashboard
+priority
medium
help edit space_dashboard
+tag
accounts
following
Design
Wagn 1.14
help edit space_dashboard
+commit
 

+issues

help edit space_dashboard

The pressing issue here is that URLs like http://wagn.org/card/unwatch/Ticket (in the notification email) don't work if you're not signed in. They prompt you to sign in, but then you're at the home page and there's no clear way to unwatch or even get to the Ticket card.

 

There are two main cases where we want to return to a previous address:

  1. Action Interrupted.  This is the case that this ticket is originally about.  You're trying to unwatch a card but must sign in to do so.  Could also happen with a create url, a delete, ... maybe others? Once signed in, Wagn should remember the action that got interrupted (eg unwatch) and continue on that path.  Note - thus far signin is the only interruption like this.
  2. Ambiguous Next Step.  There are several cases like this, where a user decides to take an action and, once completed, we must decide where to go.  We're currently using our stack (and @previous_location) to make this choice for us.  This comes up when:
    • cancelling a card creation or an invitation
    • hitting "forgot password"
    • deleting a card

My point in spelling all of this out is that the "history stack" will not solve both problems.  For the "next step" (#2) cases, we almost never want to go back to performing some action on a card that was previously in progress.  And for the interrupted actions (#1), we don't really want a queue - we just want to go back to that action.  No need to keep a stack.

 

But currently, we don't have any great way of handling "action interrupted".

 

+solution

help edit space_dashboard

I think in the action interrupted case, the best idea is to pass the interrupted action url through the signin process via cgi variables. (note, it could also be desirable to be able to preserve this action through signup and/or forgot password, but my inclination would not be to start there).

 

Perhaps we could even make all of this possible via AJAX, so that if I were to try to edit something in place for which I did not have permissions, I'd get sign-in options right there and then be able to continue in place.

 

 

help edit space_dashboard

also see retain GET query when signing in

--John Abbe.....2013-05-06 03:16:07 +0000

I would say that one is a subset of this one.

 

AJAX is probably the best solution to this, but maybe it needs several approaches. If the action is reloading the browser page, it probably works a bit better to let the server handle it, since the server knows how/why it got interrupted, but if the action is going to be processed in AJAX ways, it will be hard to get back without AJAX help. I think the tricky part will be that it needs to do the sign-in/signup, etc. within a frame or slot, and I don't think sign-in/signup works that way now.

--Gerry Gleason.....2013-06-08 22:25:36 +0000

I would say AJAX is a secondary concern. First is getting the representation and the simple cases right.

--Ethan McCutchen.....2013-06-10 05:13:02 +0000

in other words, I don't think an ajax-only solution makes sense, but it would be cool if the ajax and non-ajax behaviors were pretty close to the same.

--Ethan McCutchen.....2013-06-10 15:55:17 +0000

I implemented a simple solution: when an action is interrupted by a sign-in I save the uri in the session and return to that uri after the sign-in

--Philipp Kuehl.....2014-10-09 11:42:36 +0000

is there a PR for this?

--Ethan McCutchen.....2014-10-09 17:05:01 +0000

 

+discussed in support tickets

help edit space_dashboard