Problem/Motivation
People are already using @[username] in issue comments (likely provided by Dreditor) to respond to a particular person, but there are no notifications fired when this happens.
Proposed resolution
1) syntax:
@username
and for usernames with spaces:
@username with spaces@
There is a character limit for usernames, and we can check for an ending @ that is not proceeded by a space.
2) document
Document the syntax in the same place we document [#NNNNN]:
https://www.drupal.org/filter/tips
which is the link on the lower right below comment and summary text areas.
3) autocomplete
to be handled in #2416521: Add autocomplete for @username in textareas on issues on d.o
@username is the format people are already using, and will work for most usernames.
The autocomplete would help people discover the syntax for names they select that have spaces in some kind of natural way,
but we do not need to wait for the autocomplete for this to be useful.
4) way to opt out of getting notifications
have a setting on people's profile where they can opt out of getting notifications when they are mentioned,
and include a sentence and link to the profile place for that in the notification email.
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Original report by @Deciphered
Hi,
I don't know if anyone has thought about this or looked into this already; I did a quick search and wasn't about to find anything.
My suggestion is to create the ability for users to refer to other users using the @username (as per twitter) and have that @username become a link to the users profile (user/uid).
The second part of the feature would be to record mentions (use of @username) on the users dashboard so they can be alerted to comments/conversations that are relevant to them, also similar to twitter.
I have already started looking into this and have created a basic module that provides a filter that does the linking if there is a valid 'username', however I have come across two major issue:
1. Usernames with a space in them are not currently caught by my regular expressions and I don't think they can be successfully caught without using a termination marker (@username@, @user name@, etc).
2. hook_filter() does not provide any information about the node or comment id, therefore the tracking of mentions can not be done at the filter level. It may be the case that the translation of @username has to be done in hook_node_api() instead of hook_filter(), which could cause performance issues.
I would appreciate any feedback on this idea; to tell me it's a terrible idea and won't make it in, to offer support or ideas on how to achieve it, anything at all.
Also, being unfamiliar with the drupalorg project, is this something that should be done in an external module with some integration added into the dashboard, or should it be all in here?
Cheers,
Deciphered.
Comments
Comment #1
Deciphered CreditAttribution: Deciphered commentedSo I know this concept is so exciting that it has left everyone speechless, but I have created the Mentions module which achieves everything this request was after, except of course for getting it implemented on D.o.
The two issues I raised where extremely simple:
1. By default the replacement pattern is [@username] so that all users can be captured, but I did make the pattern customizable so you could use @username or @username@ or anything else you wish.
2. While the replacement is done via hook_filter(), the recording of the mention is done in hook_nodeapi() and hook_comment().
I still think this would be a great feature for D.o., allowing users to notify other users/developers of an issue that they would like them to look into, etc.
Cheers,
Deciphered.
Comment #2
ohnobinki CreditAttribution: ohnobinki commented+
This is especially important for
@<username>
-style mentions in project_issue's bug tracker so that people can properly be notified that their help is requested on a bug, to make references to people's nicknames robust against nickname changes, etc.Does that make #1175910: Enable mentions module for use in project issue comments on drupal.org a dupe of this? ;-).
(I was forced to select a Version for this bug by project_issue).
Comment #3
Deciphered CreditAttribution: Deciphered commentedI believe it does, yes.
I'm still more than happy to help with this, the only reason I wrote the Mentions module in the first place is that I wanted users to be able to notify other users when there assistance was required in an issue.
While I haven't had any time for the Mentions module, I would make time to re-write the module if this issue was to gain some traction.
Cheers,
Deciphered.
Comment #4
Deciphered CreditAttribution: Deciphered commentedTagging
Comment #5
mgiffordThis would be pretty interesting. It can be hard to find in a busy thread.
This module doesn't have a stable D7 version and is Seeking new maintainer
https://drupal.org/project/mentions
I think when those issues are resolved it's worth considering again.
With all of these ideas, what is going to be the impact on the social interactions on d.o? I think this would be a positive one.
Comment #6
mgiffordComment #7
jenlamptonI was just going to recommend the same thing, when I stumbled across this issue. My suggestion was going to include using something lik http://podio.github.io/jquery-mentions-input on the front end as well as the php filtering on the back. What do you think?
Comment #8
drummFront-end input should be a separate issue from evaluating the Mentions module.
An alternative implementation would be dreditor's:
from https://dreditor.org/features.
Comment #9
markhalliwellI think https://drupal.org/project/atjs would probably be better TBH.
Comment #10
Deciphered CreditAttribution: Deciphered commentedThe Mentions module still needs a complete port to Drupal 7, but that's not really a major task in itself.
There is a sub module that someone wrote for it that did allow for Auto complete of names, but it doesn't work with Wysiwygs, however I don't know if that would be an issue with the editor on D.o.
It's worth noting that while the frontend aspect is important, what Mentions primarily does is trigger of actions (Rules) upon mentions being made, such as emailing users that are mentioned to notify them of the mention, as well as providing Views integration to show a user a page of all their mentions.
Comment #11
markhalliwellNo, d.o doesn't use a wysiwyg, just https://drupal.org/project/bueditor.
Sorry, didn't realize you were the module's maintainer. It's cool that you started on it and I'm really not trying to sideswipe this.
I'm just saying that we should probably go with a 3rd party library that has a lot of the API logistics worked out (as far as the front-end goes). The At.js Drupal module is relatively new, but it also already has many of the same features the Mention module has. I know Alli (@heylookalive), the creator/maintainer of At.js, and I'm sure I could probably help move the project into a much more stable release.
I probably also have an interest in piloting this because of Dreditor, which already provides name and comment # tab completion. I would love to finally move this out of Dreditor on onto d.o. To me, it just makes sense that we use a solid 3rd party JS plugin (so none of us have to keep maintaining it). We just set up the hooks in the module so that people get notified.
What At.js would also give us is a way to autocomplete comment numbers using the
#
initiator:https://github.com/ichord/At.js/wiki/Base-Document#register-multiple-at-...
If we were ambitious, we could probably also have it automatically add issue relationships when the "mention" callback is initially invoked :)
Even more ambitious, we could probably even link it into the API docs so we could autocomplete function urls, maybe using the
:
initiator, thoughts?Comment #12
heylookalive CreditAttribution: heylookalive commentedThanks for the ping Mark! Here's a link to the library demo so people can see it in action: http://ichord.github.io/At.js
Jen, http://podio.github.io/jquery-mentions-input I've taken a look and am not sure that the plugin let's you reference things within a textarea which At.js does.
I'd say that At.js suits this purpose fine, also there are multiple options for what's possible so within the issue queue you could have:
@ mentions for usernames
# for issues (autocomplete results would show issue title)
: for referencing API (great idea Mark!)
Mentions does trigger rules events but via the hook system in the At.js module this is easily done. At.js also provides an optional method for storing mentions and whether or not they change. At this point I wouldn't have thought it's necessary and would add extra load performance wise. It could be turned on at a later date if and when d.o has a centralised notifications system (though emails do get sent as a result of issue changes).
The At.js module is quite new so could do with a bit of discussion on how to make it more solid, in effect it lets you interface very closely to EntityFieldQuery which could be considered a good or bad thing, at it's core it should be fairly quick though.
Comment #13
Deciphered CreditAttribution: Deciphered commentedMentions for D7 has a beta release now, including a jQuery autocompletion of users with the ability to use either the username direct or be configured to use a unique machine name field (nick name) as well as rendering the actual output of the mention as a token so that something like Realname could be used for the output rather than the username. However, for the sake of D.o, username in and out is likely the best choice.
Happy to work with anyone to make any required changes to the module to make it more applicable, or work with others working towards this goal as this is an important piece of functionality for D.o.
Comment #14
YesCT CreditAttribution: YesCT commented@Deciphered Thanks.
I think the next steps here are an updated issue summary using the issue summary template
and getting set up with a d.o dev server. See the handbook page: Develop on our server (preferred) https://www.drupal.org/node/1018084
Comment #15
realityloop@YesCT could this be tackled as part of the mentoring improvements for d.o. that are on my plate now?
Comment #16
realityloopadded and filled out issue summary template
Comment #17
realityloopComment #18
markhalliwellThis has nothing to with Twitter specifically (common feature across multiple sites). Furthermore, this really isn't/shouldn't be about just usernames.
@Deciphered, you mentioned in your original issue summary that there are two major issues with that module. Have those been fixed or figured out? Your comment in #13 doesn't really say. There's still the issue (as far as I can tell) that mentions relies on WYSIWYG implementation, which d.o has none (and will likely never have).
I'm sorry, but this issue really hasn't even begun... I'm not really sure what an issue summary update will actually accomplish at this point. Has anyone actually read #11 and #12? The only reason I'm pushing for At.js is that is "proudly found elsewhere" with many added benefits (i.e. not limiting to just @usernames for one).
In the D7 upgrade of d.o, it has been mentioned several times that the more we can keep functionality of d.o away from custom implementations, the better. While I understand that the mentions module is independent of d.o, I suspect that a lot of it is or will be tailored specifically for d.o. This has bit us in the past because we tend to get the mentality that "it's ok, we can just make it do this our way", which ultimately has proven to make things far difficult for us in the future.
Comment #19
Deciphered CreditAttribution: Deciphered commented@markcarver
Of the two issues previously mentioned:
1. If usernames are allowed to have a space in them, then they need a suffix. Mentions provides the ability to completely customize the token used, it defaults to "[@username]", which is seemingly consistent with D.o's "[#123456]" for issues, but it can be customized to anything a site admin wishes.
2. Mentions uses hook_entity_insert/update() to record the Mention, I can't see why there would be any performance issue.
As far as this issue having begun, the first step is to identify the problem and make a suggestion to resolve it. @realityloop had done a good job of this IMHO, which has always been simple; Allow people to Mention other users and allow those mentioned users that they have been mentioned.
The autocompletion aspect is secondary, you can already enter a link to a D.o issue quite easily, and if need be put in a URL to anything else, and they work as needed. But alerting a specific user to an issue is not easy. You don't need autocompletion for that part, because if you are trying to alert a specific user, you already know their name. What you need is a method for the user to be alerted.
Clearly there's going to be bias from me towards the Mentions module, just as there is going to be bias from you towards the At.js module, yet I will try to do a super quick unbiased synopsis of my understanding of the differences:
- Mentions is specifically for twitter inspired @username style mentioning of a user any any entity, recording said mention and exposing the mention(s) to the Rules module and the Views module making it super easy for site builders to alert users to a mention or displaying all mentions via a View.
- At.js is a wrapper for the At.js javascript library, mentions are recorded, but they can only be accessed by a developer writing a database query.
There is no doubt in my mind that both modules could be modified to meet the needs of this issue, but my understanding of this issue has already been met by the Mentions module, out of the box it will do what needs to be done, and if we want auto-completion of usernames as an added extra it simply requires the presence of the jquery-textcomplete library.
Comment #20
heylookalive CreditAttribution: heylookalive commentedAt.js maintainer here!
In reference to usernames with spaces dont work for mentions module, same for atjs - if you work it out let me know!
Atjs is entity based and field API based as opposed to entity_hook_* and allows for any entity to be a to/from in terms of mentions.
As mentioned it is optional to record mentions, so if the community simply wanted mentions without the overhead of recording the mention as with doing something like ":url" to refer to an API function.
A question for @Deciphered, in atjs we've got hooks available for alerting if a mention has been created or removed, these are aware in the case of seeing a mention if it's new or not. So if an issue were to be edited which had a mention in it, atjs will only fire a hook if there's another new one present and not react to existing mentions, does mentions have this? If so we've got decent parity!
Mentions and machine name, atjs utilises entity field query and when creating a listener you can choose both the "search" index e.g. username, random field on whatever entity, nid and so on. Also you select the data you want back from the query e.g. for user - uid, username, random image file from profile. Again any entity type can reference another or itself.
On the plugin, yep no way am I going near trying to write a plugin to do this stuff, that's my personal line and kudos to anyone who does as this stuff is complicated cross browser and all that.
I'll also throw out I'm happy to put some work in, right now the things I see where atjs is lacking is views integration (which would be akin to flags views integration) and rules hooks, latter is easy.
Final thing from my POV I'd question what we want to do here, if the goal is to get twitter style mentions into the issue queue with an email notification either module can do this right now.
If we're saying we want to do that and also list out where people have been mentioned and so on then the criticism of atjs having no views integration is valid.
Thanks!
Comment #21
YesCT CreditAttribution: YesCT commentedI think autocomplete can be separated out.
Let's keep this just about making the format and notifications.
Here is the separate issue #2416521: Add autocomplete for @username in textareas on issues on d.o
Comment #22
YesCT CreditAttribution: YesCT commentedI thought about the syntax.
1)
I propose:
@username
and for usernames with spaces:
@username with spaces@
This might work, as I suspect there is a character limit for usernames, and we can check for an ending @ that is not preceeded by a space.
2)
We can document the syntax in the same place we document [#NNNNN]:
https://www.drupal.org/filter/tips
which is the link on the lower right below comment and summary text areas.
3)
It is the format people are already using, and will work for most usernames.
The autocomplete would help people discover the syntax for names they select that have spaces in some kind of natural way,
but I think we dont need to wait for the autocomplete for this to be useful.
4)
I think we should have a setting on people's profile where they can opt out of getting notifications when they are mentioned, and we should include a sentence and link to the profile place for that in the notification email.
Comment #23
YesCT CreditAttribution: YesCT commentedtaking out some of the opinion wording from the summary.
Comment #24
markhalliwellAutocomplete should not be an afterthought
Autocomplete will shape how and what we do on the back-end and must be considered seriously.
I am _not_ bias towards At.js. I have never used it personally in any projects. I have simply done the research and have concluded that this library offers the most bang for the buck.
I think there is a lot misunderstanding in what my goal of this issue is here. It isn't to "keep it simple". I am trying to expand this issue and think of the bigger picture. We must look at this objectively and in a forward thinking manner.
No. Autocompletion should not be "secondary", it should be primary. This is 2015, autocomplete is everywhere, they are expected on modern websites. Many people are unaware of the issue filter until they discover/install Dreditor and it "auto completes" a full URL into the shorthand syntax for them. The only reason that many of the power users know of this issue filter is because they themselves are practically tenured and saw this feature actually go in or eventually caught on.
My goal with Dreditor has always been to move/combine as many of it's features into d.o. Yes, we had originally looked at At.js to replace Dreditor's custom code, but realized that we'd need AJAX callbacks on d.o. The next logical step is really to cut it out of Dreditor entirely and move it here.
The only reason I am pushing for At.js is that its module is built around a 3rd-party JS plugin. This means that it's not a complete afterthought for the front-end UX. It provides a sophisticated UI out of the box that allows us the expandability for future features. By doing another filter to just "keep it simple"... I feel would put us down a path that would stifle future feature expansion and isn't really the correct direction.
I, for one, am tired of seeing d.o being treated with front-end techniques from over 10 years ago. It only hasn't been until recently that we've gotten things like: a responsive theme, styled comments w/user pics and git credit & committing.
The "mention" comes naturally with At.js and that shouldn't be our focus here, but rather to provide a better UI and UX to users.
Comment #25
YesCT CreditAttribution: YesCT commented@markcarver You have a very good point. But I think it is a different new issue. #2416625: Add At.js autocomplete in textareas on d.o
If that is implemented, it might solve this also. (I'm not sure I see how yet though)
Let's describe it over there since it is bigger than just username mention notifications.
Comment #26
mgiffordSpaces are complicated... With Flickr when you tag photos they just eliminate them. If we did this then "username with space" would just become "usernamewithspace".
Now it could be that there are some instances where there are legitimate conflicts with domain names. Say, we have another user that sets up a "Mark Carver" account. I think this would be a potential concern. I don't know if Drupal.org deals with upper/lower case either for that matter.
For the purposes of tagging though we can just search for @WimLeers in the alias' even though it is actually "Wim Leers". I think that would be an easier convention to remember than @Wim Leers@.
I don't have any stats on this, but I'm pretty sure that 90% or more of users don't have spaces in their user names. Would be good to confirm this, but I suspect that the vast majority of users would benefit of this feature being implemented well before we deal with the exceptional users like Wim.
I do think removing the space as our convention would also help deal with legacy content. We can find users that have spaces in their name. We can search MySQL for "@Wim Leers" and replace old comments with "@WimLeers". Or we can just apologize to users like Wim and say that the legacy content won't be tracked at this time.
Whatever convention we choose, it should be documented in the tips.
The notifications also should be on a page off the user profile. Definitely shouldn't be in your face.
Good discussion thus far.
Comment #27
markhalliwellI suggested in this issue that we actually restrict usernames to only alphanumeric characters (plus ._-) as this is the convention for most sites on the internet. It also helps deal with data integrity when dealing with issues like this. It would be far easier to search for usernames and then use a "display" name afterwards if one exists.
Comment #28
mgifford@markcarver - absolutely. Should make implementation easier too.
Comment #29
Wim LeersPlaying the devil's advocate. Especially because I've always found it utterly retarded that d.o is one of the few sites where you can use spaces. There's no good reason to not allow spaces in usernames. We didn't have Twitter until a handful of years ago.
Commencing the play:
The data we enter on d.o should be entered through an assistive editor. That assistive editor would start to autocomplete if we typed "@" followed by an alphanumeric character, hence autocompleting to the full username. The assistive editor would map this to whatever form of HTML we decide on. The server-side filter to do the rendering can then be very simple again, not having to take into account spaces.
Comment #30
markhalliwell@Wim Leers, I would suggest mentioning the same thing in #2274717: Optionally offer a display name instead of "first last (user)" on user pages?. I knew I wasn't the only one that wanted to display their first and last name while keeping their username "standard" :)
Comment #31
Wim LeersDone.
Comment #32
YesCT CreditAttribution: YesCT commented#2474609: Not possible to credit people who didn't comment in an issue is a bit related to this one.
Comment #33
rcross CreditAttribution: rcross at CrossFunctional commentedobviously I'm coming to this issue late. Its worth pointing out that some people use email addresses as their usernames, so the "@thing with spaces@" format might need adjustment.
Comment #34
rcross CreditAttribution: rcross at CrossFunctional commentedComment #35
markhalliwellHonestly, I don't think we can continue to add robust features to d.o unless we really address the issue at hand first: usernames.
I talked about limiting usernames to alphanumeric (allowing _ and - as well) as a solution for this problem in #2274717-21: Optionally offer a display name instead of "first last (user)" on user pages?.
I really think this needs to be addressed before we can really continue with any issue pertaining to usernames.
Solutions like @...@, and the various permutations like it, are really just a symptom of having to deal with non-machine usernames. It's ugly, unreliable and quite honestly too much work to catch "every" use-case.
Comment #36
rcross CreditAttribution: rcross at CrossFunctional commentedIs there a specific issue where making the change to allowable usernames on d.o is being discussed? The display name issue is related/relevant, but doesn't seem to specifically address changing the machine name validation of usernames.
Comment #37
markhalliwellNo, I didn't see one so I just created this one.
Comment #38
Deciphered CreditAttribution: Deciphered as a volunteer commentedI tend to agree, even though the Mentions module does have support for prefix and suffix, it's only out of necessity. @username is always going to be better than [@user name] or @user name@.
Comment #39
YesCT CreditAttribution: YesCT commentedI'm not sure looking at how dreditor does autocomplete is useful (in response to @drumm in #8)
To move forward I think we need to...
1: update issue summary that reflects the state of things
2: get @Deciphered and @markcarver (and others?) in a hangout or some good communication form to come to agreement ... agreement I think on what the criteria for success is of this issue (MVP?) and if it includes autocomplete or not
3: write up a spec that in the issue summary
4: escalate to DSWG for prioritization
4: get feedback from d.o staff
(I know there were two 4's)
Comment #40
markhalliwellI'm personally (and very strongly) against "using Dreditor's autocomplete". It is a very rudimentary implementation, solely based on basic FE input, and just needs to die out. There is no real 1:1 data correlation to the site (d.o) it's integrating with.
There are much better solutions out there for a true autocomplete integration between d.o's BE and FE, Dreditor (in this case) is definitely not one of them; solutions that d.o (and Dreditor) would not have to maintain at all in the future.
Comment #41
star-szr(crosspost with @markcarver)
I happened to catch some discussion about this in IRC and as one of the Dreditor maintainers I'd like to state that the implementation of autocomplete in Dreditor is probably not going to be helpful here. I personally get frustrated with it regularly, and there are issues on GitHub to rework it…
https://github.com/dreditor/dreditor/issues/237
https://github.com/dreditor/dreditor/issues/160
@markcarver mentioned this above in #24:
More generally in terms of this functionality, limiting the list of people that are @ mentionable to those that have commented on the issue really limits its usefulness IMO.
Comment #42
PieterDCI just want to support the people working on this issue by informing you that my colleague Sardara and me would be really happy with this feature. (We are used to it from working with the Jira ticketing system on a daily basis.)
Comment #43
Deciphered CreditAttribution: Deciphered as a volunteer commentedMark and I met up yesterday to discuss this issue and how we can best move forward with it, and as such we have come up with the following:
Requirements
User based mentions
Issue node mentions
Project node mentions
Plan
Comment #44
webchickMay the schwartz be with you. This would be incredibly handy.
Comment #45
heylookalive CreditAttribution: heylookalive commentedThat's good news, sad I missed out on the conversation as would've been good to meet (but wasn't at DC).
As mentions will be the chosen solution is there any chance of At.js merging into it or nah?
Comment #46
markhalliwellThe "Plan" section in @Deciphered's comment above are really phases (and the order that we will be implementing these features). Each of these phases are purposefully abstract/standalone so we don't build a dependency/custom code nightmare (as we have seen from the previous d.o upgrade).
In reality, the Mentions module is much more stable and focuses on just one very specific piece of the functionality: handling the backend Drupal/filter integration.
Any UI enhancements (like CKE/At.js) will come later. Whether or not we specifically utilize At.js inside the CKEditor plugin is still up in the air TBH (I would like to, but we'll have to just see... we're not quite there yet). If we do, it will likely just utilize the At.js JS library itself, instead of the module.
Before I can even really answer that question though, I will have to do an audit of d.o's JS so we can get jQuery updated for d.o's theme, bluecheese. The front end stuff will likely start happening the end of the year or so.
P.S. the issue summary definitely needs updating. Thinking about creating a meta for this as well, may do that when I get back if someone doesn't beat me to it.
P.P.S. the
[@username]
format should really be[@uid]
as usernames can change. This is for data integrity purposes only. Yes, we could do some fancy custom code that converts it upon save, but It would make more sense to just keep the filter as simple as possible.We can, in the future with the UI stuff, make this more intuitive with CKE which will allow us to display an @username prettily inside the editor and then it deconstructs into necessary filter format for data storage upon save.
Comment #47
drummThe
[#123456]
issue mentions format is handled by project issue module. Any extra functionality there, like programmatically commenting on the mentioned issue, should live in project_issue module.I didn't see an issue for this already, so I made one #2578695: Use CKEditor on *.drupal.org sites.
Comment #48
Deciphered CreditAttribution: Deciphered as a volunteer commented@drumm,
While you are correct,
[#123456]
is already handled by the Project module, that is purely the replacement of the filter side of things, which the Project module can continue to handle.The mentions aspect of that particular use case will be via
hook_entity_*()
which will register the mention and trigger it's relevant reaction.However, it makes perfect sense that the actual implementation of
hook_mentions_*()
could live within the Project issue module or similar.Comment #49
webchickWouldn't we want @foo to work in forum posts, news comments, etc. too? I'm not sure why to tie it to project_issue module. [#xxx] makes sense to do so, because it's pulling in project_issue data, but @foo is username stuff.
Comment #50
Deciphered CreditAttribution: Deciphered as a volunteer commented@webchick
I'm not at all suggesting that. The mentions module rewrite will allows for multiple mention types to be defined (user, issue node, project node, etc), which determines the pattern used to detect a mention and how to replace it. Upon detection of a mention, a mention entity will be created which will trigger hook_entity_*/hook_mentions_* which a module can react to.
With that in mind, the reaction to a mention of an Issue node can go somewhere related, just as the email notification of a User mention (made anywhere) can also go somewhere related.
Comment #51
markhalliwellYes, but the project_issue filter doesn't store mentions and thus trigger hooks/events. project_issue could implement certain hooks as @Deciphered mentions afterwards, but the actual filter would need to be the mentions module. Essentially, the current filter code would be moved into an appropriate hook_mentions_* implementation for project_issue (and largely slimmed down I imagine).
Yes. This issue is about abstracting this filter (via mentions module) so it works everywhere and allows specific entities to be referenced. The mentions module should not care that it's a user entity or a node entity mapped to a specific "issue" or a "project" entity bundle. All it needs to worry about is linking to a specific entity and then triggering some sort of hook/event. It is up modules, like project_issue, to implement the necessary hooks to deal with their specific use cases. In the case of users, I would imagine that code would live in something like drupalorg.
Comment #52
drummYep, refactoring the issue mentions is okay to do. project_issue will still need to handle some of it for the issue status coloring, and the less-known extras like putting in the assigned person like #448074: @ style mentions for usernames which send notifications for D.o Assigned to: Deciphered.
Comment #53
heylookalive CreditAttribution: heylookalive commentedWhen rewriting it'll be worth taking a look at the At.js modules code as in that we've got the awareness of new/removed/unchanged references (this requires storing things in the database).
Comment #54
heylookalive CreditAttribution: heylookalive commentedRe-reading some of this, I'd like some clarity from @deciphered and @markcarver as to why At.js is less viable than mentions module. I'm sure there was balanced discourse, I'd just like the justification for one over the other please.
https://www.drupal.org/node/448074#comment-10373093
Comment #55
drummI don't think that was said exactly, they are parallel problems. At.js can handle the front end (nice autocomplete-style UI), and mentions the back end (storing who mentioned who, allowing notifications to be kicked off). They aren't competing.
Comment #56
heylookalive CreditAttribution: heylookalive commentedHey Merlin! The At.js module does exactly what you described, provides inline autocomplete referencing of entities triggered by a character/string (@/#/:/anything). Along with storage of mentions firing a hook when new mentions appear, change or are removed. So, with that I'd say they are comparable.
https://www.drupal.org/project/atjs
Comment #57
Deciphered CreditAttribution: Deciphered as a volunteer commented@heylookalive,
I did take a look at the At.js module when I was first made aware of it, and if I recall correctly the two obvious issues I found where:
These could of course be remedied. My personal concern would be the tie in to a specific Javascript library, which becomes confusing if/when that particular library becomes redundant by another library; personally I'd opt for a more generic approach that would allow for any number of library to be used in the front-end.
However, I am far from being un-biased, and I would recommend that someone else do a review.
Regardless, I am already in the process of re-writing Mentions to be more generic, modular and powerful, and will continue to do so regardless of any decisions made here, I am also not going to sit around for another four years, and will be pushing forward for a resolution on this issue.
I am open to combining the two modules, so if you are interested in doing so, contact me via my D.o issue queue and we can setup a time to have a voice call.
Comment #58
Deciphered CreditAttribution: Deciphered as a volunteer commentedI've pushed the big 7.x-2.x commit for the Mentions module, which makes the module Entity based (Mentions are Entities, Mention Types are CTools pluggable Bundles) and object agnostic (Currently you can mention any type of Entity in anything, but via CTools plugin you could also mention any non-entities as well).
I will begin implementing this on my D.o dev environment this evening.
Comment #59
heylookalive CreditAttribution: heylookalive commented@Deciphered, the comparison isn't quite right but to be honest I've got my hands full and if you're able to commit time to this then I support that and would happily merge at.js.
Good to hear on entities!
Comment #60
markhalliwell@heylookalive, I think you misunderstand. We will likely use At.js library itself (also as a CKEditor plugin) for the front-end. @Deciphered and I spent a good amount of time discussing this and ultimately what we realized is that we need abstraction.
The backend needs to be decoupled/interchangeable with whatever solution is used on the front end. Currently this sounds like the At.js library, but that could easily change in the future. From my experience, having a top level module that is solely and specifically designed around a single front end library has never really bode all that well.
When we integrate the At.js library, it will likely be as a sub-module of the mentions module.
Comment #61
Deciphered CreditAttribution: Deciphered as a volunteer commented@heylookalive/@markcarver,
There is also the possibility that the existing at.js module becomes the sub-module for the Mentions module with the singular purpose of adding at.js support to mentions. This would mean that Mentions would need to ensure that it covers all usecases of the existing backend functionality of at.js, as well as providing an upgrade path.
I think we still have time to discuss this after the initial round of work is done for Mentions on D.o, and there is probably a better place to have this discussion, such as:#2582423: At.js 2.x as front-end for Mentions 2.x branch
Comment #62
Honza Pobořil CreditAttribution: Honza Pobořil for Czech Radio commentedBtw, from the UX point of view it is good to use common syntax, because users are used to use it on other services.
This issue queue have similar target group like GitHub, GitLab, etc. and this services use this symbols:
@ username
# issue number
! pull/merge request
namespace/project#issue
(all without [ ], with autocomplete and with expanded title on render)
Comment #63
Deciphered CreditAttribution: Deciphered as a volunteer commented@Bobik,
The problem with the lack of
[]
is that Drupal.org supports usernames with spaces, so if someone were to write: "Hi @bob how are you?" and there were users bob and bob how then it wouldn't be simple to determine which user is being referenced here. Javascript can be used to render it without the[]
, but you'd still need the filter to have a distinct end point if we are to support names with spaces.Comment #64
ohnobinki CreditAttribution: ohnobinki commented@Deciphered StackOverflow comments ignores spaces in usernames when doing this. For someone named “John Smith”, the autocomplete will have you type “@JohnSmith” and notify the correct person. However, the scope of the possible people that can be notified is narrowed down to the people participating in the particular question/answer comments. If Drupal treats “John Smith” (2 spaces), “John Smith” (1 space), and “JohnSmith” as unique usernames, this won’t help any. If you have autocomplete, you could just have the autocomplete expand to the more complicated markup for usernames that require it.
Comment #65
Honza Pobořil CreditAttribution: Honza Pobořil for Czech Radio commentedMention module have nice solution - if you want to mention user with spaces you have to do it like this:
@John Seed@
Not nice, but could work, if autocomplete do it automatically.
Comment #66
realityloop@ohnobinki
The StackOverflow behavior you described will prohibit you from drawing the attention of someone who isn't involved in the thread, which is likely how many would want to use this functionality (including myself).
Comment #67
Deciphered CreditAttribution: Deciphered as a volunteer commented@Bobik,
As the author of the module, I am aware of that ;) Not nice, but essential when spaces are allowed in usernames.
Comment #68
markhalliwellThe actual symbol used on the front end (e.g. @, #, !) is of any little real consequence. I would imagine that what should actually be saved in the field should resemble that of something like a token (e.g.
[@bob how]
or[#12345]
). On the front end (especially if utilizing CKE/widgets) we can display the visual representation of said token with a more human readable output (excluding the bracket prefix and suffix).edit: fixed token examples (been a while since I've read this issue)
Comment #69
Deciphered CreditAttribution: Deciphered as a volunteer commented@markcarver I agree, but that is dependent on D.o having CKEditor to utilise, which it does not currently. I know that we discussed that would happen in relation to this work, but I know for myself time is not something that has been kind in the last year, and I suspect the same for you.
Comment #70
markhalliwellCKE is already on d.o (which doesn't require jQuery 1.7+, #2451277: [meta] Implement jquery_update on d.o, as I originally had thought).
CKE is just not turned on for
project_issue
node types... in part, mostly, because of #1673278: [PP-1] Add user_enhancements to d.o for smaller Dreditor features.I have been working on that issue in my spare time... which hasn't been a lot lately these past few months, no (I'm hoping to spend some time on it over the holidays).
Once that's in though, we'll likely get CKE for issues too which means that we could easily create a CKE widget for this.
Anyway, regardless of whatever the FE implementation, the storage of said data should be a token because that's what actually has to be stored.
Personally, I'd rather we work on the assumption of a CKE widget moving forward.
Comment #71
Deciphered CreditAttribution: Deciphered as a volunteer commentedToken or Filter, yes, I fully agree, and also more than happy to move forward with the assumption of a CKE widget. I will also do my best to be more involved in this issue over the holidays.
Comment #72
drummSee also #2741227: Enable CKEditor for more content types. Our CKEditor configuration has mangled some code in documentation pages. Some root causes have been fixed, maybe not all. You can try it out on documentation pages on Drupal.org. In particular, we want to make sure existing issue summaries edited with CKEditor work well and nothing is mangled.
Comment #73
paintingguy CreditAttribution: paintingguy commentedplease continue developing this module. I am on D9 and am currently trying to figure out how to mention and notify users mentioned in threads. Any help doing this, I would be sooo grateful!