Repository navigation
Missing pieces: user mentions in Comments #2443
Description
With 11 we put the cornerstones for user mentioning in comments (cf. #753). It's not end user friendly yet, though. For Nc 12 we have left to accomplish:
-
When writing or editing a comment and typing an @ in the beginning of a word followed by another character an auto-complete is offered. It only includes users that have access to the file. Results are supposed to show up with a slight delay. For scaling reasons, it needs to be figured out whether all possible users are fetched in the background in advance, or on demand (like search dialog). done in 13
-
Usernames are somehow allowed to contain whitespaces. They are currently not supported by our regex syntax. To be truly compatible we need to change the underlying markup and, for instance, wrap the mention into
[ ]brackets (see below). Changes needs to be reflected into clients so they render properly (comments UI in sidebar, notifications, activites, …) -
upon click on a comment notification, currently only the corresponding page within Files is being opened. Additionally, the sidebar should be opened with the Comments section active. The new comment should be highlighted, also.
Not fully supported username examples
"Let's talk about it today, @foobar."
Since we allow dots, @foobar and @foobar. are possible scenarios here. If you have both? Would be silly to insert a space between the username and the fullstop.
But even better it is that we allow white spaces in usernames now:
"@alice Bernadette wants to talk"
Username can be '@Alice Bernadette'or'@Alice'(or both).
For now, I improve the Regexp to have the 98% solution, butt when going with autocomplete I am afraid we need to wrap the mention into brackets to be able to support all these funny usernames.
Nice to have
- subscription system (not further specified yet)
Update Jul 12th and again on Jul 14th
Implementation specs
Overview
- JavaScript GUI Tool: OC.AutoComplete.GUI
- fetches AutoComplete options once! (automatically, when opening Comments tab)
- filters options client-side
- inserts, following a consumer-defined template, e.g.
[@$id]for comments - block-removes inserted mentions on backspace/delete
- uses At.js for the actual presentation and interaction parts (best candiate after research, did not prototype yet)
- API endpoint: /autocomplete/get/
- Controller in core
- gets users from sharees endpoint
- Parameters
- optional {itemType} being the thing you look users for, e.g. a file (→ file comments obviously)
- optional {itemId} the corresponding identifier (requires itemType, throws Exception if missing)
- optional {sorter} parameter to request a Sorter (default: $sorter = null → none)
- returns sorted array with resulting objects, as assoc array with
id,labelandsourceas keys
- ServerAPI: AutoCompleteManager
- offers to register a Sorter, e.g. prioritizing who where commenting on the file already. (Might come as a second step, but Controller implementation should have this extension in mind)
Activity
foobar commentedon Dec 2, 2016
😅
jancborchardt commentedon Dec 8, 2016
Hahaha @foobar :D welcome
@blizzz two things:
Let's push this because without autocompletion the feature is basically not really discoverable.
blizzz commentedon Dec 8, 2016
Basically I'd follow what sharing is doing. The typed string is passed to the user backends, and what they are looking at is their business. Local ones do username and display name i believe.
Reasonable to do so, I agree.
And shouldn't be, I guess, it's more groundwork right now. Though it works if you know how to mention whom ;)
jancborchardt commentedon Feb 21, 2017
@blizzz any progress here or something to review?
blizzz commentedon Mar 7, 2017
nope, i've other prios so far unfortunately
jancborchardt commentedon Apr 30, 2017
One other thing:
We should already offer the autocomplete as soon as the @ is typed. It should prioritize showing them in this order:
blizzz commentedon Jul 12, 2017
Those who cannot access it, should not be shown at all. Or, otherwise, showing them (then of course only those that potentially can get access) and eventually mentioning them would also include creating a share.
Basically like above, but it would end up as federated or mail share. Thus, also only offering those we potentially can get access.
blizzz commentedon Jul 12, 2017
I added the Implementation specs part into the description and would follow this scheme. This should allow auto completion not only for File Comments, but in any other place too (e.g. calendar descriptions), while still not being bloated. Most requirements come from File Comments itself.
Perhaps you want to have a look and leave input? @schiessle @nickvergessen @LukasReschke @MorrisJobke (and anyone else is invited, too, of course). Beware, since I won't have much time left until i am off for a longer while until the conf, I am going to take on the implementation swiftly (with the risk of changes in case I oversaw a thing).
13 remaining items
jancborchardt commentedon Oct 2, 2017
@blizzz do you think the @-mention-suggestions will make it into 13? Anything up for review? :)
blizzz commentedon Oct 2, 2017
#6328 as necessary pre-work… i started a dev branch based on that will deal with the backend stuff. not ready yet, nevertheless, #6328 needs to get through first. All in all it should go into 13, otherwise i feel very very very very awful.
MorrisJobke commentedon Jun 25, 2018
@blizzz Seems to be delayed again, right? Move to 15?
MorrisJobke commentedon Jun 29, 2018
Nothing for 14 it seems -> moved to 15
blizzz commentedon Jun 29, 2018
The second item could be met with a proper solution for #10021, alas i won't have the resources left to tackle it
nickvergessen commentedon Oct 12, 2018
I have a local fix for mentions with spaces.