launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #03092
Re: Exposing newCodeImport
On 29/03/10 09:58, James Westby wrote:
On Mon, 29 Mar 2010 08:05:30 +1300, Michael Hudson<michael.hudson@xxxxxxxxxxxxx> wrote:
I've got it to the stage where I have IBranchTarget.newCodeImport() and
I want to expose this method over the API. I have two questions about
how to do that though.
However, I can't simply expose it, as it isn't on the actual branch
targets. I'd like to know what the best way to do this is.
IBranchTarget has several implementations, one for each of product,
sourcepackage, person, and productseries. I want the method to be only
available on the first two if possible, but it's fine if it has to be
all four, as it is part of the interface after all.
I can add newCodeImport methods to IProduct and ISourcePackage that just
do
def newCodeImport(...):
return IBranchTarget(self).newCodeImport(...)
but that seems like unnecessary duplication.
Is there some way that I can tell lazr.restful to consider IBranchTarget
when looking at what to export on IProduct etc?
I *think* but without checking the code or really knowing for sure that
you have to make IProduct inherit from IBranchTarget to do this. But
IIRC products are not IBranchTargets, they are adaptable to
IBranchTargets, and I don't think adaptation is (or really could be) a
concept that translates into the API.
Right, so it sounds like I still need a small interface and mixin to do
the adaptation and call newCodeImport on the result?
Um. Yes, I think so.
Does anyone know of a similar situation elsewhere that I can look at for
inspiration?
The second issue is with the "registrant" argument to
newCodeImport. This eventually becomes the owner of the created branch.
For my use case I want to specify this, as I don't want my user to own
all the branches. However, for API simplicity it shouldn't be required.
If I use @call_with(registrant=REQUEST_USER) will that prevent it from
being specified by the caller?
Is the correct solution to use @call_with() as above, but allow and
optional owner parameter that defaults to registrant?
That would solve the issue, and also prevent the registrant of the code
import being recorded as a team, so it sounds like the best solution.
Yes, that all sounds sane.
Good, thinking about it further over the weekend it sounds like
registrant=REQUEST_USER and owner=None is the right approach.
Yeah.
In addition, I presume I need to add in access control, so that I can't
create a code import owned by any user, only teams that I am part of. Is
there an idiom for that?
I'm pretty sure you can describe a parameter to a named operation as a
schema field, so in this case you'd set it to be a ReferenceChoice for
the appropriate vocabulary -- can't remember what it's called, but it
certainly exists, the Branch +edit page uses it.
There would be a vocabulary for "IPersons that registrant is a member
of?"
No, but there's a vocabulary for "IPersons that the logged in user is a
member of" -- UserTeamsParticipationPlusSelfVocabulary -- and that's the
same thing here.
I was assuming I would need to add some sort of manual check?
Not really.
For these things is checking membership the right thing, or is there
some sort of permission check so that e.g. admins can set anyone
as the owner?
I thought the vocabulary did this, but it seems that it's not, it's done
in the +edit form setup code (I guess because the widgets are different
depending on whether the user is an admin or not).
So maybe you'll need to do something different here, or at least change
the details of how things are done now.
Hope this was helpful, please don't be *too* surprised if its a bit
inaccurate in places.
No problem. Thanks for the feedback.
Thanks for working on this!
Cheers,
mwh
Follow ups
References
