Discourse Presence - "Who is writing"

(David Taylor) #21

I ran into the same error in my plugin. Have created a pull request which should hopefully fix the problem. Not extensively tested but seems to work for me :slight_smile:

5 Likes
(David Taylor) #22

Thanks @adrapereira for merging it in. @ewanly hopefully it’ll work for you now :smiley:

1 Like
(EW 👌) #23

Thanks David :+1:. I’m going to enable it again. I hope it will have no other problem.

Edit:
I did installed back and its working again :tada: :sparkles:

3 Likes
(gauthier) #24

Thanks for this plugin, it’s usefull.

I’ve a bug when someone writing a reply and someone else create a new topic:

On the screen, it’s a new topic.

Thanks again!:clap:

(Chris Beach) #25

Is this plugin currently working for others?

I have enabled it but not seeing the avatars appear. Also nothing in the JavaScript logs. On the latest version of the plugin and of Discourse.

(David Taylor) #26

Following discussion here:

I have been working on improving this plugin. It now works with the latest Discourse, and now works for “editing” as well as “replying”. The indicator has been moved to the top right of the composer, and most importantly the ellipsis is animated! :wink:

I have updated the top post with new information and screenshots.

18 Likes
Editing wiki posts at same time as someone else sometimes loses revisions
(Jeff Atwood) #27

Very nice!! Let’s try it out in core!

10 Likes
(David Taylor) #28

PR to include discourse-presence as a core plugin: :slight_smile:

16 Likes
(Régis Hanol) #29

I’ll merge it :fr: tomorrow morning unless someone else beats me to it :wink:

14 Likes
(David Taylor) #30

This is now merged - thanks @zogstrip

If you previously had this plugin installed you need to remove it from your app.yml file, otherwise the next rebuild will fail.

9 Likes
Forum is down, upgrade failed with fatal error, need help
(Joshua Rosenfeld) #31

Minor nitpick here. I have an ultra-wide monitor. For me, the someone is replying appears way over on the edge of my monitor, far from the composer.

Any chance it could sit above the preview area instead of being flush right?


Side note, loving this new feature. Very helpful for me when dealing with PMs.

7 Likes
(Jay Pfaffman) #32

I hate when this happens, as unless you’re someone who reads every message here, you’re likely to have no idea that this is going to happen to you. Is there a way to modify the plugin to know to disable itself it it’s being included in a version of Discourse that doesn’t need it?

6 Likes
(David Taylor) #33

The issue is not with the plugin “disabling itself” - the rebuild problem occurs because you cannot clone the plugin git repo on top of a plugin that has the same name in core.

The only way would be to rename the core version of the plugin, and then empty the existing GitHub repo. I can make a PR if the team would like to do this.

For this plugin I’m hoping it won’t be too much of a problem, since it has been broken for the last few months anyway.

4 Likes
(Jay Pfaffman) #34

Thanks. This has happened with a few plugins that have moved to core. It sounds like there’s not an easy solution other than to always rename something as it gets moved into core, which I suppose introduces a whole other set of problems.

3 Likes
(Christoph) #35

yes, if all core plugins would be named discourse-core-whatever, that would also signal to people what they’re dealing with, i.e. not a “real” plugin!

6 Likes
(Jeff Atwood) #36

This is really nice @david excellent work :tada:

One suggestion, let’s kill off “is also” and just have “replying” since that says enough, and less words = less translations = less screen space used for jibba-jabba = more betterer.

9 Likes
(David Taylor) #37

Sounds good to me

I hope I’ve added the transifex config correctly - if someone who uses it can double check that would be great :slight_smile:

5 Likes
(Robin Ward) #38

I made a couple changes to the plugin this morning. The first thing I did was use shouldRender on the connector to avoid it rendering if the plugin is disabled which saves some time. There was also a bug for me with regards to the presenceUsers array not existing by the time it was computed which broke the composer for me.

While I was in there I realized the code has some pretty big issues that need to be fixed:

  1. IMPORTANT: There is no guardian logic to ensure a user can see the composer they’ve subscribed or published to. This means that I can see who is typing on a topic that is private. It doesn’t leak information about the topic but this definitely should not be allowed. I’ve made the plugin disabled by default until this is addressed.

  2. The component is injecting the controller. All of a component’s arguments should be passed in to encourage a clean interface. The injected controller should be removed and replaced with the exact arguments it needs.

  3. The majority of the logic is extended into the composer controller. Why not do it all in the component? You get a lifecycle of didInsertElement when the component is rendered and willDestroyElement when it is removed. This should be a lot simpler than the current code which has to detect if the composer is closed/open/not visible

10 Likes
(David Taylor) #39

Thanks for looking over the code and making some changes - I’ll work on those comments today :slight_smile:

Edit:

11 Likes
(Robin Ward) #40

Thanks for the pull request! I’ve merged it.

9 Likes