feat(ew): comments

[usman-khalid]

To be merged with adobe/da-nx#562

Summary

Collaborative comments for Experience Workspace.

Users can select text, an image or a table (block) and attach a comment. Each comment is stored as a .json file in .da/comments/{docId}/{commentId}.json

When a selection is made, a comment icon is also added to the toolbar in EW to initiate a thread.

Supports replies/threads, resolve/unresolve & orphan threads (user comments on something, the content is deleted while the comment is still active).

Comment data will survive if a page is moved to another folder.

Keyboard Shortcuts

• CMD+Option+M — if there is a selection, will start composing a new thread.
• CMD+Enter to submit a comment/reply

Read-Only Users

Read only users who should have access to comment only would need to be given write permissions to /{site}/.da/comments/ + ** in the DA config.

Layout Mode

Layout mode currently doesn't show a toolbar at all when a block is selected. The comment button should be made available there as part of the work done in SITES-46128

Blocks now have a toolbar since this PR was originally raised. This is now supported.

How Has This Been Tested?

• Unit tests
• localhost
• https://comments--da-live--adobe.aem.page/canvas?nx=ew-comments&quick-edit=ew-comments&da-admin=stage&da-collab=stage#/usman-khalid/stage-site-2/annotations

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
In case there are problems, just click the checkbox below to rerun the respective action.

• Re-sync branch

Commits

• 6a0de51 ✅ (latest)
• 880fdd9 ✅
• 40d7f0d ✅
• 8855363 ✅
• 14ee86c ✅

[sharanyavinod]

Thanks for your contribution and for your patience!
One architecture note: since you opened this PR, we've standardized how components talk to each other. Communication within the canvas itself now goes through a shared pub/sub bus, and communication that crosses from canvas into the panel has a standard eventing mechanism it should be going through consistently. Could you please update your PR to use these?

[usman-khalid]

Thanks for your contribution and for your patience! One architecture note: since you opened this PR, we've standardized how components talk to each other. Communication within the canvas itself now goes through a shared pub/sub bus, and communication that crosses from canvas into the panel has a standard eventing mechanism it should be going through consistently. Could you please update your PR to use these?

done. routed canvas stuff through canvasBus and canvas > panel through PANEL_EVENT

[sharanyavinod]

I think intersection observer might be slightly overkill here - tool-panel already knows which is the currently active panel. Couldnt we expose this so all who want to know which panel is active only refer to it?

[usman-khalid]

we don't show the comment markers in the canvas if the rail is closed entirely, which is what this is for. doing the above would cause the them to still be visible if a user had the comments panel open, then closed the right rail entirely.

[sharanyavinod]

There is already an event which is fired when the panel is closed. Couldn't we listen to that instead, and thus wouldn't a combination of this + what is the panel currently active cover this case without the need for an observer?