ether / ep_comments_page Goto Github PK

Due to EP security model

This should be on the right side of the screen if there is enough X PX

On the Etherpad instance we're using, we need another way to display comments. I don't know if it would be useful for ep_comments to have it incorporated to the code, or if we should implement it on a separated plugin (or a fork of this one). Let me know if you think this is something nice to have here, and I'll submit a PR.

Here are the details about it:

• Instead of displaying boxes on the right side of the screen, there would be icons on the right margin of the page:

  

• Comment details would be displayed only when I click on the icon:

  

• Clicking again on the icon would close comment details;

• Comments with replies would have a different icon (the actual icon I was thinking is this one, but I could not find it quickly on Etherpad, so I used the ones I found for this spike):

  

• When there are 2+ comments on the same line, each comment would have its own icon, side-by-side:

  

• One thing that we can do is create a toggle to allow user to choose whether to display comments as icons or as it is right now.

Let me know your thoughts.

Exporting a pad and following import to another pad haven't exported comments, just keeps yellow highlighting (possibly related to issue#79)

Problem: After installing the plugin files like main.css and jquery.tmpl.min.js could not be loaded.
Possible cause: The concerning etherpad instance does not run on a own domain, but on a subdomain.
Possible solution: After comparing the way ep_comments links the resources with the way other plugins (e.g. ep_page_view) do it, I noted that these other plugins went up a directory before like link href="../static/plugins/ep_page_view/static/css/page_view.css" rel="stylesheet whereas ep_comments does not do this: [/static/plugins/ep_comments_page/static/js/jquery.tmpl.min.js](script src="/static/plugins/ep_comments_page/static/js/jquery.tmpl.min.js"). Adding the ../ seems to work on a own domain as well as on a subdomain.

I can send a pull request implementing this.

The behaviour of the toolbar button should be improved.

When no text is selected

Current behaviour: Button as usual (enabled)
Best behaviour: Disabled

When text is selected

Current behaviour: Button as usual (enabled)
Best behaviour: Button as usual (enabled)

This behaviour could further be improved by having a floating button. See #95.

Actually I found out the delete button needs font awesome (which is not needed by Etherpad in general as it seems). Font awesome is saved under etherpad/static/font/fontawesome-etherpad.woff.

However the delete button was not shown.

But from having q quick look on your code you seem to use etherpad-lite to load font awesome, so I reported the issue there: ether/etherpad-lite#2963
So go on reading there if you're interested in this issue. (And please confirm that it must be fixed in etherpad-lite. If you can fix it, you're of course free to do it.)

The comment icon which can be activated via its appropriate function won't be shown and the comment field is being overlapped by the chat frame.

I have added the settings at the end of my settings.json. Highlighting works.

{ ...
  // Display comments as icons, not boxes
  "ep_comments_page": {
    "displayCommentAsIcon": true
  },
  // Highlight selected text when adding comment
  "ep_comments_page": {
    "highlightSelectedText": true
  }
}

EDIT: both "ep_page_view" and "ep_comments_page" were installed via npm install (no git clone involved)

EDIT2: Added pictures for clarification

Comments are key for collaboration - but inserting them can interrupt the flow of writing. Please define some specific signs, words between e.g. \ and \ are automatically formatted as comments and transferred to the side pane. It would of course be great if the characters that trigger the commenting of text could optionally be user-defined

It would be great if the comment button would only appear when text is selected.

So if the user selects some text a transparent version of the current button appears next to the selection. If the user hovers over this button it gets opaque and afterwards it just works as the current button.
When there is already a comment on a line the button could already become visible when hovering (not marking) the commented part, so that the user can instantly click on it and get to the reply box of the comment (so a click on the button, focuses this input field), type in the message and press enter to add a reply - without having to move the cursor to the right part of the screen.

This approach would have some advantages:

1. less need to move around the cursor around
2. intuitive
3. In the read-only mode the toolbar does not waste space as this is one of the few plugins, which have toolbar buttons in the read-only mode (so that there mostly is only one button in ro mode)

On https://medium.com you can e.g. find such a comment feature.

This is a feature suggestion, and I'll work on it. I just wanted to get some feedback before implementing it to make sure I'll address everything we need.

My suggestion is to create a route on the API to post a comment to a pad. So basically the steps would be:

• register a POST route /p/:pad/:rev?/add/comment/ (or should it be /p/:pad/:rev?/addComment/?)
• from there we call comments.addPadComment() -- similar to the code that is commented out on ep_comments/index.js
  • if err, should we return codes like the ones used on the Etherpad API? Something like { "code": 2, "message": "..." }?
  • if success, we return { "code": 0, "commentId": "c-12345" }
• finally, we need to tell the pad that the comment was created, so we broadcast 'pushAddComment' to the padId -- like what is done here. (I'm not sure how to do this step, but when I get to this point I'll see if I need some support here)

Is that it? Or do I need to do something else?

When I paste a text commented from another pad doesn't bring the whole comment just the text. It's shown the text with the background set to yellow.
Set the background to yellow makes the user confused but it seems to be easy to fix it just changing the comment class to something unique to the pad. IMHO copy the whole comment it'd be the expected behavior in this situation. Any idea how to solve it?

On windows7 64bit, build the latest version, after comments plugin installed, the comment input dialog is showed. But the comments of the pad dont display.
Steps:
1 build the latest version, install comment plugin ,open a pad
2 click the comment button, they comment input dialog shows
3 type something, click comment to submit
4 the dialog dispear, but the comment not display on the pad content

attachs:

Hi John!

Would you please publish the latest version of this plugin on npm?
We manage most of our dependencies this way and it would be awesome if we could use all of the improvements you and the other contributors made in the last 10 months without resorting to github pulls.

Thanks a bunch!
Cheers,
Milan

Hello @JohnMcLear, the french locales has been merged.

Could you publish a new version on npm please?

I cannot respond to my own comments. Since comments are not visible to others in my etherpad instance (see #1 ) I can't tell if this is a feature or a bug, but I think the possibility to respond to one's own comment is a desirable feature (cos it visually signals to others that there is a debate on that point, that various points are made, even if by the same person)

Content split with a line break loses comment hover.

If "displayCommentAsIcon" is being used I am not able to click URLs anymore.

Reproduceable (un)commenting "displayCommentAsIcon". Doesn't matter whether being used with "highlightSelectedText".

No error in log.

EDIT: packages installed: "ep_page_view" and "ep_comments_page". Removed everything else to avoid conflicting plugins

Hi @JohnMcLear , great plugin, please let the world know what license it's under!

Unfortunaltely the comments don't really work for me, they don't appear for other viewers, and in my test, other viewers couldn't even insert them into the same pad where I (and only I) could see my own comments. It should have no bearing, but maybe it's relevant that I was logged in as Admin in the same browser session.

1. Create two lines of text
2. attach a comment that is 3 or more lines long to the first line
3. attach a comment to the second line
   When done, the first comment continues below the second comment when the focus is on the second comment:
   

I think the interface would be cleaner if multi-line comments collapsed to a single line ending in an ellipsis (...) when not in focus (as they do in workflowy, for example)

I think comments is a bit b0rked when embedded.

As I see the German translation is included in the repo, but it is not used in my installation.
Plugin version: 0.0.33
Etherpad v1.6.0

In Firefox (v43) it also shows me this:

Could not find string ep_comments_page.time.minutes.past html10n.js:742:1
Couldn't find translation key ep_comments_page.delete_comment.title html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.from html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.suggested_change html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.accept_change.value html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.reply_input_label html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.include_suggestion html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.from html10n.js:831:1
Couldn't find translation key ep_comments_page.comments_template.to html10n.js:831:1
Couldn't find translation key ep_comments_page.delete_comment.title[...]

Several minor-to-medium usability problems. Non of them is likely to cause severe breakdowns, however they hinder flow and intuitive understanding

I would try to take on these myself, but maybe I oversaw some technical reasons for these, so I file them here in case they need to be discussed before:

1. Replies can be added by entering text in a textbox below current replies. It would be good to provide some context to the textbox to ease its usage – a label above stating Your Reply (hit ENTER to send) would make sense and it would fit the layout.
2. When suggesting a change, the currently selected text (the candidate for the change) is visible, labeled "From:" This is a great help for the user.
   A quirk here is that this text is placed in a textarea field. It is inactive (so it can’t be changed) but the control suggests that it could be changed (and is inactive because some mode is toggled). So some non-input element (a paragraph, styled differently than the interface’s lables) would conform to interfaces standards and is thus likely to be easily understood.
3. If "suggest change" is checked, the checkbox jumps to the bottom of the comments field, while the from and to textareas appear above. It would be visually more consistent and easier to uncheck the control again (after accidentally checking it) if the checkbox and its label would remain in place while the textareas appear below it. +1 if from/to and the checkbox are in a fieldset (or other wrapper) to connect them semantically as well as visually.

The comment button has no icon.
If I click it, nothing happens and the console gives:
[WARN] client - Uncaught TypeError: undefined is not a function -- { errorId: 'O5xQsna03qmTSGmiCTfd', msg: 'Uncaught TypeError: undefined is not a function', linenumber: 308,

How do you think? Could it be possible to comment in a read-only Pad?
They are stored to database, too

key:

comments:padID 

value:

"commentId":{ "author": data.author, "name": data.name, "text": data.text, "changeTo": data.changeTo, "changeFrom": data.changeFrom, "timestamp": new Date().getTime()}

(commentManager.js, line 62, right?)

But in

key:

pad:padId

there won't be the comment (commentId), so after reload the pad the comment won't be shown.
Is that the consciously behavior? Does anyone know a way / fix to save comments on read-only pads?

I am using the latest version (0.0.22) with etherpad 1.5.6. On one pad, I have one comment which can't be deleted. Clicking the "delete" button fires the message back to the server, and I don't receive any errors on the server, but the comment persists.

Any suggestions for debugging and/or manually removing the comment?

Reproduce: Just comment and reply yourself a few times. To make it longer you can also include suggestion.

What happens:

A scrollbar appears...

What should happen:
In long pads which already are longer than the screens height, this is not a problem, but for smaller documents it is annoying to always see a scrollbar when hovering over such a long comment.

So what should actually happen - at least for these small documents is: When hovering over the comment move the "window" up so it fits on the screen.
If the window really takes the full available height a scrollbar should appear inside of the comment. (So the user should be able to scroll through the comment without scrolling through the whole pad.)

Maybe this behaviour is also suitable for these long documents. (I nearly assume it is.)
But one should test whether it looks nicely and is user-friendly.

To reproduce:

1. click the button to add a comment;
2. click on Cancel, instead of creating the comment;
3. click the button to add a comment again;
4. the form will be opened with suggestion elements visible:

Seems to be an easy fix. I can work on it after I'm done with l10n, if you want.

IE user a(r/o user) wants to change "hello" to "hello world" - they should be able to suggest this change.

There is no submit or comment button when replying to comments. This is bad as it is no good UX to require the user to press enter.

E.g. this is the "workflow" when adding a suggestion (so not adding a actual comment) to a user who commented on a line:

1. Hover over the comment
2. Click on "Suggest changes"
3. Enter the suggestion
4. Click bad into the field for entering a comment (bad UX!, few users would know that they have to do this)
   (5. Read the title which says "Press enter")
5. Press enter.

That's not user-friendly.
Just showing a button "Add comment"/"Reply" or something similar would be much more straightforward for the user.

I was testing ep_comments on mobile devices (iPad and iPhone, for now) and noticed some functionalites were not working properly there (clicking to open/close the comment modal, adding comments, etc).

I'm planning to work on this, so wanted to know if anyone has any concerns about it. It seems that http://jquerymobile.com/ could help us, but to be honest I just gave a fast look on it.

Concerns about this? Or about using jQuery Mobile?

I'll work on a separated branch this time, to avoid conflicts if this takes too long to finish.

Comment modal is displaying part of the "suggested change" form.

To reproduce:

1. Check setting to "Show Comments";
2. On any comment, check "Include suggested change";
3. Uncheck setting to "Show Comments";
4. Display modal of the comment of step 2;

Expected:

Actual:

Note: simply adding .comment-modal form.comment-reply .reply-suggestion, to this code on comment.css

/* hide comment elements when displayed on modal, not on sidebar */
 .comment-modal .reply-comment-suggest,
 .comment-modal .comment-reply-input-label,
.comment-modal form.comment-reply .reply-suggestion,
 .comment-modal input,
 .comment-modal .comment-changeTo-approve{
   display:none;

does not work because we're using show()/hide() to display .reply-suggestion. So this needs a deeper investigation.

Hi
The plugin works fine with Chromium but not with Firefox. Firefox permits to create comment but they are not displayed.
Cheers.

Reproduce this:

1. Mark some text,
2. click "Add Comment"
3. interact with the comment Dialog, check "Include suggested change"
4. click cancel
5. repeat 1. and .2.

What should happen:

• The from/to fields should not be visible (works not)
• If "Include suggested change" is checked, "From" should contain the currently selected text.

What happens instead:

• Though the checkbox for "Include suggested change" is unchecked, the from/to fields are visible if they have been activated when calling the dialog previously.
• If "Include suggested change" is checked, "From" does not contain the currently selected text, but is blank

Use Case: I wrote a comment which is no longer needed or useful. I want to get rid of that comment.

Current Problems:

• Seemingly the whole text on which I commented needs to be removed to remove the comment as well.
• As a user, I may be unaware of the possibility to remove the text to remove the comment

Solution

• Like in (probably) familiar office suites, the comment fields can have a "delete" or "x" button to delete them: (Mockup)
  
• Comments could as well be inserted at the end of the text commented on, like an invisible character, which can be deleted. This is how Open Office Writer does it. However, I assume this is far more difficult to implement than the button mentioned above.

(The yellow ▲ is like a character that can be deleted – and with it the comment)

tl;dr
When ep_etherpad-lite/static is loaded before ep_comments_page, API POST routes return 405: Only the HEAD or GET methods are allowed. Apparently just adding this hook on ep.json fixes the issue:

"post": ["ep_etherpad-lite/static"],

Long story:

I've noticed that sometimes the POST routes on the API were returning 405: Only the HEAD or GET methods are allowed. As it was kind of a random behaviour, my guessing was that it might be related to the order things were being loaded (other plugins, Etherpad hooks, etc). So I got the logs from a successful and a failing running of Etherpad:

This makes POST route work:

[2015-05-20 10:31:03.245] [DEBUG] console - Installed parts:
ep_script_page_view/page_view
ep_disable_lists/ep_disable_lists
ep_font_color/main
ep_script_elements/main
ep_adminpads/ep_adminpads
ep_etherpad-lite/swagger
ep_etherpad-lite/adminsettings
ep_etherpad-lite/adminplugins
ep_etherpad-lite/admin
ep_etherpad-lite/tests
ep_etherpad-lite/socketio
ep_etherpad-lite/errorhandling
ep_etherpad-lite/importexport
ep_etherpad-lite/apicalls
ep_etherpad-lite/webaccess
ep_comments_page/comments_page
ep_etherpad-lite/padreadonly
ep_etherpad-lite/padurlsanitize
ep_etherpad-lite/specialpages
ep_etherpad-lite/i18n
ep_etherpad-lite/static
ep_etherpad-lite/express

This makes POST route return 405:

[2015-05-20 10:30:14.873] [DEBUG] console - Installed parts:
ep_script_page_view/page_view
ep_script_elements/main
ep_font_color/main
ep_etherpad-lite/swagger
ep_etherpad-lite/adminsettings
ep_etherpad-lite/adminplugins
ep_etherpad-lite/admin
ep_etherpad-lite/tests
ep_etherpad-lite/socketio
ep_etherpad-lite/errorhandling
ep_etherpad-lite/importexport
ep_etherpad-lite/apicalls
ep_etherpad-lite/padreadonly
ep_etherpad-lite/padurlsanitize
ep_etherpad-lite/specialpages
ep_etherpad-lite/i18n
ep_etherpad-lite/static
ep_etherpad-lite/express
ep_disable_lists/ep_disable_lists
ep_etherpad-lite/webaccess
ep_comments_page/comments_page
ep_adminpads/ep_adminpads

So my test was basically to get each of the 6 hooks that were called after ep_comments on the successful running (ep_etherpad-lite/padreadonly, ep_etherpad-lite/padurlsanitize, ep_etherpad-lite/specialpages, ep_etherpad-lite/i18n, ep_etherpad-lite/static, ep_etherpad-lite/express) and force them to be a post hook for the plugin.

Apparently the hook that is making the routes fail is ep_etherpad-lite/static, so to validate that I've tested ep_comments_page with 2 configurations on ep.json:

• forcing static to be loaded before, and all other candidate hooks after:

      "pre": ["ep_etherpad-lite/webaccess", "ep_etherpad-lite/static"],
      "post": ["ep_etherpad-lite/padreadonly", "ep_etherpad-lite/padurlsanitize", "ep_etherpad-lite/specialpages", "ep_etherpad-lite/i18n", "ep_etherpad-lite/express"],
  

• forcing static to be the only hook loaded after:

      "pre": ["ep_etherpad-lite/webaccess", "ep_etherpad-lite/padreadonly", "ep_etherpad-lite/padurlsanitize", "ep_etherpad-lite/specialpages", "ep_etherpad-lite/i18n", "ep_etherpad-lite/express"],
      "post": ["ep_etherpad-lite/static"],
  

And, as expected, the first configuration returned consistently 405, and the second one worked fine.

So it seems that just adding this to ep.json would fix the issue:

"post": ["ep_etherpad-lite/static"],

Note: this is the curl command I was using:

curl -X POST http://localhost:9001/p/LFP/comments -d "apikey=yourApiKey" -d "name=Author" -d "text=Comment"

I'm not exactly sure why that is happening, I could just figure out a way to fix it. Any other ideas?

I'll submit a PR with the fix above if you agree with the solution.

I tested this on the last dev version and beta.etherpad.org, on windows 7 chrome 39, ie 11, firefox 35.
Steps:
1 open two client(client-A,client-B) for the same pad pad-n
2 input n comments at client-A
3 client-B show n-1comments on the pad
4 input n+m comments at client-A
5 client-b show n+m-1 comments on the pad

Review this code:

this.pushComment('add', function (commentId, comment){
self.setComment(commentId, comment);
// console.log('pushComment', comment);
window.setTimeout(function() {
self.collectComments();
}, 300);
});

This function will fail to add new comment in self.collectComments() if the pad costs more than 300 ms to update the pad content what comment on.
I will commit a pull reqeust to fix it temp (try to update 3 more times if neccessary):

this.pushComment('add', function (commentId, comment){
    self.setComment(commentId, comment);
    // console.log('pushComment', comment);
    window.setTimeout(function() {
      self.collectComments();
            var count_comments=0;
      for(var key in self.comments)  {count_comments++;}
      var padComment  = this.padInner.contents().find('.comment');
      if( count_comments > padComment.length ) {
         window.setTimeout(function() {
            self.collectComments();
            var count_comments=0;
            for(var key in self.comments)  {count_comments++;}
            var padComment  = this.padInner.contents().find('.comment');
            if( count_comments > padComment.length ) {
               window.setTimeout(function() {
                  self.collectComments();
                  var count_comments=0;
                  for(var key in self.comments)  {count_comments++;}
                  var padComment  = this.padInner.contents().find('.comment');
                  if( count_comments > padComment.length ) {
                     window.setTimeout(function() {
                        self.collectComments();

                      }, 9000);
                  }
                }, 3000);
            }
          }, 1000);
      }
    }, 300);
  });