Tabs don't work on bug attachment page

[Matthew Paul Thomas]

A bug attachment page, such as <https://bugs.launchpad.net/ubuntu/+source/wmaker/+bug/174252/attachments/188403>, has seven tabs: "Overview", "Code", "Bugs", "Bugs", "Blueprints", "Translations", and "Answers". One of the "Bugs" tabs is clickable, but none of the other tabs are.

The tabs should be clickable exactly as they are on <https://bugs.launchpad.net/ubuntu/+source/wmaker/+bug/174252>.

[Curtis Hovey (sinzui)]

This problem looks like we need to create and register an adapter for attachments. The IPrimaryContext for Attachments should be launchbag.bugtask.target.

[Diogo Matsubara (matsubara)]

Hi Gavin,

the same behaviour appear in bug watches pages. See bug 314898 which I duplicated against this one.

Please when you fix the attachment page, please also fix the bug watches page.

Thanks.

[Gavin Panella (allenap)]

[ This comment has become a bit of a brain dump, sorry. ]

From the description:

> The tabs should be clickable exactly as they are on
> <https://bugs.launchpad.net/ubuntu/+source/wmaker/+bug/174252>.

Both bug attachments and bug watches are associated with the bug, not
any particular bugtask. Viewing bugs and their dependents in the
context of one particular task is confusing and misleading, especially
when there are multiple tasks.

Currently, bug watches are found at:

  /bugs/<bug-id>/+watch/<id>

So I think bug attachments should be found at:

  /bugs/<bug-id>/+attachment/<id>

In fact, they can *already* be found at:

  /bugs/<bug-id>/attachments/<id>

Which is their canonical URL.

However, from a bug page they are currently linked to at:

  /<context>/+bug/<bug-id>/attachments/<id>

...

But, when an attachment is viewed only in the context of the bug - as
proposed above - and not a project or whatever, there are no active
tabs, because they don't make sense. We are forced to choose a bugtask
before we can make a decision about which tabs to activate.

However, I don't think we should. I think that no active tabs makes
sense for bug attachments and bug watches. Being forced into a bugtask
context was, I think, a big barrier to understanding Launchpad for me.

...

In BugNavigation there is a comment suggesting that, because we don't
have a per-bug sequence for bug watches, we should perhaps just put
them at:

  /bugwatches/<id>

Which makes some sense, but is ugly. The id is the database ID and
means little. For bug watches we could (and perhaps should) have their
canonical URL be something like:

  /bugs/<bug-id>/+watch/<bugtracker-name>/<remote-bug-id>

(The remote bug id might need to be sanitised.)

I'm pretty sure that would be unique, though not permanent because
both the bug tracker name (e.g. "gnome-bugs") and the remote bug id
are editable by users.

There is nothing similar we can do for bug attachments though, without
adding new naming or numbering machinery.

[Matthew Paul Thomas (mpt)]

It's true that bug attachments and watches are associated with the bug report rather than with any bugtask. But the same applies to bug privacy, security, subscriptions, duplicate markings, related branches, CVEs, and comments. Nevertheless, all the secondary pages relating to those things preserve the navigation of the project/package context you're in. This maintains visual stability between pages, and is consistent with the navigation those operations will have once you are able to do them with fancy popups in the bug report page itself.

In that respect, I don't think bug attachments are any different from privacy, security, subscriptions, duplicate markings, related branches, CVEs, or comments. Nor are watches (at least as long as it's possible to have context-free watches). I shouldn't have one set of navigation while modifying an attachment or watch, and another set of navigation while doing anything else related to the bug report.

If fixing this for bug watches is trickier than for attachments (because attachment editing already has the context in its URL while watches do not), perhaps they should be tackled separately, so bug 314898 should be detached from this one?

[Gavin Panella (allenap)]

Yeah, I guess I agree with you mpt :)

I'll do bug watches and attachments together; the fix is very similar.

[Gavin Panella (allenap)]

Fix for bug attachment pages is in trunk, r7657.

Work for the bug watch pages overran a little, so I've filed bug 320755 to track that.

[Matthew Paul Thomas (mpt)]

Sweet! Thanks Gavin.