Merge into devel : additional-affiliation-types : Code : Launchpad itself

Status:

Superseded

Proposed branch:

lp://staging/~wallyworld/launchpad/additional-affiliation-types

Merge into:

lp://staging/launchpad

Prerequisite:

lp://staging/~wallyworld/launchpad/improve-personpicker-bugtaskaffiliation-798764

Diff against target:

1271 lines (+478/-558)

8 files modified

lib/lp/app/browser/tests/test_vocabulary.py (+0/-269)
lib/lp/app/browser/vocabulary.py (+0/-13)
lib/lp/app/javascript/picker/picker.js (+0/-72)
lib/lp/app/javascript/picker/tests/test_picker.js (+1/-80)
lib/lp/registry/configure.zcml (+21/-3)
lib/lp/registry/model/pillaraffiliation.py (+104/-56)
lib/lp/registry/tests/test_pillaraffiliation.py (+344/-62)
lib/lp/testing/factory.py (+8/-3)

To merge this branch:

bzr merge lp://staging/~wallyworld/launchpad/additional-affiliation-types

Related bugs:

Bug #820210: Add IHasAffiliation adaptor for Questions	High	Fix Released
Bug #820212: Add IHasAffiliation adaptor for Blueprints	High	Fix Released
Bug #820213: Add IHasAffiliation adaptor for Distributions	High	Fix Released

Link a bug report

Reviewer	Review Type	Date Requested	Status
Curtis Hovey (community)	code	2011-08-04	Needs Information on 2011-08-04
Review via email: mp+70442@code.staging.launchpad.net

This proposal has been superseded by a proposal from 2011-08-05.

Commit message

Add to the affiliation adaptor to provide affiliation for other entity types like Question, DistroSeries, ProductSeries, Specification

Description of the change

This branch adds to the affiliation adaptor to provide affiliation for other entity types:
- Specification
- Question
- Distribution
- DistroSeries
- ProductSeries
- Product

== Implementation ==

Add extra affiliation adaptors for the additional context types. Checks are done for:
owner
driver
security contact
bug supervisor

Some contexts have pillars eg BugTask has a product or distribution; a distroseries has a distribution. The context is checked first. If the context doesn't match on the given attribute (eg owner), then the pillar is checked. If there is no match on owner, then driver is checked etc.

I think this mp also covers the intent of bug 81692, although that bug talks about additional checks eg registrant. Do we consider the work done here sufficient to address that bug?

== Tests ==

Add a bunch of tests to test_pillaraffiliation

== Lint ==

Linting changed files:
  lib/lp/registry/configure.zcml
  lib/lp/registry/model/pillaraffiliation.py
  lib/lp/registry/tests/test_pillaraffiliation.py

Revision history for this message

Curtis Hovey (sinzui) wrote on 2011-08-04:

#

Download full text (9.7 KiB)

> === modified file 'lib/lp/registry/model/pillaraffiliation.py'
> --- lib/lp/registry/model/pillaraffiliation.py 2011-08-04 14:31:56 +0000
> +++ lib/lp/registry/model/pillaraffiliation.py 2011-08-04 14:32:17 +0000
...
> + def getPillar(self):
> + return self.context
> +
> + def getAffiliationBadge(self, person):
> + """ Return the affiliation information for a person given a context.
> +
> + The context is a Distribution, Product etc and is associated with a
> + pillar. Checks are done to see if the person is associated with the
> + context first (owner, driver etc) and if not, then the pillar.
> + """
> + pillar = self.getPillar()
> +
> + def checkAffiliation(capability, attribute, role):
> + # Check the affiliation defined by the specified capability on the
> + # context and then pillar. Capability is IHasOwner etc. WHatever
> + # matches first (context or pillar) is used for the display name.
> + affiliated_entity = None
> + capabilityProvidedBy = getattr(capability, 'providedBy')
> + if capabilityProvidedBy(self.context):
> + if person.inTeam(getattr(self.context, attribute)):
> + affiliated_entity = self.context.displayname
> + if (affiliated_entity is None and capabilityProvidedBy(pillar)):
> + if person.inTeam(getattr(pillar, attribute)):
> + affiliated_entity = pillar.displayname
> + if affiliated_entity is None:
> + return None
> + return affiliated_entity, role

I do not see why this is an inner function. This could be simpler too if
we decide that all we care about is product or distribution. We know how to
check owner, drivers, and other roles. The other kinds of items I
see returned, notably for specification and question are probably wrong.
We do not need the interface checks if we are certain we are getting a
distro or product.

I have some doubts about the universality of these checks. I think
owner and driver are universal. bug_supervisor and security contact are
only useful in bugs and branches cases that deal with privacy and security.
eg assigning a branch reviewer, bug assignee, subscriber.

Questions might care more about answer contacts which are more likely to
be assigned. Consider Ubuntu. The owners and drivers are rarely assigned.
when I assign a question, I care about the answer contact for the package
first, then the contacts for Ubuntu.

Specifications care about the people who are assignees, drafters, approvers,
and need feedback. In most cases these people are owners and drivers. There
is a rare case for the approver who is for the series goal...

The series is the problem. Maybe a separate branch becuase it is a rule
that may not prove very important. The series driver (release manager) is
the most important person for bugs that affect a series or blueprints with
a series goal. Those driver are assumed to be a subset of owner or drivers
who have the authority to define the work for a series. I happen to know
that This is not an issue for Ubuntu or any of our major pro...

> === modified file 'lib/lp/registry/model/pillaraffiliation.py'
> --- lib/lp/registry/model/pillaraffiliation.py	2011-08-04 14:31:56 +0000
> +++ lib/lp/registry/model/pillaraffiliation.py	2011-08-04 14:32:17 +0000
...
> +    def getPillar(self):
> +        return self.context
> +
> +    def getAffiliationBadge(self, person):
> +        """ Return the affiliation information for a person given a context.
> +
> +         The context is a Distribution, Product etc and is associated with a
> +         pillar. Checks are done to see if the person is associated with the
> +         context first (owner, driver etc) and if not, then the pillar.
> +        """
> +        pillar = self.getPillar()
> +
> +        def checkAffiliation(capability, attribute, role):
> +            # Check the affiliation defined by the specified capability on the
> +            # context and then pillar. Capability is IHasOwner etc. WHatever
> +            # matches first (context or pillar) is used for the display name.
> +            affiliated_entity = None
> +            capabilityProvidedBy = getattr(capability, 'providedBy')
> +            if capabilityProvidedBy(self.context):
> +                if person.inTeam(getattr(self.context, attribute)):
> +                    affiliated_entity = self.context.displayname
> +            if (affiliated_entity is None and capabilityProvidedBy(pillar)):
> +                if person.inTeam(getattr(pillar, attribute)):
> +                    affiliated_entity = pillar.displayname
> +            if affiliated_entity is None:
> +                return None
> +            return affiliated_entity, role

I do not see why this is an inner function. This could be simpler too if
we decide that all we care about is product or distribution. We know how to
check owner, drivers, and other roles. The other kinds of items I
see returned, notably for specification and question are probably wrong.
We do not need the interface checks if we are certain we are getting a
distro or product.

I have some doubts about the universality of these checks. I think
owner and driver are universal. bug_supervisor and security contact are
only useful in bugs and branches cases that deal with privacy and security.
eg assigning a branch reviewer, bug assignee, subscriber.

Questions might care more about answer contacts which are more likely to
be assigned. Consider Ubuntu. The owners and drivers are rarely assigned.
when I assign a question, I care about the answer contact for the package
first, then the contacts for Ubuntu.

Specifications care about the people who are assignees, drafters, approvers,
and need feedback. In most cases these people are owners and drivers. There
is a rare case for the approver who is for the series goal...

The series is the problem. Maybe a separate branch becuase it is a rule
that may not prove very important. The series driver (release manager) is
the most important person for bugs that affect a series or blueprints with
a series goal. Those driver are assumed to be a subset of owner or drivers
who have the authority to define the work for a series. I happen to know
that This is not an issue for Ubuntu or any of our major projects. There
could be a project where the series driver is not a driver project or
project group driver. I am not inclined to fix this until we know it
is really broken.

I think the two universal roles could be in the base class. the subclass
could add the extra checks. We already have subclasses to handle the getting
the pillar. Maybe Questions is the only special case here because the answers
community is independent of code contributors.

> +        affiliation_details = checkAffiliation(
> +            IHasOwner, 'owner', 'maintainer')
> +        if affiliation_details is None:
> +            affiliation_details = checkAffiliation(
> +                IHasAppointedDriver, 'driver', 'driver')

This will give bad results for the driver attribute. drivers (note the 's') is
composed of the direct and indirect drivers for the object. so if we wanted to
support series, most of the ubuntu drivers would be ignored for bugs :(

> +        if affiliation_details is None:
> +            affiliation_details = checkAffiliation(
> +                IHasBugSupervisor, 'bug_supervisor', 'bug supervisor')
> +        if affiliation_details is None:
> +            affiliation_details = checkAffiliation(
> +                IHasSecurityContact, 'security_contact', 'security contact')
> +
> +        if not affiliation_details:
>              return None

We know that IDistribution and IProduct always have these attributes.
...

> +@adapter(ISpecification)
> +class SpecificationPillarAffiliation(PillarAffiliation):
> +    """An affiliation adapter for blueprints."""
> +    def getPillar(self):
> +        return (self.context.productseries or
> +            self.context.distroseries or
> +            self.context.product or
> +            self.context.distribution)

This is a little surprising since series are not targets, they are goals
that are likely to change. They are not pillars either. Series wrongly
have IHasOwner, but that is just the registrant. The owner has no authority.

This could be simple like
        return self.context.product or self.context.distribution
or
        return self.context.target

> +@adapter(IQuestion)
> +class QuestionPillarAffiliation(PillarAffiliation):
> +    """An affiliation adapter for questions."""
> +    def getPillar(self):
> +        return self.context.target

This will return a DSP 50% of the time in production. A target may be
a product, distribution or distribution source package. Recent code
uses IDistribution(target) to get the distro. maybe

pillar = IDistribution(self.context.target, none)
        if pillar is None:
            pillar = self.context.target
        return pillar
or
        return IDistribution(self.context.target, self.context.target)
or
        return self.context.product or self.context.distribution

We  could decide we wanted an IPillar() adapter to be sure we always get
a product or distro. I kind of have one with IServiceUsage. I do not think
it is necessary since it is pretty easy to get the right product or distro.

> === modified file 'lib/lp/registry/tests/test_pillaraffiliation.py'
> --- lib/lp/registry/tests/test_pillaraffiliation.py	2011-08-04 14:31:56 +0000
> +++ lib/lp/registry/tests/test_pillaraffiliation.py	2011-08-04 14:32:17 +0000
...
> +class TestDistroSeriesPillarAffiliation(TestCaseWithFactory):
> +
> +    layer = DatabaseFunctionalLayer
> +
> +    def test_correct_pillar_is_used(self):
> +        series = self.factory.makeDistroSeries()
> +        badge = IHasAffiliation(series)
> +        self.assertEqual(series.distribution, badge.getPillar())
> +
> +    def test_distroseries_driver_affiliation(self):
> +        # A person who is the driver for a distroseries distribution is
> +        # affiliated. Here, the affiliation is with the distribution of the
> +        # series.
> +        owner = self.factory.makePerson()
> +        driver = self.factory.makePerson()
> +        distribution = self.factory.makeDistribution(
> +            owner=owner, name='pting')
> +        removeSecurityProxy(distribution).driver = driver
> +        distroseries = self.factory.makeDistroSeries(
> +            registrant=owner, distribution=distribution)
> +        badge = IHasAffiliation(distroseries).getAffiliationBadge(driver)
> +        self.assertEqual(
> +            ("/@@/distribution-badge", "Pting driver"), badge)

This is good in because it recognises the importance of the release manager,
but it ignores the drivers that are assigned to the distribution. The
drivers property is better I think.

> +    def test_distroseries_owner_affiliation(self):
> +        # A person who owns a distroseries is affiliated.
> +        person = self.factory.makePerson()
> +        distribution = self.factory.makeDistribution(
> +            owner=person, name='pting')
> +        distroseries = self.factory.makeDistroSeries(
> +            distribution=distribution)
> +        badge = IHasAffiliation(distroseries).getAffiliationBadge(person)
> +        self.assertEqual(
> +            ("/@@/distribution-badge", "%s maintainer" %
> +                distroseries.displayname), badge)

Distroseries do not have owners. The property just returns the distro owner.

> +class TestProductSeriesPillarAffiliation(TestCaseWithFactory):
> +
> +    layer = DatabaseFunctionalLayer
> +
> +    def test_correct_pillar_is_used(self):
> +        series = self.factory.makeProductSeries()
> +        badge = IHasAffiliation(series)
> +        self.assertEqual(series.product, badge.getPillar())

What of the series driver (release manager)? What of the drivers from the
project group? Lots of things are assigned the the Canonical PM team that
own the project groups but the individual projects and series have different
owners.

Beware of ProductSeries.owner. That field is actually registrant and it does
not convey authority.

> +class TestQuestionPillarAffiliation(TestCaseWithFactory):
> +
> +    layer = DatabaseFunctionalLayer
> +
> +    def test_correct_pillar_is_used(self):
> +        product = self.factory.makeProduct()
> +        question = self.factory.makeQuestion(target=product)
> +        badge = IHasAffiliation(question)
> +        self.assertEqual(question.target, badge.getPillar())

I think this will fail if you used a DSP as the target.

> +class TestSpecificationPillarAffiliation(TestCaseWithFactory):
> +
> +    layer = DatabaseFunctionalLayer
> +
> +    def test_correct_pillar_is_used(self):
> +        product = self.factory.makeProduct()
> +        specification = self.factory.makeSpecification(product=product)
> +        badge = IHasAffiliation(specification)
> +        self.assertEqual(specification.product, badge.getPillar())

If I set a set this blueprint to a goal, this test wpuld fail.

review: Needs Information (code)

Revision history for this message

Ian Booth (wallyworld) wrote on 2011-08-05:

#

Download full text (9.8 KiB)

Thanks for the review. Clearly I'm missing some knowledge.

On 05/08/11 05:22, Curtis Hovey wrote:
> Review: Needs Information code
>> === modified file 'lib/lp/registry/model/pillaraffiliation.py'
>> --- lib/lp/registry/model/pillaraffiliation.py 2011-08-04 14:31:56 +0000
>> +++ lib/lp/registry/model/pillaraffiliation.py 2011-08-04 14:32:17 +0000
> ...
>> + def getPillar(self):
>> + return self.context
>> +
>> + def getAffiliationBadge(self, person):
>> + """ Return the affiliation information for a person given a context.
>> +
>> + The context is a Distribution, Product etc and is associated with a
>> + pillar. Checks are done to see if the person is associated with the
>> + context first (owner, driver etc) and if not, then the pillar.
>> + """
>> + pillar = self.getPillar()
>> +
>> + def checkAffiliation(capability, attribute, role):
>> + # Check the affiliation defined by the specified capability on the
>> + # context and then pillar. Capability is IHasOwner etc. WHatever
>> + # matches first (context or pillar) is used for the display name.
>> + affiliated_entity = None
>> + capabilityProvidedBy = getattr(capability, 'providedBy')
>> + if capabilityProvidedBy(self.context):
>> + if person.inTeam(getattr(self.context, attribute)):
>> + affiliated_entity = self.context.displayname
>> + if (affiliated_entity is None and capabilityProvidedBy(pillar)):
>> + if person.inTeam(getattr(pillar, attribute)):
>> + affiliated_entity = pillar.displayname
>> + if affiliated_entity is None:
>> + return None
>> + return affiliated_entity, role
>
> I do not see why this is an inner function. This could be simpler too if

Me either.

> we decide that all we care about is product or distribution. We know how to
> check owner, drivers, and other roles. The other kinds of items I
> see returned, notably for specification and question are probably wrong.
> We do not need the interface checks if we are certain we are getting a
> distro or product.
>

Will we always be getting a distro or product though? If I have a
Specification, wouldn't I want to possibly first see if the person in
question is affiliated with the specification itself and then check the
affiliation with the target (product/distro) only if the specification
check turned up empty?

> I have some doubts about the universality of these checks. I think
> owner and driver are universal. bug_supervisor and security contact are
> only useful in bugs and branches cases that deal with privacy and security.
> eg assigning a branch reviewer, bug assignee, subscriber.
>

This suggests we need another piece of context information to properly
determine the affiliation - the name of the attribute that is being
updated with the person, not just the person alone. So instead of saying
"we are associating person fred with bugtask 4 in some capacity" we are
saying "we are associating person fred with bugtask 4 as an assignee"
and that this distinction possibly affect...

Thanks for the review. Clearly I'm missing some knowledge.

On 05/08/11 05:22, Curtis Hovey wrote:
> Review: Needs Information code
>> === modified file 'lib/lp/registry/model/pillaraffiliation.py'
>> --- lib/lp/registry/model/pillaraffiliation.py	2011-08-04 14:31:56 +0000
>> +++ lib/lp/registry/model/pillaraffiliation.py	2011-08-04 14:32:17 +0000
> ...
>> +    def getPillar(self):
>> +        return self.context
>> +
>> +    def getAffiliationBadge(self, person):
>> +        """ Return the affiliation information for a person given a context.
>> +
>> +         The context is a Distribution, Product etc and is associated with a
>> +         pillar. Checks are done to see if the person is associated with the
>> +         context first (owner, driver etc) and if not, then the pillar.
>> +        """
>> +        pillar = self.getPillar()
>> +
>> +        def checkAffiliation(capability, attribute, role):
>> +            # Check the affiliation defined by the specified capability on the
>> +            # context and then pillar. Capability is IHasOwner etc. WHatever
>> +            # matches first (context or pillar) is used for the display name.
>> +            affiliated_entity = None
>> +            capabilityProvidedBy = getattr(capability, 'providedBy')
>> +            if capabilityProvidedBy(self.context):
>> +                if person.inTeam(getattr(self.context, attribute)):
>> +                    affiliated_entity = self.context.displayname
>> +            if (affiliated_entity is None and capabilityProvidedBy(pillar)):
>> +                if person.inTeam(getattr(pillar, attribute)):
>> +                    affiliated_entity = pillar.displayname
>> +            if affiliated_entity is None:
>> +                return None
>> +            return affiliated_entity, role
> 
> I do not see why this is an inner function. This could be simpler too if

Me either.

> we decide that all we care about is product or distribution. We know how to
> check owner, drivers, and other roles. The other kinds of items I
> see returned, notably for specification and question are probably wrong.
> We do not need the interface checks if we are certain we are getting a
> distro or product.
>

Will we always be getting a distro or product though? If I have a
Specification, wouldn't I want to possibly first see if the person in
question is affiliated with the specification itself and then check the
affiliation with the target (product/distro) only if the specification
check turned up empty?

> I have some doubts about the universality of these checks. I think
> owner and driver are universal. bug_supervisor and security contact are
> only useful in bugs and branches cases that deal with privacy and security.
> eg assigning a branch reviewer, bug assignee, subscriber.
>

This suggests we need another piece of context information to properly
determine the affiliation - the name of the attribute that is being
updated with the person, not just the person alone. So instead of saying
"we are associating person fred with bugtask 4 in some capacity" we are
saying "we are associating person fred with bugtask 4 as an assignee"
and that this distinction possibly affects the affiliation. Perhaps for
now we could ignore this distinction and land a subsequent branch which
accounts for it.

> Questions might care more about answer contacts which are more likely to
> be assigned. Consider Ubuntu. The owners and drivers are rarely assigned.
> when I assign a question, I care about the answer contact for the package
> first, then the contacts for Ubuntu.
> 
> Specifications care about the people who are assignees, drafters, approvers,
> and need feedback. In most cases these people are owners and drivers. There
> is a rare case for the approver who is for the series goal...
>

So it seems the affiliation checks are not as generic as I had hoped. So
I will attempt to flesh out the various adaptors for the different
entity classes with specific rules.

> The series is the problem. Maybe a separate branch becuase it is a rule
> that may not prove very important. The series driver (release manager) is
> the most important person for bugs that affect a series or blueprints with
> a series goal. Those driver are assumed to be a subset of owner or drivers
> who have the authority to define the work for a series. I happen to know
> that This is not an issue for Ubuntu or any of our major projects. There
> could be a project where the series driver is not a driver project or
> project group driver. I am not inclined to fix this until we know it
> is really broken.
>

Fine with me.

> I think the two universal roles could be in the base class. the subclass
> could add the extra checks. We already have subclasses to handle the getting
> the pillar. Maybe Questions is the only special case here because the answers
> community is independent of code contributors.
> 
>> +        affiliation_details = checkAffiliation(
>> +            IHasOwner, 'owner', 'maintainer')
>> +        if affiliation_details is None:
>> +            affiliation_details = checkAffiliation(
>> +                IHasAppointedDriver, 'driver', 'driver')
> 
> This will give bad results for the driver attribute. drivers (note the 's') is
> composed of the direct and indirect drivers for the object. so if we wanted to
> support series, most of the ubuntu drivers would be ignored for bugs :(
>

I don't fully understand the above issue. Are we saying that for bugs
the driver affiliation check should be done first before owner? If not,
is that why ubuntu drivers would be ignored? Sorry, I'm confused here.

>> +        if affiliation_details is None:
>> +            affiliation_details = checkAffiliation(
>> +                IHasBugSupervisor, 'bug_supervisor', 'bug supervisor')
>> +        if affiliation_details is None:
>> +            affiliation_details = checkAffiliation(
>> +                IHasSecurityContact, 'security_contact', 'security contact')
>> +
>> +        if not affiliation_details:
>>              return None
> 
> We know that IDistribution and IProduct always have these attributes.
> ...

Yes. But other things like Questions etc don't and based on my comments
above, my thought was that we would be checking against other entity
types, and so the above code handles this generically.

> 
>> +@adapter(ISpecification)
>> +class SpecificationPillarAffiliation(PillarAffiliation):
>> +    """An affiliation adapter for blueprints."""
>> +    def getPillar(self):
>> +        return (self.context.productseries or
>> +            self.context.distroseries or
>> +            self.context.product or
>> +            self.context.distribution)
> 
> This is a little surprising since series are not targets, they are goals
> that are likely to change. They are not pillars either. Series wrongly
> have IHasOwner, but that is just the registrant. The owner has no authority.
> 
> This could be simple like
>         return self.context.product or self.context.distribution
> or
>         return self.context.target
>

Ah right. I wanted to user self.context.target but thought that the
[product|distro]series also had to be included in the affiliation check,
hence the code as written.

>> +@adapter(IQuestion)
>> +class QuestionPillarAffiliation(PillarAffiliation):
>> +    """An affiliation adapter for questions."""
>> +    def getPillar(self):
>> +        return self.context.target
> 
> This will return a DSP 50% of the time in production. A target may be
> a product, distribution or distribution source package. Recent code
> uses IDistribution(target) to get the distro. maybe
> 
>         pillar = IDistribution(self.context.target, none)
>         if pillar is None:
>             pillar = self.context.target
>         return pillar
> or
>         return IDistribution(self.context.target, self.context.target)
> or
>         return self.context.product or self.context.distribution
>

So there's no need to check if a person is somehow affiliated with the DSP?

<snip>

>> +class TestProductSeriesPillarAffiliation(TestCaseWithFactory):
>> +
>> +    layer = DatabaseFunctionalLayer
>> +
>> +    def test_correct_pillar_is_used(self):
>> +        series = self.factory.makeProductSeries()
>> +        badge = IHasAffiliation(series)
>> +        self.assertEqual(series.product, badge.getPillar())
> 
> What of the series driver (release manager)? What of the drivers from the
> project group? Lots of things are assigned the the Canonical PM team that
> own the project groups but the individual projects and series have different
> owners.
>

The code in the base class first checks the context (the series) and
then the pillar (the product). So the series driver will be used as the
affiliation if it matches. The project group is ignored you are correct.
So are we saying that anytime a project affiliation is checked, we
should also check against the project group too? Or just in this case?

> Beware of ProductSeries.owner. That field is actually registrant and it does
> not convey authority.
>

So no owner checks for product series?

>> +class TestQuestionPillarAffiliation(TestCaseWithFactory):
>> +
>> +    layer = DatabaseFunctionalLayer
>> +
>> +    def test_correct_pillar_is_used(self):
>> +        product = self.factory.makeProduct()
>> +        question = self.factory.makeQuestion(target=product)
>> +        badge = IHasAffiliation(question)
>> +        self.assertEqual(question.target, badge.getPillar())
> 
> I think this will fail if you used a DSP as the target.
>

I'll try it.

>> +class TestSpecificationPillarAffiliation(TestCaseWithFactory):
>> +
>> +    layer = DatabaseFunctionalLayer
>> +
>> +    def test_correct_pillar_is_used(self):
>> +        product = self.factory.makeProduct()
>> +        specification = self.factory.makeSpecification(product=product)
>> +        badge = IHasAffiliation(specification)
>> +        self.assertEqual(specification.product, badge.getPillar())
> 
> If I set a set this blueprint to a goal, this test wpuld fail.

I'll check.

lp://staging/~wallyworld/launchpad/additional-affiliation-types updated on 2011-08-05

13603. By Ian Booth on 2011-08-05: Rework affiliation checks and reimplement question adaptor
13604. By Ian Booth on 2011-08-05: Reimplement specification adaptor
13605. By Ian Booth on 2011-08-05: Reimplement distro/product affiliation adaptors and fix tests
13606. By Ian Booth on 2011-08-05: Add extra tests for distroseries and productseries
13607. By Ian Booth on 2011-08-05: Merge from trunk

Unmerged revisions

13607. By Ian Booth on 2011-08-05: Merge from trunk
13606. By Ian Booth on 2011-08-05: Add extra tests for distroseries and productseries
13605. By Ian Booth on 2011-08-05: Reimplement distro/product affiliation adaptors and fix tests
13604. By Ian Booth on 2011-08-05: Reimplement specification adaptor
13603. By Ian Booth on 2011-08-05: Rework affiliation checks and reimplement question adaptor
13602. By Ian Booth on 2011-08-04: Lint
13601. By Ian Booth on 2011-08-04: Lint
13600. By Ian Booth on 2011-08-04: Implement affiliation for other entity types
13599. By Ian Booth on 2011-08-04: Merge from trunk
13598. By Ian Booth on 2011-08-03: Improve affiliatin text

Launchpad itself

Merge lp://staging/~wallyworld/launchpad/additional-affiliation-types into lp://staging/launchpad

Commit message

Description of the change

Unmerged revisions

Preview Diff

Subscribers