Change Details

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". **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. **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?

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.

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. **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?