348519 - prefill default requestee for patch flags

Status: RESOLVED WONTFIX

(Bugzilla :: Attachments & Requests, enhancement, P5)

Description

[timeless]

This is a bit of a risk, about two strokes.

in bmo it will win very rarely, so probably the intelligence should be more complicated than the obvious:

steps:
1. find a bug, bug 339991 works
2. write a patch and attach it
3. go edit the attachment
4 [review]. select review's ? value
5. click commit.

expected steps by Bugzilla:
when you edit the attachment any requestee fields that are listed as [ ] but which can be listed as [?] should prefill their requestable value according to some logic. the basic logic is described below but is subject to negotiation:

a. if the flag has a default requestee for this component/product/flag, use that value

b. if the bug has an assignee which doesn't match the person changing the flag consider the person
c. if qa is enabled and the bug has a qa and the qa is not the person changing the flag consider the qa.

definition of consider:
d. if the user is marked in nomail, reject the candidate and continue
e. if the user has not logged in in the past 3 months, reject the candidate and continue

i suppose the definition of logged in is special, if someone has a token which they used yesterday but which they created a year ago, they should have been considered to be logged in yesterday from my perspective. i have no idea whether Bugzilla knows this, if it doesn't, that's an implementation bug.

f. if Bugzilla finds a candidate which it hasn't excluded, it should use that email address instead of empty as the default value.

expected results:

review:[ |v] wtchang...
       |?  |
...

Comment 1

[Frédéric Buclin]

You have no way to know when a user logged in for the last time. We would first need a last_logged_in_date column in the profiles table.

Comment 2

[Max Kanat-Alexander]

(In reply to comment #1)
> You have no way to know when a user logged in for the last time. We would first
> need a last_logged_in_date column in the profiles table.

  Which we would probably never do, because we'd have to do an UPDATE on the profiles table every time somebody loaded any page, if they were logged in.

  I think this is a WONTFIX.

Comment 3

[timeless]

first f is optional, if you don't have a way to exclude someone, don't exclude them. prefilling the field with a value should not hurt anyone.

as for how f can happen. 
i think that can be managed by a cron script that runs once a month. it doesn't have to be very frequent. and all it has to do is query bugs with a last modified newer than last scan. for any bug filed after last scan, check the reporter, for all bugs modified after last scan, check the comments later than last scan and the acitity log since last scan.

but again, f is optional, it isn't needed for the ui to be better.

Comment 4

[timeless]

I think the way to make this work better for bmo is to add some other users to the pot.

I might as well start drafting some SQL for feedback. Yes I know some of this stuff should be done using JOIN statements of some shape or form. For now I'm merely trying to define concepts. If people want to suggest which statements to use w/ JOINs, I'm all ears.

this covers d:
SELECT userid FROM profiles WHERE disable_mail = 0 AND userid IN (...)

this covers b,c:
avail = SELECT initialowner, initialqacontact FROM components WHERE id = ?

foreach cand (avail) push avail, cand IF cand != user;

here's the bmo case:
avail = SELECT assigned_to, COUNT(assigned_to) FROM bugs WHERE delta_ts > ? AND resolution = "FIXED" GROUP BY assigned_to

foreach cand (avail) push avail, cand IF cand != user;

here's my definition for e:
limit = select NOW()-90D

VALUES (limit, user):
files = select_1 bug_id FROM bugs WHERE creation_ts > ? AND reporter = ?
comments = select_1 comment_id FROM longdesc WHERE bug_when > ? AND who = ?
triages = select_1 bug_id FROM bugs_activity WHERE bug_when > ? AND who = ?

could someone indicate if this definition is particularly expensive?

select_1 means i just want some query that tells me if there are any matches, i don't care what the match is. (if i can use SELECT 1 FROM ... instead of SELECT key FROM, I'll gladly do that).

afai-understand, triages will catch flag changes.

A bit more intelligence is possible (I think the next step is rand() on a list of about 10 or maybe looking into the request queue).

An alternate, additional, or strict criteria for automatic could be this:
SELECT id FROM flags WHERE setter_id = ? AND status = '+' AND type_id = ?

where setter_id comes form cands and type_id is the flag that could be set.

This would mean that the only suggestions given would be people who have actually taken this action.

and, a replacement for the three select_1 queries above could be:
select_1 id FROM flags WHERE setter_id = ? AND status = '+' AND type_id = ?
AND modification_date > ?
with that being limit.

I suspect some of this would be optimizable using:
SELECT DISTINCT setter_id ... WHERE setter_id IN (...) ...

Comment 5

[Frédéric Buclin]

OK, I'm definitely not going to take such a RFE upstream. If you really want to implement something so crazy, please do it as a plugin or a local customization.