Bug 1020377 - Poorly worded error message when attempting to attach a file that is too large
Summary: Poorly worded error message when attempting to attach a file that is too large
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Bugzilla
Classification: Community
Component: Attachments/Requests
Version: 4.4
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
Assignee: PnT DevOps Devs
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-17 14:38 UTC by Larry O'Leary
Modified: 2013-12-11 06:04 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-11 06:04:51 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 947766 0 None None None Never

Description Larry O'Leary 2013-10-17 14:38:23 UTC
Description of problem:
When attaching a file that exceeds the maximum attachment size the error message indicates that the file can be uploaded elsewhere and attached using the URL field. In the past, this "URL" field was in the attachment screen itself and showed up under the Attachments section. However, this field is no longer available. 

In other words, there is no way to specify a URL as an attachment.

The error message I am referring to is:

> The file you are trying to attach is 51200 kilobytes (KB) in size. Attachments cannot be more than 20000 KB.
> We recommend that you store your attachment elsewhere and then paste the URL to this file on the attachment creation page in the appropriate text field.
> Alternately, if your attachment is an image, you could convert it to a compressible format like JPG or PNG and try again.

Comment 1 Simon Green 2013-11-03 22:52:08 UTC
The URL can be specified on the main bug page. That is the correct place to enter it. If it was available on the add attachment page, it could lead to confusion.

  -- simon

Comment 2 Larry O'Leary 2013-11-04 14:35:39 UTC
Perhaps you missed the real point of this BZ. The field is missing yet BZ tells you to go to the file attachment page to use it. This is where it always has been and based on the message, I would assume that is where it should be.

Additionally, I am not sure how one could confuse attaching a file as a URL and linking a BZ to a URL? Those are two different things. 

None the less, this is still a bug so I am re-opening.

Comment 3 Jason McDonald 2013-11-27 06:28:59 UTC
I think this is just a case of a poorly worded error message, which I'm happy for us to correct.

I can't find any evidence that there has ever been a URL field on the attachment page in Bugzilla, nor that there has ever been a URL field in the attachments table in the Bugzilla database schema.  Indeed, the weekly sanity check script would complain about any attachment that has metadata but doesn't have attachment content data in the database.

For reference, the current schema for the attachments table is shown below:

mysql> DESCRIBE bugs.attachments;
+-------------------+--------------+------+-----+---------+----------------+
| Field             | Type         | Null | Key | Default | Extra          |
+-------------------+--------------+------+-----+---------+----------------+
| attach_id         | mediumint(9) | NO   | PRI | NULL    | auto_increment |   
| bug_id            | mediumint(9) | NO   | MUL | NULL    |                |   
| creation_ts       | datetime     | NO   | MUL | NULL    |                |
| description       | tinytext     | NO   |     | NULL    |                |
| mimetype          | tinytext     | NO   |     | NULL    |                |
| ispatch           | tinyint(4)   | NO   |     | 0       |                |
| filename          | varchar(255) | NO   |     | NULL    |                |
| submitter_id      | mediumint(9) | NO   | MUL | NULL    |                |
| isobsolete        | tinyint(4)   | NO   |     | 0       |                |
| isprivate         | tinyint(4)   | NO   |     | 0       |                |
| it_id             | tinyint(4)   | YES  |     | NULL    |                |
| modification_time | datetime     | NO   | MUL | NULL    |                |
+-------------------+--------------+------+-----+---------+----------------+
12 rows in set (0.00 sec)

Comment 6 Simon Green 2013-12-11 06:04:51 UTC
Upstream have approved this for version 4.4, so we will inherit the change that way as part of Bugzilla 4.4.1013.

  -- simon


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