Page MenuHomePhabricator

Huggle: Support message delivery to user who has Flow (Structured discussion) enabled on their page
Closed, ResolvedPublic

Description

As title says, we need to start developing Huggle to be able to warn a user, even if s/he has Flow activated, since it will soon be opt-in.
Huggle is translated at Cawp, Frwp, Hewp, Svwp, [ 1 ] (which are amongst the list of communities interested in the Flow opt-in).

WIP:

Design: since flow is extension to mediawiki and not part of core, this will be implemented in huggle as well as extension. The main code will be here: https://github.com/huggle/extension-flow

The branch I made in huggle core contains code changes to core necessary to override internal messaging subsystem as well as link to flow extension.

The main idea how to implement this is to create an override of class Huggle::Message (I call it MessageFlow) that will reimplement almost everything related to message handling using Flow API. When we want to send a message in huggle, it's done using WikiUtil::SendMessage which now has a hook to a virtual function that can be implemented by an extension, and it can basically override whole function if it needs.

TO-DO:

Diagram:

                       +---------------------------------+
                       |New message delivery is requested|
                       +------------+--------------------+
                                    |
                                    |
                                    |  Extension hook
                                    |
                                    |
                                    v
           Nope        +------------+-------------+           Yes
         +-------------+Is flow supported on wiki?+---------+
         |             +--------------------------+         |
         |                                                  |
         |                                                  |
         |                                          +-------+-------------------+
         |                                          |Override with MessageFlow  |
         |                                          |delivery class and initiate|
         v                                          |asynchronous query to check|
+--------+------------+                             |if target user has flow    |
|Standard delivery    +--------------+              +-------+-------------------+
+---------------------+              |     <- Nope          |
                                     +----------------------+------------------+
+----------------------+                             |Query finished, does user|
|Deliver using flow API+-----------------------------+has flow on talk?        |
+----------------------+                     <- Yes  +-------------------------+

Event Timeline

Josve05a created this task.Sep 17 2015, 3:25 PM
Josve05a raised the priority of this task from to Needs Triage.
Josve05a updated the task description. (Show Details)
Josve05a added a subscriber: Josve05a.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptSep 17 2015, 3:25 PM
Restricted Application added subscribers: Luke081515, Aklapper. · View Herald Transcript
Quiddity updated the task description. (Show Details)Sep 17 2015, 4:33 PM
Quiddity set Security to None.

You can also read/grep the Pywikibot code as an example, since it has some Flow support (including adding new topics) now.

Petrb added a subscriber: Petrb.Sep 21 2015, 11:54 AM

Is flow part of mediawiki core or extension?

I think it is an extension

OK, I guess I will need to read some documentation.

The implementation is probably not going to be that hard, all I need is to verify if wiki has Flow activated, and if yes, on which namespaces (does it works for all of them or selected NS's only)

Once it's clear whether WikiSite uses this, extension would probably override some of the WikiUtil functions used for message delivery, specifically this one:

WikiUtil::MessageUser:

/*!
 * \brief MessageUser Message user
 *
 * This function will deliver a message to user using Message class which is returned by this function
 *
 * \param User Pointer to user
 * \param Text Text of message
 * \param Title Title of message
 * \param Summary          Summary Edit summary that will be used while delivering the message
 * \param InsertSection    Whether this message should be created in a new section
 * \param DependencyRevert Rollback that is used as a dependency, if it's not NULL
 *                         the system will wait for it to finish before the message is sent
 * \param NoSuffix         Will not append huggle suffix if this is true, useful if you need to use custom summary
 * \param SectionKeep      If true, huggle will try to use the identical section, if there is not such a section it
 *                         will make it
 *
 * \return NULL on error or instance of Huggle::Message in case it's success
 */
HUGGLE_EX Message *WikiUtil::MessageUser(WikiUser *User, QString Text, QString Title, QString Summary, bool InsertSection = true,
                               Query *Dependency = nullptr, bool NoSuffix = false, bool SectionKeep = false,
                               bool autoremove = true, QString BaseTimestamp = "", bool CreateOnly_ = false, bool FreshOnly_ = false);

I think that most of huggle's code that delivers any messages to any users use this and hopefully only this function in order to do that.

The question is if the newly implemented override of this function would be able to support all of options we have now, especially merging of sections and so on, but I guess it should work.

Everything needs to be handled through API of course.

Catrope triaged this task as Normal priority.Sep 23 2015, 11:27 PM
Catrope added a subscriber: Catrope.

OK, I guess I will need to read some documentation.
The implementation is probably not going to be that hard, all I need is to verify if wiki has Flow activated, and if yes, on which namespaces (does it works for all of them or selected NS's only)

Sorry, it needs to be checked on a per-user basis, since early adopters are starting to opt into User talk on major wikis.

Naturally, converting all User talk pages on a major wiki would be a big deal, so doing it more gradually allows issues like Huggle to be worked out early.

You can detect it through the API:

Flow: https://www.mediawiki.org/w/api.php?action=query&titles=User%20talk:Mattflaschen-WMF&prop=info
Old style: https://www.mediawiki.org/w/api.php?action=query&titles=User%20talk:Keegan%20%28WMF%29&prop=info

The question is if the newly implemented override of this function would be able to support all of options we have now, especially merging of sections and so on, but I guess it should work.

Flow does not have the same concept of sections. It has topics with a topic title and then posts. Everything can be edited, but it's not just free-form wikitext.

Huggle might want to reply to an existing post (though it could do new topics as a first pass), but editing posts is probably not necessary for you.

Everything needs to be handled through API of course.

I think everything you need is exposed via API. All the write actions are exposed via API (and almost all the read actions), and the API is the primary way the write actions are done.`

Restricted Application added a subscriber: Matthewrbowker. · View Herald TranscriptOct 23 2015, 3:42 PM

There are some wikis where Flow is not enabled on any user talk at all yet, but I don't know if you want to optimize for that (I don't think this overall info is exposed in the API).

Maybe with a query, search for "contentmodel"?

Petrb added a comment.Apr 2 2016, 3:06 PM

Do we have some testwiki (beta is probably fine as well) with flow enabled? By testwiki I mean wiki where I can seriously break stuff and nobody is going to complain about it.

Petrb added a comment.Apr 2 2016, 3:09 PM

testwiki actually seems to have this :o

One approach is to implement T155968: Add ApiPostMessage using the server-side MessagePoster then use that, rather than having Huggle do these checks (are they using Flow?) on the client-side.

MessagePoster doesn't support replying to existing sections, though. So if that is a required feature, you might have to only use MessgePoster for Flow, and keep the existing path for non-Flow.

However, that would put you back into having to detect on the client-side whether it's Flow. :(

Mattflaschen-WMF renamed this task from Investigate if and how Huggle works when warning user who has Flow on user talk to Huggle: Support warning user who has Flow on user talk.Jan 23 2017, 4:01 AM
Petrb updated the task description. (Show Details)Nov 9 2017, 8:15 PM
Petrb updated the task description. (Show Details)Nov 10 2017, 8:06 AM
Petrb updated the task description. (Show Details)
Petrb updated the task description. (Show Details)Nov 10 2017, 8:20 AM
Petrb updated the task description. (Show Details)Nov 11 2017, 12:39 PM
Petrb renamed this task from Huggle: Support warning user who has Flow on user talk to Huggle: Support message delivery to user who has Flow (Structured discussion) enabled on their page.Nov 11 2017, 12:52 PM

So, first working version produced this: https://test.wikipedia.org/w/index.php?title=Topic:U1r2zu0wdqr16wip&topic_postId=u1r2zu0xxv6oj38h&topic_revId=u1r2zu0xxv6oj38h&action=single-view

The problem here, is the way how welcome and warning templates fetch name of target user I guess.

Meaning we might need to adapt the current templates we have so that they could simply be substed on flow talk pages

Quiddity removed a subscriber: Quiddity.Nov 12 2017, 3:04 AM

Does anyone from flow team have a clue how to modify the templates so that greeting contains the name of user?

Also, for backward compatibility, is there any way to subst templates like this?

'''Hello {{BASEPAGENAME}}'''

Almost all templates on English wikipedia start with this.

Does anyone from flow team have a clue how to modify the templates so that greeting contains the name of user?
Also, for backward compatibility, is there any way to subst templates like this?

'''Hello {{BASEPAGENAME}}'''

Almost all templates on English wikipedia start with this.

For now, it is not possible, sorry. The BASEPAGE NAME is the topic ID.

See T109373: Flow's usage of the page name magic words is different from wikitext talk pages.

Well, it's not hard for me to make Huggle submit the target user name as parameter to template, but it won't work for existing templates, each wiki that has Flow would need to update all of templates that are being used by Huggle, some of these templates are not dedicated for Huggle only, but are rather standard templates and they all probably use this magic word, so in that case they would need to be copy pasted to version which supports Flow.

Petrb added a comment.Nov 13 2017, 3:29 PM

BTW is there any wiki or any plan for a wiki, where flow is default for IP users?

Petrb added a comment.Nov 13 2017, 7:43 PM

Just a little update, the extension Flow was merged into master branch, so Huggle de-facto does support Flow content model to a point.

I am now going to test if there are any other major issues, other than that magic words don't work as expected in templates, but problem I have is that test grounds are limited. I installed Huggle to mediawiki, which is the only wiki I found that is English speaking (language I understand) and also has Flow enabled and unlike test wiki, it has some real traffic (although extremely tiny).

For wikis that don't have flow enabled, there is absolutely no change in behavior, even if extension is loaded and active.

Petrb closed this task as Resolved.Nov 13 2017, 7:44 PM
Petrb claimed this task.
Petrb updated the task description. (Show Details)

I see this was Resolved after a lot of discussion. @Petrb were you successful in addressing the issue (I hope)?

Hi Joe,

I was successful in that Huggle is now capable of delivery to talk pages of users that have Flow enabled, which was the primary goal of this task. There are some other minor issues, related primarily to templates themselves and how their magic words are interpreted by Flow extension, but that is nothing which should be fixed on Huggle level.

The fix of these "minor" issues can be either modification of the template used to post a message or simply, by fixing the behavior in extension. Related tasks exist: https://phabricator.wikimedia.org/T109373 which should take care of that.