Closed Bug 330986 Opened 20 years ago Closed 16 years ago

Standardize confusing "local/big file" storage term for attachments

Categories

(Bugzilla :: Attachments & Requests, defect)

Product:
Bugzilla
Component:
Attachments & Requests
Version:
2.20.1
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 4.2

People

(Reporter: timeless, Assigned: LpSolit)

References

Details

(Whiteboard: [fixed by blocker])

[% ELSIF error == "local_file_too_large" %] [% title = "Local File Too Large" %] Local file uploads must not exceed [% Param('maxlocalattachment') %] MB in size. If we're actually using "local file" in our ui, then we'll need to fix this globally, but either way. local file can't possibly be explained or meaningful to users.
Users actually sometimes get to choose whether or not an attachment is stored locally, so they know what's going on. However, there are configurations where that's not the case.
OS: MacOS X → All
Hardware: Macintosh → All
Summary: local_file_too_large doesn't make sense → Saying anything to users about "local file" storage for attachments is confusing
Looks like new attachment UI refers this as attaching a big file. Confusing.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Saying anything to users about "local file" storage for attachments is confusing → Standardize confusing "local/big file" storage term for attachments
Depends on: 490930
Assignee: attach-and-request → LpSolit
We no longer talk about "big files" or "local files" to users. This is done automatically in the background.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by blocker]
Target Milestone: --- → Bugzilla 4.2
You need to log in before you can comment on or make changes to this bug.