Page MenuHomePhabricator

HAWelcome take into account SocialProfile
Closed, ResolvedPublic

Description

Currently we have two automatic welcoming extensions - HAWelcome and AutomaticBoardWelcome. The latter is a social tool, posting on the user's board, whereas the former is for normal talk pages.

@jack has an uncommitted and untested patch which makes HAWelcome not edit User: pages if the user has opted to have their user: page as the social profile page and the wiki page at UserWiki

We could attempt to go a step further though, and merge the two extensions so that HAWelcome will welcome users on their board if social tools are installed and the user has their social profile page as their default user page.

cook879 created this task.Jul 9 2016, 4:36 PM
lewiscawte triaged this task as High priority.Jul 11 2016, 9:03 AM
lewiscawte assigned this task to jack.
lewiscawte added a subscriber: lewiscawte.

I'm in favour of either of these options - if we want to test the patch to HAWelcome and merge that it could be a great solution until a merge is completed.

I'm going to mark this as a high priority as new users being spammed with two notifications isn't particularly friendly.

jack added a comment.Jul 11 2016, 3:26 PM

{rSHWK3908} is the aforementioned patch. It should work, as most of the logic of the new getUserPage() method was sporked from SocialProfile (one of the hooks in UserProfile.php).

I agree with the idea of merging both extensions. However, this isn't exactly a straightforward thing, because of the following:

  1. Usually users have the choice between a wiki user page and a social user profile, i.e. social profiles aren't enforced (SocialProfile's $wgUserPageChoice config var), so we need to take these into account...
  2. ...and even if social profiles were enforced, user boards and traditional user talk pages will coexist, because to my knowledge, it just isn't possible to get rid of user talk pages without significant core hacks. Generally speaking most users tend to prefer user boards over talk pages -- I guess it's easier to use those than to go to the desired user's talk page, click "edit", make changes, preview and finally save.

So we'll probably have to create some new "config variables" for MediaWiki:Welcome-enabled, the message which controls which HAWelcome features are enabled. But wait, there's more!

  1. AutomaticBoardWelcome is open source, our HAWelcome isn't. We need to fix this so that users of ABW won't lose any functionality and won't be running obsolete software on their servers.
  2. We have little/no documentation on what HAWelcome is (IIRC), how to configure it and how to use it. This is...not ideal, to say the very least.

There's also a slight conceptual difference between the two extensions: ABW sends the message right after the creation of the user account (and even for automatically created accounts -- think of WMF and CentralAuth -- if $wgAutomaticBoardWelcomeAutowelcomeAutocreated is true), whereas HAWelcome does its magic after the user's first edit. We need to decide what to do: do we want to preserve this distinction or do we want to make the board-related functionality (=ABW) behave like HAWelcome, or something else.

Based on the fact that patch was filed... over half a year ago, we can safely assume it's been deployed. Can we close this as resolved?

jack closed this task as Resolved.Mar 29 2017, 5:40 PM

Pretty much, yeah, although I'm not sure if the patch has been tested on wikis running both extensions. I think the reason I was keeping this open was due to my earlier comment about merging AutomaticBoardWelcome and HAWelcome, but we can create a separate task for that or something.