Page MenuHomePhorge

Add and use new RemarkupMetadata class
ClosedPublic

Authored by Dylsss on Sep 18 2022, 16:59.
Referenced Files
F357868: D25052.id270.diff
Mon, Sep 25, 03:35
Unknown Object (File)
Sun, Sep 24, 05:05
Unknown Object (File)
Thu, Sep 21, 20:57
Unknown Object (File)
Wed, Sep 20, 23:37
Unknown Object (File)
Fri, Sep 15, 05:58
Unknown Object (File)
Tue, Sep 12, 09:17
Unknown Object (File)
Tue, Sep 12, 02:03
Unknown Object (File)
Sun, Sep 10, 09:41

Details

Summary

Add a new RemarkupMetadata class and use with upload button as well as drag and drop pathways.

With this change, files are now attached automatically to the object. This this could solve
several issues, for example when a person uploads a file but only that author is able to see it.

Ref T15106

Test Plan
  • Drag and drop file, upload file with button. Check that both files are attached with "attachedFilePHIDs" values.
    • drop file in a Task description (now works)
    • drop file in a Task comment (now works)
    • drop file in an edited Task comment (still not supported)
  • This was already tested in Wikimedia Foundation: https://phabricator.wikimedia.org/D1203

Diff Detail

Repository
rP Phorge
Branch
master
Lint
Lint Warnings
SeverityLocationCodeMessage
Warningwebroot/rsrc/js/core/RemarkupMetadata.js:1JAVELIN5`javelinsymbols` Not In Path
Unit
Tests Passed
Build Status
Buildable 86
Build 86: arc lint + arc unit

Event Timeline

Dylsss requested review of this revision.Sep 18 2022, 16:59

Differentiate between metadata of different text areas using node ID. e.g., new comment text areas and text areas in the edit comment dialog.

Bear with me here, because Javeline (like all js frameworks) is confusing to me.

I'd expect some PHP code to actually attach the files from attachedFilePHIDs to the relevant object, but I don't see it in this diff. Is that already happening somehow?

webroot/rsrc/js/core/behavior-phabricator-remarkup-assist.js
260–264

is metadata gets automatically inserted into something? I don't see it being manually saved.

In D25052#1750, @avivey wrote:

I'd expect some PHP code to actually attach the files from attachedFilePHIDs to the relevant object, but I don't see it in this diff. Is that already happening somehow?

It's done here: https://we.phorge.it/source/phorge/browse/master/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php;5aa159a83013fca3a72f5c6d2c493c117fbbf83b$2296

webroot/rsrc/js/core/behavior-phabricator-remarkup-assist.js
260–264

It gets written to the HTML element in the setMetadata method.

This revision is now accepted and ready to land.Oct 28 2022, 10:19
Matthew requested changes to this revision.Dec 8 2022, 22:37

Please rebase and resubmit, there is a merge conflict.

matthew@Tower phorge % arc patch D25052
Created and checked out branch arcpatch-D25052.
Checking patch webroot/rsrc/js/core/behavior-phabricator-remarkup-assist.js...
Checking patch webroot/rsrc/js/core/behavior-drag-and-drop-textarea.js...
Checking patch webroot/rsrc/js/core/RemarkupMetadata.js...
Checking patch src/view/form/control/PhabricatorRemarkupControl.php...
Checking patch resources/celerity/map.php...
Applied patch webroot/rsrc/js/core/behavior-phabricator-remarkup-assist.js cleanly.
Applied patch webroot/rsrc/js/core/behavior-drag-and-drop-textarea.js cleanly.
Applied patch webroot/rsrc/js/core/RemarkupMetadata.js cleanly.
Applied patch src/view/form/control/PhabricatorRemarkupControl.php cleanly.
Applied patch resources/celerity/map.php cleanly.
 COMMITTED  Successfully committed patch.
matthew@Tower phorge % arc land
 STRATEGY  Merging with "squash" strategy, the default strategy.
 SOURCE  Landing the current branch, "arcpatch-D25052".
 ONTO REMOTE  Landing onto remote "origin", the default remote under Git.
 ONTO TARGET  Landing onto target "master", the default target under Git.
 INTO REMOTE  Will merge into remote "origin" by default, because this is the remote the change is landing onto.
 INTO TARGET  Will merge into target "master" by default, because this is the "onto" target.
 FETCH  Fetching "master" from remote "origin"...

  $   git fetch --no-tags --quiet -- origin master


 INTO COMMIT  Preparing merge into "master" from remote "origin", at commit "dc558b5538cd".
 LANDING  These changes will land:

  *   D25052 Add and use new RemarkupMetadata class
          27935e60780f  Add and use new RemarkupMetadata class

 >>>  Land these changes? [y/N/?] y

 <!> NOT REVISION AUTHOR 
You are landing revisions which you ("@Matthew") are not the author of:

  *   D25052 Add and use new RemarkupMetadata class
        Author: @Dylsss

  ?   Use "Commandeer" in the web interface to become the author of a
      revision.

 >>>  Land revisions you are not the author of? [y/N/?] y
 <!> BUILD FAILURES 
1 revision(s) have build failures:

  *   D25052 Add and use new RemarkupMetadata class
  *     B87 Buildable "B87"
 ://      https://we.phorge.it/B87
  *       Build 87 arc lint + arc unit


 >>>  Land 1 revision(s) anyway, despite failed builds? [y/N/?] y
 MERGING  27935e60780f Add and use new RemarkupMetadata class
 MERGE  Attempting to rebase changes.
 MERGE  Attempting to reduce and rebase changes.

 <!> MERGE CONFLICT 
Local commit "27935e60780f" ("arcpatch-D25052") does not merge cleanly into
"dc558b5538cd". Rebase or merge local changes so they can merge cleanly.

 LOAD STATE  Restoring local state (to ref "arcpatch-D25052" at commit "27935e60780f").
 USAGE EXCEPTION  Encountered a merge conflict.
This revision now requires changes to proceed.Dec 8 2022, 22:37

Rebased on master, ran bin/celerity map to resolve merge conflict.

For some historical context, this current patch comes from another one from the Phabricator of Wikimedia Foundation:

https://phabricator.wikimedia.org/D1203

webroot/rsrc/js/core/RemarkupMetadata.js
13–18

Thanks. In short, this is the proposed change. Taking this:

if (JX.RemarkupMetadata._metadataValue == null) {
  JX.RemarkupMetadata._metadataValue = [];
  JX.RemarkupMetadata._metadataValue[metadataID] = metadataValue;
} else if (!JX.RemarkupMetadata._metadataValue.hasOwnProperty(metadataID)) {
  JX.RemarkupMetadata._metadataValue[metadataID] = metadataValue;
}

And simplifying it to this:

if (JX.RemarkupMetadata._metadataValue == null) {
  JX.RemarkupMetadata._metadataValue = {};
}
if (!JX.RemarkupMetadata._metadataValue.hasOwnProperty(metadataID)) {
  JX.RemarkupMetadata._metadataValue[metadataID] = metadataValue;
}

Reasons:

  1. I suggest to have myVar = {} instead of myVar = [] (so, explicitly declaring an object, instead of an array-object) since using a JavaScript array-object for an "associative map" is a little understood hack, and the risk here is that a person with experience in PHP misunderstand what is going on in JavaScript, and he/she can goes crazy when he/she finds out that things like .length are completely broken on the array, since we are not really working with an array, we are really not adding elements to an array, etc. Here we need an "associative array", and since in JavaScript an array is really an object, and since the syntax myVar['foo']=value just does myVar.foo=value on an object, and since hasOwnProperty() is just inherited from the generical object class, I suggest to just declare it as any normal object. I'm sincerely sorry if JavaScript is so weird. If you have a doubt, think about JSON: an "associative array" is just an object {}, while arrays are only used to represent a stack of consecutive elements.
  2. I also suggest to avoid the base case optimization, essentially because it does not justify the loss of readability. It also avoids the introduction of future typos since we don't repeat the same instruction twice.
valerio.bozzolan added inline comments.
webroot/rsrc/js/core/RemarkupMetadata.js
13–18

Hi @Dylsss do you agree with the inline comments here?

You can also say "Yeah I don't care" ihih and I will amend that for you, no problem

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

Using the upload button has different behaviour to drag&drop - files uploaded using the upload button need to be manually attached to the object which is a bit of a faff (not sure if there's a way to automatically do this?):

image.png (241×558 px, 24 KB)

This revision is now accepted and ready to land.Apr 20 2023, 15:58
In D25052#4020, @MCPCN wrote:

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

Using the upload button has different behaviour to drag&drop - files uploaded using the upload button need to be manually attached to the object which is a bit of a faff (not sure if there's a way to automatically do this?):

image.png (241×558 px, 24 KB)

Thanks. Since it seems to me that you are not a bot (or you are a bot with good intentions! ihih) now you are marked as Trusted Contributors 🎉 This amazing power allows you to create new Tasks. If you want, feel free to describe such specific additional corner case, opening such Task under Remarkup (and please put myself in Subscribers since your report also affects me and it's interesting to me)

Amazing @Dylsss you have green light here. Feel free to land.

Although I would like to talk about those little inline comments from me :D Thank you for your opinion

WARNING: After this change, in my JavaScript console I can see this exception: Error: JX.DOM.scry(<yuck>, ...): first argument must be a DOM node. - I do not understand a shit about Javelin so I really don't know what does it mean
In D25052#4020, @MCPCN wrote:

I'm the author of Q49 - just confirmed that this patch appears to work in our environment (latest release of Phabricator) - files uploaded to Maniphest tasks are accessible to others.

Can I ask you if you see any error in your browser console, after that patch?

WARNING: After this change, in my JavaScript console I can see this exception: Error: JX.DOM.scry(<yuck>, ...): first argument must be a DOM node. - I do not understand a shit about Javelin so I really don't know what does it mean

I reverted to a previous commit (36dba82224de1b64bf571ebae5e944ce8a02e7c2) and still get this error when uploading from the remarkup toolbar upload button. So I don't think it is related to this change.

In D25052#4102, @Dylsss wrote:

I reverted to a previous commit (36dba82224de1b64bf571ebae5e944ce8a02e7c2) and still get this error when uploading from the remarkup toolbar upload button. So I don't think it is related to this change.

D25076 fixed this issue, this issue shouldn't exist when this patch is merged, but I'll rebase against master anyway. I'll also apply the suggested changes.

Rebased and applied suggested changes

Dylsss marked 3 inline comments as done.Apr 24 2023, 00:28
This revision was landed with ongoing or failed builds.Apr 24 2023, 01:53
This revision was automatically updated to reflect the committed changes.

(Ignored unrelated build failures, see fix: D25133)