← Back to team overview

launchpad-dev team mailing list archive

Re: visibility vs. information_type for Products

 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-09-18 10:44 AM, Curtis Hovey wrote:
> On 09/17/2012 04:35 PM, Deryck Hodge wrote:
>> I'd like to use information_type for a few reasons.
>> 
>> 
>> **Consistency with other parts of the code**
>> 
>> It doesn't make sense to me to have different names for things
>> that are basically the same concept in our code.  it's simpler
>> and more consistent to stick with information_type.  Other devs
>> who come along won't have to get their head around how visibility
>> and information_type are related, even basically the same, yet
>> somehow different.
> 
> I am -0 with this. It disagrees with PersonVisibility. Do you want
> to replace PersonVisiblity with InformationType too.

I don't really understand how private teams work.  Is the idea that
they have AccessPolicies, and then anyone with the right
AccessPolicyGrant can see them?  If so, it sounds like it would be a
good fit.

> InformationType represents the content the content of an artefact. 
> Projects and teams are not documents/parts.

Right, but Milestones and Series, which will derive their
InformationType from Project are parts.

> I agree that three of the enums do work with projects and teams,
> but two imply the project or team exists to create maleware or
> phishing scams. We will not except that. Projects and team might
> use a base class or subclass that only contains the three sensible
> enums.

That's okay, it doesn't affect the database representation-- it's an
int either way.

> Otherwise the db and applications needs constraints to ensure
> non-sense is not excepted.

We need that anyway, e.g. for Specification.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBYoeUACgkQ0F+nu1YWqI2anACfYHaKtEt0/rW5FX+DQkb/UlFE
hp4Anjs2qtV3B3AK731ACLBY2ACbRPrD
=Qrpc
-----END PGP SIGNATURE-----


Follow ups

References