After T13603, referencing a file in Remarkup no longer automatically attaches it to the object where it is referenced. This breaks some workflows, and interacts with some existing behavior and code:
**Remove "getRemarkupBlocks()"**
Remarkup blocks are extracted from transactions with "newRemarkupChanges()", except that two callsites use the obsolete "getRemarkupBlocks()" pathway: one in Audit, one in CustomFields. These may both be difficult to get rid of.
**Remove Old Drafts**
"PhabricatorApplicationTransactionCommentView->setDraft()" has exactly two callers: one in Slowvote and one in Pholio. These are best removed by updating both applications to EditEngine, which is a complicated change. Some attachment behavior in both applications is broken until this is completed.
The Conpherence "Durable Column View" also uses old drafts. This could probably just be removed.
**Permanent Attachment Type**
If the UI gets explicit attachment management, it will become possible to detach "innate" files (like images in a Pholio version). This can break objects. These relationships should likely be marked "Permanent", e.g. "attached, and users can't detach them since they're fundamental to the object".
**What should API callers do?**
API callers can't currently provide an "attach" transaction and also can't provide Remarkup metadata. Do they need to be able to do one or the other?
----
//Done//
**Attachments not mentioned**
If you drag-and-drop a file into an object, then delete the reference from the text, we shouldn't attach the file (even though it will still be in the metadata attachment list).
**References in Quotes**
We should stop extracting file references from quoted blocks.