Merge lp:~wallyworld/launchpad/delete-bugtasks-1324 into lp:launchpad
Status: | Merged |
---|---|
Approved by: | Curtis Hovey |
Approved revision: | no longer in the source branch. |
Merged at revision: | 14176 |
Proposed branch: | lp:~wallyworld/launchpad/delete-bugtasks-1324 |
Merge into: | lp:launchpad |
Diff against target: |
486 lines (+275/-4) (has conflicts) 8 files modified
lib/canonical/launchpad/permissions.zcml (+3/-0) lib/lp/bugs/configure.zcml (+3/-0) lib/lp/bugs/interfaces/bugtask.py (+29/-1) lib/lp/bugs/model/bugtask.py (+23/-0) lib/lp/bugs/model/tests/test_bugtask.py (+157/-0) lib/lp/bugs/security.py (+51/-0) lib/lp/services/features/flags.py (+4/-0) lib/lp/services/features/rulesource.py (+5/-3) Text conflict in lib/lp/bugs/model/tests/test_bugtask.py |
To merge this branch: | bzr merge lp:~wallyworld/launchpad/delete-bugtasks-1324 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Curtis Hovey (community) | code | Approve | |
Данило Шеган (community) | Needs Fixing | ||
Review via email: mp+79541@code.launchpad.net |
Commit message
Add a bugtask delete method to the IBugTask API and also export to the web service.
Description of the change
Add a bugtask delete method to the IBugTask API and also export to the web service.
A followup branch will add an entry to the bug activity log when a task is deleted and an email will be sent to the bug supervisor of the pillar for which the task is deleted.
== Preimplementation ==
Talked with lifeless and wgrant. lifeless was concerned about deleting a bugtask if it were a conjoined master/slave. wgrant said this doesn't matter due to recent changes to allow such 'orphaned' bugtasks.
== Implementation ==
The delete implementation was done in a destroySelf method on BugTask. This fits with how other entities are deleted in Launchpad (even though my preference is for the lifecycle of entities to be managed by a service based interface rather than the entiy itself). In terms of security, a new Launchpad permission is introduced - "launchpad.Delete". I feel it is better more semantically correct to use this new permission rather than just piggyback onto the launchpad.Edit permission.
A security adaptor is provided to check the necessary role based permissions. A new interface is introduced to allow the security and permissions to be wired up that that everything works in both the server side and web service api - IBugTaskDelete.
There are also other business rules which stop a bugtask from being deleted eg the last bugtask cannot be deleted. These rules are checked in the canBeDeleted() method and a CannotDeleteBugtask exception is raised in such cases.
A feature flag is used to hide this operation - 'disclosure.
== Demo and QA ==
An example script to invoke the api using launchpadlib:
from launchpadlib.
def test_delete_
lp = Launchpad.
'testing', service_
bug = lp.bugs[bug_num]
bugtasks = bug.bug_tasks
if len(bugtasks) == 1:
print "This bug has no extra bugtasks to be deleted."
else:
for bugtask in bugtasks:
if bugtask.target.name == pillar_name:
== Tests ==
Add a new testcase TestBugTaskDeletion with some tests:
test_cannot_
test_unauthoris
test_pillar_
test_bug_
test_task_
test_cannot_
test_delete_bugtask
test_delete_
test_bug_
Add a testcase for the web service interface: TestWebService
== Lint ==
Checking for conflicts and issues in changed files.
Linting changed files:
lib/canonical
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
lib/lp/
Looks pretty good: very nice to see this happening.
I do have a few observations/ questions that I'd like addressed first.
If concerns were raised about conjoined bug tasks, I suppose it would be nice to have a test for that, though I believe nothing would really be affected (a slave would lose a master and vice versa, but that's about it).
Next, I wonder if there was a good reason not to use launchpad.Admin privilege instead? I.e. the way you implement Delete for BugTask seems limited to checking permissions on the context. Real admins (like LOSAs) will not be able to delete bug tasks, if I am reading it correctly.
I also don't feel like checking for feature flags belongs in the permissions code: you don't have a permission because feature is not enabled? Just sounds wrong to me, no big deal otherwise. Tied to that, perhaps tests should ensure UnauthorizedError is raised when delete is attempted instead of using check_permission as well?
Also, I'd prefer if tests which contain logic for when both feature flag is on and off are split into two separate tests each.
Also, is adding a store.flush() really necessary to the rulesource.py? If you need it for tests, maybe it's not necessary for production (and would introduce a query or two that we could avoid, if updates to a single object happen before and after flags are modified). Not a big deal though.
Thanks for the lint fixes :)