Bug 1121214 - include bug id in URL of attachments
Summary: include bug id in URL of attachments
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Bugzilla
Classification: Community
Component: Attachments/Requests
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified vote
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-18 16:15 UTC by Eric Blake
Modified: 2014-07-22 01:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-22 01:05:01 UTC


Attachments (Terms of Use)

Description Eric Blake 2014-07-18 16:15:13 UTC
Description of problem:
Quoting from the Fedora test list:


On 07/18/2014 09:45 AM, Adam Williamson wrote:> On Thu, 2014-07-17 at 20:53 -0400, Felix Miata wrote:
>> On 2014-07-17 20:41 (GMT-0400) Adam Williamson composed:
>>
>>>> https://bugzilla.redhat.com/attachment.cgi?id=918676
>>
>>> What bug is this attached to? Bugzilla does not provide a backtrack from
>>> an attachment to a bug report, infuriatingly.
>>
>> A convenient link to click, you're right, it has none. But there is a way. 
>> Simply append &action=edit to the attachment URL and you will get a page that 
>> provides a link to the bug it's attached to.
> 
> Hah, nice workaround, I should've thought of that. thanks.

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. click on the attachment of any bug
2. using just that URL, try to get back to the bug
3.

Actual results:
Unless you know the '&action=edit' trick, there is no easy way to get from a raw attachment link back to the bug it is tied to.

Expected results:
It would be nice if the URLs generated for attachment pages included a parameter describing the bug id the attachment belongs to.

Obviously, the lookup engine should still hit the right attachment without the bugid addon present in the URL, so existing attachment URLs still work; and in the case of a user (intentionally?) mismatching an attachment id vs. bug id, it's probably better to take the user to the right attachment (that is, have the bug id parameter ignored on input, generated on output).

Additional info:

Comment 1 Jason McDonald 2014-07-21 02:02:17 UTC
(In reply to Eric Blake from comment #0)
> https://bugzilla.redhat.com/attachment.cgi?id=918676
>
> What bug is this attached to? Bugzilla does not provide a backtrack from
> an attachment to a bug report, infuriatingly.

Note that the attachment URL above is a direct pointer to the attachment data, which could be any type of file, so including a bug-link there is not possible without changing that URL into an html page with another link to the attachment data (and the back link to the bug).  That would be a significant API change which would break a number of client scripts.

> Steps to Reproduce:
> 1. click on the attachment of any bug
> 2. using just that URL, try to get back to the bug

How common is the use-case? (Somebody pastes an attachment link somewhere without bothering to post the bug link alongside it.)

Can a little user education be applied to this situation?  

> Expected results:
> It would be nice if the URLs generated for attachment pages included a
> parameter describing the bug id the attachment belongs to.
> 
> Obviously, the lookup engine should still hit the right attachment without
> the bugid addon present in the URL, so existing attachment URLs still work;
> and in the case of a user (intentionally?) mismatching an attachment id vs.
> bug id, it's probably better to take the user to the right attachment (that
> is, have the bug id parameter ignored on input, generated on output).

That's probably doable from a technical point of view, though there are some corner-cases that will need some thought (like what happens if the attachment id refers to a private attachment that the user cannot see, what happens if the bug id doesn't match the attachment, and what happens if someone adds other parameters to the URL).

In any case, this is a request that ideally should go to the upstream Bugzilla project rather than Red Hat Bugzilla, as there's nothing Red Hat or Fedora-specific in the problem or the suggested solution (i.e. Fedora folks would also have the same problem with links to attachments in any other Bugzilla instance).

Therefore, I'd suggest submitting this request to https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla.  If accepted by the upstream project, Red Hat Bugzilla could inherit the upstream change without having to carry extra patches of our own or deviate from other Bugzilla instances.

Comment 2 Eric Blake 2014-07-21 12:53:46 UTC
(In reply to Jason McDonald from comment #1)
> (In reply to Eric Blake from comment #0)
> > https://bugzilla.redhat.com/attachment.cgi?id=918676
> >
> > What bug is this attached to? Bugzilla does not provide a backtrack from
> > an attachment to a bug report, infuriatingly.
> 
> Note that the attachment URL above is a direct pointer to the attachment
> data, which could be any type of file, so including a bug-link there is not
> possible without changing that URL into an html page with another link to
> the attachment data (and the back link to the bug).  That would be a
> significant API change which would break a number of client scripts.

I'm NOT asking that the attachment page itself change content, only that the URL to the page optionally allow additional information, and that all cases where bugzilla generates the URL to an attachment page, it generates the long URL.  That is, I'm proposing that:

https://bugzilla.redhat.com/attachment.cgi?id=918676

and

https://bugzilla.redhat.com/attachment.cgi?id=918676&bug=1120283

both redirect to the same attachment page, where the page itself does not change contents.

> 
> > Steps to Reproduce:
> > 1. click on the attachment of any bug
> > 2. using just that URL, try to get back to the bug
> 
> How common is the use-case? (Somebody pastes an attachment link somewhere
> without bothering to post the bug link alongside it.)

Common enough that it spawned a thread on the Fedora test list.  And seems simple enough to work around.

> 
> Can a little user education be applied to this situation?  

Which is easier - educating lots of users that they can manually append '&action=edit' to learn which bug owned an attachment, or generating long URLs that already include the bug number from the get-go?

> In any case, this is a request that ideally should go to the upstream
> Bugzilla project rather than Red Hat Bugzilla, as there's nothing Red Hat or
> Fedora-specific in the problem or the suggested solution (i.e. Fedora folks
> would also have the same problem with links to attachments in any other
> Bugzilla instance).
> 
> Therefore, I'd suggest submitting this request to
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla.  If accepted by
> the upstream project, Red Hat Bugzilla could inherit the upstream change
> without having to carry extra patches of our own or deviate from other
> Bugzilla instances.

Okay, I'll try that.

Comment 4 Jason McDonald 2014-07-22 01:05:01 UTC
(In reply to Eric Blake from comment #2)
> (In reply to Jason McDonald from comment #1)
> > (In reply to Eric Blake from comment #0)
> > > https://bugzilla.redhat.com/attachment.cgi?id=918676
> > >
> > > What bug is this attached to? Bugzilla does not provide a backtrack from
> > > an attachment to a bug report, infuriatingly.
> > 
> > Note that the attachment URL above is a direct pointer to the attachment
> > data, which could be any type of file, so including a bug-link there is not
> > possible without changing that URL into an html page with another link to
> > the attachment data (and the back link to the bug).  That would be a
> > significant API change which would break a number of client scripts.
> 
> I'm NOT asking that the attachment page itself change content, only that the
> URL to the page optionally allow additional information, and that all cases
> where bugzilla generates the URL to an attachment page, it generates the
> long URL.

Sure. I was just trying to explain the reason behind the lack of a backlink from attachments to bugs.

> > Can a little user education be applied to this situation?  
> 
> Which is easier - educating lots of users that they can manually append
> '&action=edit' to learn which bug owned an attachment, or generating long
> URLs that already include the bug number from the get-go?

I was thinking more along the lines of educating frequent Bugzilla users to avoid the problem by pasting links to bugs in preference to pasting links to attachments without context.  Occasional users might struggle to see why that's a good idea though.

(In reply to Eric Blake from comment #3)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1041508

That bug has been closed as a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=148562.


Note You need to log in before you can comment on or make changes to this bug.