Since this is an irrevocable action, an interstitial page making sure the user has carefully considered the project shortname before saving seems in order.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1040044-11.promote-confirm-fix-session.patch | 1.91 KB | dww |
| #9 | promote-shortname.patch | 2.05 KB | sdboyer |
| #6 | 1040044-6.promote-confirm.patch | 7.11 KB | dww |
| #6 | 1040044-6.promote-confirm.png | 31.74 KB | dww |
| #5 | 1040044-5.promote-confirm.patch | 7.06 KB | dww |
Comments
Comment #1
dwwYeah, mikey_p and I had discussed this. Probably worth doing, although I wouldn't mind getting some UX input on this before going much further...
Comment #2
eliza411 commentedTo get this in prior to deployment we have about 2 weeks. To get it tested thoroughly and documented, about 5 days. Hopefully we can get the feedback quickly as it would be a mistake to launch without out, I think, but not technically a blocker.
Comment #3
mikey_p commentedSounds like a good use case for confirm_form().
Comment #4
dwwFrom IRC:
Actively working on this now, stay tuned...
Comment #5
dwwLater in IRC:
I was wrong, it kind of is a pain in the ass to add the confirm form. ;) You have to persist the values from the promote form into the $_SESSION so they can be used when building the confirm form at a new menu callback. It gets even weirder since project_release is altering the confirm form. But, it's all working now. And in a way it's good I went through the trouble to do project_release properly since that'll serve as an example if any other modules need to alter the promote form and deal with the confirm form.
So here's the working patch and some screenshots of the workflow. You'll notice that in the first instance, there's no 'Releases' subtab under edit at all (since it's a sandbox with releases disabled) but in the 'done' screenshot after confirming the promotion, the download section appears on the project page. If I clicked on edit you'd see a subtab for releases, etc.
Comment #6
dwwBased on IRC feedback from eliza411, here's a new version of the confirm form itself that stuffs the shortname into the page title, too. Other screenshots are unchanged...
Comment #7
eliza411 commentedI didn't review the patch, but I think this text is ready for us to use in testing.
Comment #8
dwwCommitted to HEAD: http://drupal.org/cvs?commit=491882
Comment #9
sdboyer commentedUsing $_SESSION directly only appears to work, but $project->project['uri'] never gets updated in the db. When the form builder makes the second pass through the form and on submit, the session var has already been unset which means we revert back to the numerical uri. Yuck.
Attached patch gets rid of the $_SESSION approach and instead just passes it as as part of the url. Tested & verified that it works.
Comment #10
dwwNo, that won't work when other people are extending this form, e.g. project_release. The funny thing is that project_release gets SESSION right. I just forgot to fix the shortname once I debugged project_release. ;) Stay tuned.
-Derek
Comment #11
sdboyer commentedLike I said, it does work - I've verified that the shortname gets saved properly. I may have missed something in project_release, I wasn't checking there. If you have another way of solving this that gets the shortname saved properly, though, then by all means...
Comment #12
dwwCommitted this to HEAD. Verified the shortname was updated. ;) Sorry about that.
Comment #13
dww@sdboyer: x-post. I'm sure your patch worked for the shortname. I meant that trying to stuff everything into the URL is an unsustainable approach to this problem, which we already see in project_release. So project itself should just use SESSION properly so everyone knows how to do this if they need to extend the promote form.
Comment #14
sdboyer commentedFair nuff, works for me. Let's hope it works clean after rebuild.