960772 - Revamp Kuma attachment system

Status: RESOLVED FIXED

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

Description

[Eric Shepherd [:sheppy]]

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?
======================================

Comment 1

[Sebastian Zartner [:sebo]]

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

Comment 2

[Eric Shepherd [:sheppy]]

(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.

Comment 3

[Florian Scholz (Open Web Docs)]

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.

Comment 4

[Eric Shepherd [:sheppy]]

These bugs are now filed and are blocking bug 766741.

Comment 5

[Eric Shepherd [:sheppy]]

All issues listed in this bug have been filed as individual bugs (or were already filed). Closing this now.