Merge lp:~adeuring/launchpad/bug-39674-lfa-editable into lp:launchpad/db-devel
Status: | Merged |
---|---|
Approved by: | Gary Poster |
Approved revision: | no longer in the source branch. |
Merged at revision: | 9578 |
Proposed branch: | lp:~adeuring/launchpad/bug-39674-lfa-editable |
Merge into: | lp:launchpad/db-devel |
Diff against target: |
256 lines (+122/-4) 8 files modified
configs/development/launchpad-lazr.conf (+2/-0) daemons/librarian.tac (+4/-0) lib/canonical/config/schema-lazr.conf (+7/-0) lib/canonical/launchpad/database/librarian.py (+18/-4) lib/canonical/launchpad/interfaces/librarian.py (+5/-0) lib/canonical/launchpad/security.py (+22/-0) lib/canonical/launchpad/tests/test_libraryfilealias_with_parent.py (+53/-0) lib/canonical/launchpad/zcml/librarian.zcml (+11/-0) |
To merge this branch: | bzr merge lp:~adeuring/launchpad/bug-39674-lfa-editable |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Gary Poster (community) | Approve | ||
Review via email: mp+29314@code.launchpad.net |
Description of the change
This branch makes LibraryFileAlias records editable.
Up to now, all attributes of LibraryFileAlias were read-only. This is reasonable, because we LFAs are used for a number of different purposes, from icons for projects and users to PPAs and bug attachments. So there is nothing like a common "permission conecpt" for LFAs.
On the other hand, in bug 39674 Francis suggests that we should make the property "restricted" of LFAs changable. (This reduces the load for our Zope servers, because the content of bug attachments of public bugs will still be served via the public Librarian, while we can serve the attachment content of private bugs via the restircted Librarian.
The restricted Librarian already "copied" the permission launchpad.View of a parent object of a Librarian file, so it was straightforward too extend this concept to edit permissions for LFA records.
This branch adds an adapter for LFAs that allows to edit a Librarian file if a parent is known; users who can edit the parent's properties can also change the LFA record. (At present, the only settable attribute is "restricted", but it would be simple and useful to make other attributes also editable so that it for example becomes easier to change the content type of a bug attachment -- at present, we create a new LFA record with the same content but a changed content type field...)
test: ./bin/test -vvt test_libraryfil
no lint
Looks good, thank you!
What do you think of this instead of the try/except blocks on the test?
self. assertRaises( setattr( self.bug_ attachment. title, 'whatever'), Unauthorized) assertRaises( self.lfa_ with_parent. restricted, True), Unauthorized)
self.
It's worth noting some of the other ideas we discussed and rejected in the course of the branch.
- Set a __parent__ on the library object in the database. The problems are that library objects may have multiple parents in theory; and, more importantly, they may have multiple *types* of parents, and making a reference to an arbitrary object is not trivial in Launchpad at the moment given our table structures. This would be my preferred solution in the long run.
- Set a __parent__ on the object during traversal. The mechanism implemented here could be used for that, but would be more heavyweight than would be needed--you could just slam a transient __parent__ on the file alias instance. Problems: we didn't care for this pattern because it had hidden fragility. The current approach clearly exposes the situation for what it is. This alternative is the one that I wonder if it would have been better, but I'm happy with the call that we made.
- Make a method on the file alias to change the restricted attribute that takes a security context and then handles security checks itself. I wanted to keep security handled by the usual machinery, and I wanted to keep security concerns out of the model code.
- Use another sort of mediator, like a function. I wanted to keep security handled by the usual machinery. Using the approach we have here keeps us in the usual patterns.