Merge lp:~intellectronica/launchpad/bug-531963 into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Eleanor Berger on 2010-03-23 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | not available |
| Proposed branch: | lp:~intellectronica/launchpad/bug-531963 |
| Merge into: | lp:launchpad |
| Diff against target: |
193 lines (+148/-3) 3 files modified
lib/canonical/launchpad/javascript/bugs/bugtask-index.js (+78/-3) lib/lp/bugs/browser/bugtask.py (+1/-0) lib/lp/bugs/windmill/tests/test_bug_status.py (+69/-0) |
| To merge this branch: | bzr merge lp:~intellectronica/launchpad/bug-531963 |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Nelson (community) | ui | 2010-03-22 | Approve on 2010-03-22 |
| Abel Deuring (community) | code | 2010-03-18 | Approve on 2010-03-19 |
|
Review via email:
|
|||
Commit Message
When changing bug status, require confirmation from users who are not in the project team.
Description of the Change
This branch adds a confirmation step when a user who has no privileges in a project tries to edit the bug status. It does that by creating a specialised version of the ChoiceEdit widget that displays a javascript confirm dialog before saving if a new parameter is set. The only gotcha here is the use of confirmAnswer in the windmill test. This is how we simulate confirming (or cancelling). Windmill overrides all calls to modal dialogs in order to avoid blocking execution and uses the value in confirmAnswer instead. This value can't be set from python directly, so we use execJS to inject into the JS environment.
| Eleanor Berger (intellectronica) wrote : | # |
Michael, thanks for taking on this UI review. You can see a screenshot at http://
| Michael Nelson (michael.nelson) wrote : | # |
> Michael, thanks for taking on this UI review. You can see a screenshot at
> http://
> if you want to test it yourself on launchpad.dev, go to a bug logged in a no-
> priv and try to change a status. This is a pretty simple implementation. I
> would have liked to do this using a LAZR widget, but the work for implementing
> this is too much, and this should solve the immediate problem and only happen
> infrequently.
Hi Tom,
I agree that it would have been nice to use a LAZR widget, but understand that it's not within scope right now. I do however think it's still worth hiding the choice list before bringing up the confirmation dialog, and don't see why you say you'd need to update the widget to do so. Here's a (crude) diff that gives the behaviour that I mentioned:
http://
Other than that, I just mentioned in our conversation the addition of "whether" to the sentence (check with mrevell if you want a second opinion).
Thanks!
IRC conversation:
13:01 < noodles775> intellectronica: why is it that if I'm logged in as cprov (<email address hidden>:cprov) I'm unable to modify the bug status (the mouse-over tells me "Changeable only by a project maintainer or a bug supervisor"), yet I can as no-privs? Is no-privs a bug supervisor without privs in the project?
[snip]
13:07 < intellectronica> noodles775: that's because that bug is assigned to a bugwatch
13:07 < noodles775> Ah ok. Thanks. Two more things:
13:08 < noodles775> First, I think the wording might be missing "whether"? eg. "If you're not certain whether changing the status of this bug is correct,..." What you you think?
13:09 < noodles775> And second, how difficult would it be to first close the overlay before popping up the confirmation?
13:09 < intellectronica> noodles775: as a non-native speaker i'll have to trust you on that. both some equally good to me
13:09 < noodles775> I think that's quite important (a popup within a popup is really bad).
13:09 < intellectronica> noodles775: very difficult
13:09 < noodles775> :(
13:09 < noodles775> intellectronica: couldn't in just be hidden with CSS when you bring up the confirmation?
13:10 < noodles775> (ie. you shouldn't need to change the behaviour of the widget?)
13:10 < intellectronica> that would be a great solution, and even better one would be to handle it within the widget itself. unfortunately both require a complete restructuring of that widget which we can't afford right now
13:11 < intellectronica> noodles775: the problem is the way the widget interacts with the web service. it saves before closing, and changing that would require changing the widget, and quite possibly changing other widgets that use the api patch plugin

Hi Tom,
the code is fine, but "make lint" has a few complaints. Could you fix them?