Selecting a job should automatically add it to the pinboard... or at least if the pinboard was empty. Currently: 1) WIth pinboard open (but empty) from previous classification, select a new failing job 2) Press the pin next to the desired bug suggestion 3) Try to press save Expected: Able to save, since job was added to pinboard at #1 Actual: Unable to save since no job pinned.
Those steps work for me on production treeherder... I would like to have a job automatically pinned when I manually enter classification details with it selected but not pinned.
I don't have more specific STR, but I can assure you it didn't work for me :-)
I tried this on dev with windows but was unable to reproduce it either. So far every time I click on an adjacent pin icon beside the bug suggestion, it pins the job. I tried a few other variant workflows also, using the next-failure keys, using mouse input, explicitly opening the pinboard beforehand, etc.
Maybe steps 2,3 just confused me a bit. If the request is to simply auto-pin on job selection when the pinboard is empty - I guess we should be consistent to auto-pin all jobs regardless of type? I imagine the pinboard behavior could get pretty confusing otherwise. I would think :KWierso's workflow would generally result in an auto-pin because it would be selected anyway prior to entering classification details? Though one scenario where his could apply might be: 1) selects a job (we auto-pin if pinboard is empty) 2) user manually removes job from pinboard via its [x] icon (job is still selected in main panel) 3) user enters classification info (...this would trigger the proposed auto-pin in comment#1 ?)
Revised STR: 1) Select a failed, unclassified job 2) Open the pinboard (or alternatively the pinboard is open and empty already, from a previous classification) 3) Choose "fixed by commit" and paste a SHA in the reason box 4) Try to submit the classification Expected: Able to save the classification (like pressing 'add a comment', adding text and pressing submit in TBPL) Actual: It's both unclear that I have to manually pin a job (ie that having the job selected is insufficient; thought this is bug 1074939), and also a regression from TBPL in that it's an extra click. Perhaps we just need to never allow the pinboard to be empty? ie: the currently selected job is always added to the pinboard (for the duration of that job being the currently selected one), even if it wasn't manually pinned?
(In reply to Ed Morley [:edmorley] from comment #5) > Perhaps we just need to never allow the pinboard to be empty? ie: the > currently selected job is always added to the pinboard (for the duration of > that job being the currently selected one), even if it wasn't manually > pinned? In that use case, w.r.t. the duration of that job selection, I guess we would assume that: a) we will only auto-pin if the pinboard is empty b) we will not auto-pin if any other job is pinned c) if the selected job is the only job pinned (ie. auto-pin above), a de-selection of that job would unpin it d) if the selected job was manually pinned prior*, and the only job pinned, a de-selection of that job would also unpin it *I wonder if d) could be problematic. Where simply by deselecting a job we are making an assumption of what the user wants to do. They may have consciously pinned some jobs, happen to pare down their pins to just 1 job, and happen to click away from that job in the main panel, and it's now out of the pinboard. Granted if they click it again, it's back in. To point out also here for posterity, that Ctrl/Cmd + click does exactly the desired behavior already. If we make some sort of auto-pin, we'd have to resolve that also. Users would read the help and believe they need a meta key to click-pin, and they'd see the app doing something else, but only sometimes. Hopefully I've understood the description :)
(In reply to Jonathan French (:jfrench) from comment #6) > (In reply to Ed Morley [:edmorley] from comment #5) > > Perhaps we just need to never allow the pinboard to be empty? ie: the > > currently selected job is always added to the pinboard (for the duration of > > that job being the currently selected one), even if it wasn't manually > > pinned? > > In that use case, w.r.t. the duration of that job selection, I guess we > would assume that: > > a) we will only auto-pin if the pinboard is empty I think we actually don't want this. ie: In TBPL's implementation, "set of jobs on which the operation will be performed" was unique(currently_viewed_job + all_selected_jobs). This seems easier to implement, and more intuitive for the user? As an added bonus, we could add the ability to click remove on the currently viewed job in the pinboard, which would clear the job details panel (to make it more intuitive for the user), but leave the pinboard/classification UI showing, so the pinned jobs could be classified.