Forum Discussion

PerBonomi's avatar
9 years ago

Reply "Collision detection"

Since our Super Users asked for it I cobbled together this widget. It's not perfect, but it seems to be working.

I asked Lithium to add a custom field for messages, so I can save a state of who is currently replying to a post and when they hit reply.

Logic:

On loading the Reply Page, check if the user has a certain role, like Super User.

If yes:

- add the current user's id and system time to the list in that custom field.

- check that same field for other entries

- If an entry is found, check how long ago the other user(s) loaded the Reply page and if within a certain time frame, show the current user who else is replying.

Since I don't know how to cleanly hook into the reply (post) button's built-in triggers I added a mouseenter trigger to the Post and Cancel buttons, which removes the user's id and time from the custom field.

Screenshot below. Code is attached. One component, one endpoint.

 

  • Hi PerBonomi,

     

    Great contribution! As Wendy_S mentioned, our users have been asking for something like this for a long time. 

     

    I didn't realized I was having the same issue where the users were not deleted from the list. After some testing and google I *think* the issue is the form is interferring with the http request to the endpoint. 

     

    I might have accidentally fixed the issue while using the .unload() event to call the endpoint. I was trying toremove the user when they click on a link or type a new URL directly on the address bar too. Here's the code.

    <@liaAddScript>
    		$( window ).unload(function() {			
    			
    			var url='${community.urls.communityPrefix}/plugins/custom/hp/${community.id}/collision-check-endpoint?id=${msg_id}';
        		$.ajax({        
        			url:url
        		});    		
    
    		});
    	</@liaAddScript>

     

    Hope that helps!

  • One more quick comment.

     

    I noticed that, in our communities, I was getting an "permission denied" error when replying to a reply -not the original question-, probably because the custom field was set up for just for first message in a thread. I'm not 100% sure.

     

    Anyways, we want to keep a single list for the whole thread, regardless of whether the user replied to the original question or a reply, so I tweaked the code a little.

     

    I replaced these two lines

    <#assign msg_non_unique_id = http.request.url?substring(http.request.url?last_index_of("/") + 1, http.request.url?length)/>
    <#assign msg_id = rest("/boards/id/${coreNode.id}/messages/id/${msg_non_unique_id}/id").value/>

    With this:

    <#assign msg_id = env.context.message.discussion.topicMessage.uniqueId />

    (this gets the unique id for the first message on the thread, so no need to use another rest call)

     

    Just an FYI in case you're having the same issue on your communities.

     

    Regards!

    • Wendy_S's avatar
      Wendy_S
      Boss

      PerBonomi

       

      I want to say THANK YOU once more for sharing the code. fuenteso did a great job in making it a (beta) functionality in our communities and we're testing it as we speak.

      This is what it looks like :-)


      Thanks again! so so much! I will hug you next time we meet.

       

       

    • housikrausi's avatar
      housikrausi
      Expert

      PerBonomiI have the reference to this Feature from @DanK. Great feature. I am technically affine but have such a feature not yet built into lithium. Can I read somewhere how this works or is an IT specialist generally necessary?

      • PerBonomi's avatar
        PerBonomi
        Boss

        housikrausi wrote:

        PerBonomiI have the reference to this Feature from @DanK. Great feature. I am technically affine but have such a feature not yet built into lithium. Can I read somewhere how this works or is an IT specialist generally necessary?


        Hey housikrausi.  The code is fairly short and basic. The zip contains one component and one endpoint. Pretty much copy/paste. But just have a look and see. One thing you need Lithium Support for is to add a custom metadata field to messages. It's this one in the code, you can call it anything you want, I went with spotify.editors: "/metadata/key/spotify.editors/"

  • PerBonomi

     

    Hi! :-) thanks for sharing this. It's been one of our popular demands so we may use your code and test it out. It might come in handy specifically for expert days where we have many folks responding to customer question in the same time so chances of someone responding to a message that someone else is already working on, increases.

     

    Just a quick question. Am I supposed to gather anything from your screenshot? I am not exactly sure what I am supposed to see or what should trigger me.

     

    Thanks!
    Wendy

    • PerBonomi's avatar
      PerBonomi
      Boss

      Hi Wendy_S it's very subtle, I'll admit. If you look at the top, I logged in and hit reply on a topic. Then I also logged in with a different account and hit reply. Now, as that other user, I see that user Per hit reply 10 seconds ago.

       

       

      • Wendy_S's avatar
        Wendy_S
        Boss
        I see it now. It was well "hidden" for me. It's because the username was so short :)
  • ClaudiusH's avatar
    ClaudiusH
    Khoros Alumni (Retired)

    PerBonomi Your code is suggesting that this component will only show to a super user if other super users are responding to the same topic.

    Wendy_S Your screenshot though suggests that it will show to super users if any community member is responding. Is that correct?

     

    I actually favour the variant where only SUs see other SUs responding as the second variant seems quite intrusive to almost the level of monitoring members' behaviour. Also usually the SU's / staff's worry  most of the time seems to be to respond to a topic another SU/staff is responding to and not necessarily normal "mortal" members.

    • Wendy_S's avatar
      Wendy_S
      Boss

      You are right Claudius. I like PerBonomi set up a lot too so we might reconsider.

      It will usually be another expert or agent responding and not a user. But again, I get the point as well. 

      Cheers!

    • Wendy_S's avatar
      Wendy_S
      Boss

      ClaudiusH wrote:

      @PerBonomi Your code is suggesting that this component will only show to a super user if other super users are responding to the same topic.

      @Wendy_S Your screenshot though suggests that it will show to super users if any community member is responding. Is that correct?

       

      I actually favour the variant where only SUs see other SUs responding as the second variant seems quite intrusive to almost the level of monitoring members' behaviour. Also usually the SU's / staff's worry  most of the time seems to be to respond to a topic another SU/staff is responding to and not necessarily normal "mortal" members.



      You are right Claudius. I like PerBonomi set up a lot too so we might reconsider.

      It will usually be another expert or agent responding and not a user. But again, I get the point as well. 

      Cheers!