launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

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? 

> > 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.

> > 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?"

I was assuming I would need to add some sort of manual check?

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?

> Hope this was helpful, please don't be *too* surprised if its a bit 
> inaccurate in places.

No problem. Thanks for the feedback.


James