Closed Bug 960772 Opened 10 years ago Closed 8 years ago

Revamp Kuma attachment system

Categories

(developer.mozilla.org Graveyard :: File attachments, defect)

All
Other
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sheppy, Unassigned)

References

Details

(Whiteboard: [specification][type:feature])

What problems would this solve?
===============================
Currently, attachments are very tricky to use on MDN for many reasons:

* There's no way to delete them
* They're not associated with the pages they're attached to
** You can't get a list of attachments for the page (just a list of files linked to by the page) from KumaScript
** You can't see a list of attachments to the page that haven't been expressly linked to from the content, which means if you attach a file then save the page, then go back to try to link to it, embed the image, or whatever, the file is "gone". This results in re-uploads most of the time.
* There's no way to re-use attachments unless you memorize the URL of the file; we need a lookup of existing attachments
* There's no way to upload files using an API, which is needed to fully support automated documentation tools
* There's no way to search for specific attachments that have already been uploaded; we have an all-files list, but it's paginated, very long, and has a great many duplicates
* We need a way to find duplicates so we can try to optimize these cases by getting rid of them when that's reasonable
* We need to be able to upload a new version of an attachment, so that new version is used in all the places the attachment is referenced across MDN, but the older version is available for historical reference

Who would use this?
===================
All MDN editors/contributors

What would users see?
=====================
A better experience for attachment uploading, inserting, and management.

What would users do? What would happen as a result?
===================================================
This UX needs to be designed.

Is there anything else we should know?
======================================
Depends on: 1026638
Shouldn't this issue be rather marked as duplicate of bug 1026638? Issues listed here and not already having a bug report for themselves, should be created and block 1026638.

Sebastian
Flags: needinfo?(eshepherd)
(In reply to Sebastian Zartner [:sebo] from comment #1)
> Shouldn't this issue be rather marked as duplicate of bug 1026638? Issues
> listed here and not already having a bug report for themselves, should be
> created and block 1026638.

Something like that. We need to consolidate the attachment system bugs and get them to all make sense, while making sure that all the points brought up in each get retained.
Flags: needinfo?(eshepherd)
Component: General → File attachments
In the triage meeting sheppy was tasked to make sure the points in comment 0 are taken care of in other bugs. Needinfo'ing sheppy to do that.
Flags: needinfo?(eshepherd)
These bugs are now filed and are blocking bug 766741.
Flags: needinfo?(eshepherd)
All issues listed in this bug have been filed as individual bugs (or were already filed). Closing this now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.