launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

Hi, all.

I had an MP a week or so ago to propose a new column on Product for
enabling privacy.  I was wanting to add information_type to Product,
as has been done with all the other artifacts so far.  Robert pushed
back a bit on this, suggesting that information_type had values that
wouldn't apply, and Curtis agreed, though he supported the idea of
another enum called visibility that would just support PUBLIC,
PROPRIETARY, and EMBARGOED.  I'd like to push back on those arguments
myself and make the case for information_type.  I figure the mailing
list is the best place to do this.

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.

**Milestones and Series will inherit information_type from Product**

Again, this is about the simpler and consistent approach to just refer
to the attributes on the artifacts and also on Product by the same
name.  It's also more directly obvious what's going on if
milestones/series don't directly implement information_type.  i.e. it
makes more sense to say Milestone gets it's information_type from
Product, rather than Milestone infers information_type from
Product.visibility.

**The values should be the same numbers**

For example, we should be able to consistently refer to PROPRIETARY as
5, rather than it be 5 for information_type and 3 for visibility when
working directly in queries.

**Avoiding references to both visibility and information_type in code**

I'm sure there will be places in code where we'll have to teach the
code that visibility is like information_type for the sake of that
code.  Things like the privacy banner come to mind.  Why not just
consistently refer to information_type, rather than all the `if
visibility == PROPRIETARY or information_type == PROPRIETARY`
constructions?  Simple to work around, I know, but it does equate to
more code.  I think being consistent with information_type makes the
code simpler, smaller, and easier to maintain.


There's probably a few other arguments to be made, but this hits the
high points.  I'll leave it to others on Orange to weigh in if they
want.  I think the main argument against using information_type is
that it supports values that don't apply for Products.  I understand
that point, but we can limit the values from information_type directly
and still use information_type without all the headache of adding yet
another enum that really is just like information_type with some
values removed.

Based on all this, I'd really like to use Product.information_type
unless people strongly object or see obvious problems that I'm not
seeing.  What do others think about this?


Cheers,
deryck


-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/