Opened at 2007-08-13T22:41:13Z
Closed at 2007-08-14T00:51:30Z
#101 closed defect (fixed)
web page usability: after POST, redirect to somewhere useful
Reported by: | warner | Owned by: | warner |
---|---|---|---|
Priority: | major | Milestone: | 0.5.0 |
Component: | code | Version: | 0.4.0 |
Keywords: | web | Cc: | |
Launchpad Bug: |
Description
The human-oriented web interfaces (specifically the POST t=mkdir and t=upload forms) should leave the user's browser on a useful page. This desired behavior is different from what a programmatic client (using PUT or DELETE) ought to get.
Something regressed recently. On 0.4.0-145 (as running on our testnet), when you use the "Create a new directory" button, you are brought back to the original page (and get to notice the new directory line appear in the list). When you use the "Upload a file" button, you are also brought back to the original page (and get to notice the new file line in the list).
In 0.4.0-229 (current trunk), both operations dump you on a page that contains the URI of the newly created object, which is all-but-useless for a human.
I think this needs to be fixed back to its earlier behavior. The "Create new directory" button should perhaps drop you on the newly-created directory.. I'm not sure which behavior would be more useful.
Change History (1)
comment:1 Changed at 2007-08-14T00:51:30Z by warner
- Resolution set to fixed
- Status changed from new to closed
Fixed, in 31bfb3950a12a65a: this broke when I fixed the memory footprint problems in 3bc708529f6a64cb because the when_done= argument that was meant to get us to the right place shows up in a POST field rather than as a query argument (this is just how we happened to construct those forms.. with some hackery we could have stuffed them in the action= URL instead). 3bc708529f6a64cb means that fields no longer show up in request.args, so we weren't noticing the when_done value and thus were not doing the intended redirect.