Bug 317558 - When specifying manual Bug ID, Bug should appear in List
Summary: When specifying manual Bug ID, Bug should appear in List
Status: RESOLVED FIXED
Alias: None
Product: drkonqi
Classification: Applications
Component: general (show other bugs)
Version: 2.1.5
Platform: Chakra Linux
: NOR wishlist
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-29 17:52 UTC by Richard Llom
Modified: 2021-07-16 09:59 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of current Bug-Page in DrKonqi with Mockup (48.93 KB, image/png)
2013-03-29 17:52 UTC, Richard Llom
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Llom 2013-03-29 17:52:57 UTC
Created attachment 78489 [details]
Screenshot of current Bug-Page in DrKonqi with Mockup

In the search for bugs page in dr konqi, one can specify by hand a bug ID to attach the report to. However, this bug gets not listed as an entry in table, but as a small text below, which can easily be overlooked and is quite confusing/inconsistent.

It would be nice to have these manual entered bugs appear in the table. See also attached screenshot.
Comment 1 Jekyll Wu 2013-03-30 04:30:10 UTC
Makes sense :)
Comment 2 Bug Janitor Service 2021-07-09 12:33:13 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/drkonqi/-/merge_requests/35
Comment 3 Harald Sitter 2021-07-16 09:59:15 UTC
Git commit 6cc8ee5d558576e08a37b919ddffea5863cec8b5 by Harald Sitter.
Committed on 13/07/2021 at 11:03.
Pushed by sitter into branch 'master'.

remove the 'manually enter bug id' feature

it has an incredibly niche use case to begin with. but what's more it's
also superfluous and sports weird UX.

things wrong with it:

- bug doesn't get added to the model (would cost at least 20 extra lines
of code)
- it takes a whooping 6 extra clicks to get the bug added at all (+API
request delay to fetch the bug and comments)
- the UX is the same as for when you click an arbitrary bug, but of
course this isn't an arbitrary bug. at the point that the reporter can
give drkonqi a bug number the report will already know if this is a
complete dupe or possible dupe, also they will have looked at the bug
and comments already
- being so incredibly useless the entry takes up space that could be
used for a real actually useful dupe candidate
- it needlessly complicates the code because of how it is implemented.
with offsetting falling you on the head in every other function because
the first entry isn't a real entry

the legit use case behind this is that a triager could try to get a
better trace and attach it to the bug. for that it indeed makes a lot of
sense... if it wasn't for the fact that the report can more easily copy
paste the trace manually! having to go through the reporter dialog makes
no sense for this use case: you have to click through numerous wizard
pages. some of them don't even let you move on unless you say you know
what's going on. then you have to go through the 6 extra click nonesense
to mark the bug as dupe. for **zero** extra value added over using the
the main dialog and clicking on the 'developer info' tab and copy
pasting the trace to the bug report. In point of fact, whenever I've
seen a triage do something like this, they've taken the copy paste
route, not the overly complex and annoying reporter route.

and to top it all up the entire thing only even makes sense iff dupe
detection does not work to begin with. i.e. if the dupe finder finds the
dupe, there is no point in manually adding it at all!

M  +4    -41   src/bugzillaintegration/reportassistantpages_bugzilla_duplicates.cpp

https://invent.kde.org/plasma/drkonqi/commit/6cc8ee5d558576e08a37b919ddffea5863cec8b5