Bug 1020377 - Poorly worded error message when attempting to attach a file that is too large
Poorly worded error message when attempting to attach a file that is too large
Status: CLOSED UPSTREAM
Product: Bugzilla
Classification: Community
Component: Attachments/Requests (Show other bugs)
4.4
Unspecified Unspecified
low Severity low (vote)
: ---
: ---
Assigned To: PnT DevOps Devs
tools-bugs
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-17 10:38 EDT by Larry O'Leary
Modified: 2013-12-11 01:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-11 01:04:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 947766 None None None Never

  None (edit)
Description Larry O'Leary 2013-10-17 10:38:23 EDT
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 17:52:08 EST
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 09:35:39 EST
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 01:28:59 EST
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 01:04:51 EST
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.