launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 29 March 2011 11:59, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Tue, Mar 29, 2011 at 12:50 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>> Agreed we need to be careful. What is "inline editing of lists of bugs"? Or
>> is that a hypothetical future feature?
>
> today I know of cve:+index, blueprints linked bugs; cve:+index is
> having it removed because its just too slow *today*.
>
>> It seems to me we already have to evaluate membership rules to know whether
>> a person can change importance. Reading one boolean off the bug and using
>> that to cause the same rules to apply to status and other metadata fields
>> should be no slower?
>
> No, because bug control is derived from the bug task, so you have to
> repeat it per task row. (And you need to decide about the bug/bugtask
> interaction in such policies).

Just so I understand, can you point out where my logic is wrong here:

 * places that let you edit bug status inline will probably let you
edit importance too
 * to know whether the user can change the importance field, we need
to know if they have the bug control privilege for the relevant rule
 * since we've already loaded the bug, checking it's "locked" field
will be not require any additional queries
 * since we've already calculated whether the user is in the bug
control group, using that in conjunction with the lock bit to
determine whether the status should be mutable should also be very
cheap and not cause any additional queries

I can see how lbyl access checks for every bug in a table could get
expensive.  If this is rolled out more widely, possibly we should not
lbyl but rather just give an error if the user tries to change
something they're not allowed to change.

Martin