Merge lp:~adeuring/launchpad/bug-39674-lfa-editable into lp:launchpad/db-devel
| Status: | Merged |
|---|---|
| Approved by: | Gary Poster on 2010-07-06 |
| 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) | 2010-07-06 | Approve on 2010-07-06 | |
|
Review via email:
|
|||
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
| Robert Collins (lifeless) wrote : | # |
A few notes - this is a great branch.
The spike I'm doing on restricted librarian things will likely
eventually benefit from the adapter.
It would be great to do a quick check that we don't share LFA's
anywhere; there isn't any need to share them because they themselves
are the sharing mechanism for content in the librarian.
-Rob
| Abel Deuring (adeuring) wrote : | # |
On 28.07.2010 02:01, Robert Collins wrote:
> A few notes - this is a great branch.
>
> The spike I'm doing on restricted librarian things will likely
> eventually benefit from the adapter.
>
> It would be great to do a quick check that we don't share LFA's
> anywhere; there isn't any need to share them because they themselves
> are the sharing mechanism for content in the librarian.
I already did a quick check and I think that LFAs referenced by bug
attachments are not referenced elsewhere. But:
1. There is an obvious difference betwen "I think" and "I am absolutely
sure"
2. Even if we were absolutely sure that we don't create such references
today, some code that creates a second reference to a bug attachment's
LFA this could in the future accidentally slip into our code base.
It would be nice if we could enforce this by a constraint on all columns
which reference LFAs, but according to
file://
> Currently, CHECK expressions cannot contain subqueries nor refer to variables other than columns of the current row.
We could perhaps add triggers for INSERTs and UPDATEs of all tables that
reference LFA which ensures that something like
SELECT lfa_reference FROM table1 WHERE lfa_reference=
UNION ALL
SELECT lfa_reference FROM table2 WHERE lfa_reference=
UNION ALL...
returns exactly one row.

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.