launchpad-dev team mailing list archive

[Abel Deuring <abel.deuring@xxxxxxxxxxxxx>]

Hi Stuart,

I am currently working on
https://bugs.edge.launchpad.net/malone/+bug/39674 (Attachments of
private bugreports are public). This involves of course to set the
attribute LFA.restricted to True for private bugs.

My first idea was to simply set the restricted flag of all LFAs of
BugAttachments of a bug in the method Bug.setPrivate().

But a comment from Robert in
https://code.edge.launchpad.net/~adeuring/launchpad/bug-39674-lfa-editable/+merge/29314
let me think again if we should enforce the consistency of
LFA.restricted and Bug.private on the database level.

If we ensure that at least LFAs of BugAttachments are referenced exactly
once (in a trigger for UPDATE and INSERT statements for all tables which
reference LFAs, see my reply to Robert in the MP), we can add a trigger
for the table Bug to ensure that you can set private=true only if
LFA.restricted is true for all related LFAs, and we could add a trigger
for LFA to ensure that you can set LFA.restricted=false only if this LFA
is not referenced by the table bug or if the referencing row of Bug has
private == false.

Setting the LFA.restricted immediately in a trigger of the table Bug. is
probably not a good idea:
(1) IIRC, Robert and Graham recently chased a bug which was caused by an
inconsistency between data in a cached Storm object and the "real" DB
data which was changed by a trigger,
(2) Once bug 39674 is fixed, we might also allow private attachments for
public bugs -- this would make it less risky to add bug attachments
containing for example core dumps or stack traces to bugs which don't
need to be private. (I think there are also some bugs filed for such a
feature)

What do you think?

Abel