Closed Bug 98147 Opened 18 years ago Closed 16 years ago

The 'ViewAll attachments' link should be greyed out if there are none

Categories

(Bugzilla :: Attachments & Requests, defect, P3, minor)

2.15

Tracking

()

RESOLVED FIXED
Bugzilla 2.18

People

(Reporter: bugzilla, Assigned: goobix)

Details

Attachments

(1 file, 3 obsolete files)

The 'ViewAll' link in the new attachments table should be unavailable if there
are no links.

And/Or if you click on it, and there are no attachments, then the

http://bugzilla.mozilla.org/attachment.cgi?bugid=98074&action=viewall

page should say 'there are no attachments to view', otherwise, you get a page
that is potentially confusing, which says it is 'Viewing All Attachments', but
there aren't actually any there.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
Component: Creating/Changing Bugs → attachment and request management
Tested on my local Bugzilla installation and it works like expected.
Attachment #127922 - Flags: review?(kiko)
Attachment #127922 - Attachment is obsolete: true
Attachment #127923 - Flags: review?(kiko)
Attachment #127923 - Attachment is obsolete: true
Attachment #127922 - Flags: review?(kiko) → review-
Attachment #127923 - Flags: review?(kiko) → review-
Attachment #127924 - Flags: review?(kiko)
Comment on attachment 127924 [details] [diff] [review]
Removed != 0 condition compared to previous versions.

r=kiko, nice work
Attachment #127924 - Flags: review?(kiko) → review+
<-- me
Assignee: myk → jocuri
Flags: approval?
Status: NEW → ASSIGNED
I'm going to let Myk make the approval call on this one since it's a UI issue
Thanks for the patch.  The coloring should be done with CSS rather than the font
tag, but that's not a tragedy.  The idea itself is a good one.  a=myk
Flags: approval? → approval+
Err, sorry, I was looking at an earlier patch.  Actually, I like the greying
effect; it's standard for indicating that UI controls are disabled, so a patch
that did that (via CSS) would be ideal if you have time for it (otherwise check
this one in; I maintain my a=myk).
This should be ready for checkin then.
Attachment #127924 - Attachment is obsolete: true
Comment on attachment 128012 [details] [diff] [review]
New version per myk's suggestions.

Setting kiko's r+ from the previous one.
Attachment #128012 - Flags: review+
Kiko needs to explicitly say that his r= can be migrated to the newer
attachment, but I've reviewed it, and it looks good, so the r= can stand, as
does my a=.  Go ahead and check it in if you have access, or I'll check it in if
you don't.
I don't have access, so a checkin on this would be appreciated.

Thanks for letting me know about the r+ transition policy.
Checking in css/edit_bug.css;
/cvsroot/mozilla/webtools/bugzilla/css/edit_bug.css,v  <--  edit_bug.css
new revision: 1.3; previous revision: 1.2
done
Checking in template/en/default/attachment/list.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/attachment/list.html.tmpl,v
 <--  list.html.tmpl
new revision: 1.9; previous revision: 1.8
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
For the record, I did say on IRC that he could carry over my r=.
I really don't know how that TAB got there. It's the 2nd time this is happening.

I'm used with TAB environments, but I really fail to see how I could have pushed
that key, especially after the line ended. Oh well, I'll switch completely to
vim then, since it has support for auto-expanding TABs.

Really sorry about it. :(
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.