Last modified: 2014-11-17 10:36:10 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T5525, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 3525 - Cross-wiki watchlists
Cross-wiki watchlists
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Normal enhancement with 32 votes (vote)
: ---
Assigned To: Victor Vasiliev
: crosswiki
: 13605 14488 16695 17914 65969 (view as bug list)
Depends on: 57
Blocks: 64475
  Show dependency treegraph
 
Reported: 2005-09-21 08:32 UTC by Alexey Krasheninnikov (ACrush)
Modified: 2014-11-17 10:36 UTC (History)
37 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Alexey Krasheninnikov (ACrush) 2005-09-21 08:32:38 UTC
Please consider providing wikimedians with crosswiki watchlists. Such could also
be made public as an option.

ACrush
Comment 1 lɛʁi לערי ריינהארט 2005-12-11 03:33:03 UTC
Hallo!

*benefits*
This would help to save a lot of time.

*disadvantages*
If the number of changes for [[special:Watchlist]] is limited there are
scenarios where the changes from major wiki's would make it impossible to see
the "events" from the local wiki's watchlist.

*implementation*
a) It should be possible to select / deselect
- the local part
- the global part
b) For sites with a great number / amount of wiki's each user should have the
possibility to select the "watched wiki's" using checkboxes. Buttons as "select
all" / "deselect all" should be available too.

best regards reinhardt [[user:gangleri]]
Comment 2 lɛʁi לערי ריינהארט 2005-12-11 13:24:38 UTC
Bug 3544: Single Recent changes on several mediawikis
is related to the implementation od a crosswiki "Recentchanges".

If both will be implemented the functionality should provide the same options.

best regards reinhardt [[user:gangleri]]
Comment 3 Raimond Spekking 2008-01-24 17:27:17 UTC
*** Bug 12778 has been marked as a duplicate of this bug. ***
Comment 4 Raimond Spekking 2008-04-03 15:12:11 UTC
*** Bug 13605 has been marked as a duplicate of this bug. ***
Comment 5 Luxo 2008-04-03 15:25:17 UTC
until this bug is fixed you can use http://tools.wikimedia.de/~luxo/gwatch/ - one watchlist for all wikimedia-projects. 
Comment 6 Melancholie 2008-05-05 01:45:57 UTC
In some extent bug 5220#c21 (web feed + Mozilla Thunderbird) could help!

All wikis, but only one email/news account.

@public viewing: Maybe "Google reader" etc. could be a help.
Comment 7 Titoxd 2008-06-11 20:02:00 UTC
Re public viewing: See Bug 471 for a related bug, as all the issues that apply there apply to this bug as well.

Ideally, this bug should be split into cross-wiki and public viewing parts of the bug, although the latter would be redundant to Bug 471 as well.
Comment 8 Waldir 2008-06-14 10:50:33 UTC
*** Bug 14488 has been marked as a duplicate of this bug. ***
Comment 9 Melancholie 2008-12-19 03:02:18 UTC
*** Bug 16695 has been marked as a duplicate of this bug. ***
Comment 10 Siebrand Mazeland 2009-02-02 11:42:06 UTC
Changing component to "Watchlist"
Comment 11 Chad H. 2009-03-10 21:41:31 UTC
*** Bug 17914 has been marked as a duplicate of this bug. ***
Comment 12 Happy-melon 2009-04-02 19:48:44 UTC
Retargetting: this is clearly a CentralAuth feature-request; and splitting the bug as suggested: comments on the "with option for public viewing" part --> bug471.
Comment 13 Waldir 2010-05-18 13:08:31 UTC
Now that bug 471 has been fixed, a new tool has been developed to allow this. It could still use some polishing, but I thought it'd be worth mentioning here: http://www.watchlistr.com
Comment 14 tisane2718 2010-05-25 02:33:08 UTC
I'm thinking that either a new field, identifying the wiki on which the page is located, will need to be added to the watchlist table, or a whole new table will need to be created to store the necessary data. If unified logins are in effect, it does seem to make sense to tie that in with this functionality. So then, what strategy should be used to implement this? Create a branch of CentralAuth, get code review approval, and then merge into the trunk? Or create another extension that relies on this extension without being an integral part of it?
Comment 15 tisane2718 2010-05-26 17:19:49 UTC
I will attempt to implement this.
Comment 17 Nemo 2012-04-28 08:42:36 UTC
Looks like global watchlist will be a side-effect (!) of the new notification system: <https://www.mediawiki.org/wiki/Thread:Talk:Echo_(Notifications)/Bundling_and_expiry>
Comment 18 Andre Klapper 2013-01-09 13:36:55 UTC
Victor:
This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED.
In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help!
[assigned>=1y]
Comment 19 Guillaume Paumier 2013-05-06 13:40:02 UTC
Victor, I'd like to echo Andre's comment above; are you still interested in working on this feature?

There's a renewed interest in a global watchlist now that SUL is being finalized: [[mw:Watchlist wishlist]].

It would be great it you could confirm your interest in working with users to implement this, or let other developers know if you don't currently have the time.

Thanks!
Comment 20 MZMcBride 2013-05-19 00:59:34 UTC
(In reply to comment #19)
> It would be great it you could confirm your interest in working with users to
> implement this, or let other developers know if you don't currently have the
> time.

In my opinion, it's not a question of whether Victor has time to work on this. It's a question of whether anyone has time to review code that Victor puts together for this. As a volunteer contributor, he's had enormous difficulty getting his code reviewed in a timely manner.
Comment 21 Nathan Larson 2013-10-07 05:45:41 UTC
If there is no objection, I'd like to fix this bug. I'm going to try a different approach than what I did last time with the InterwikiIntegration extension; rather than duplicate all the code that implements the watchlist special page, I'll either (1) make the core code more extensible or (2) implement the interwiki watchlist as core functionality. Does anyone have a preference for one of those two options? Personally, I'm for the latter.
Comment 22 Victor Vasiliev 2013-10-07 16:36:01 UTC
(In reply to comment #19)
> Victor, I'd like to echo Andre's comment above; are you still interested in
> working on this feature?
> 

I am interested, if there are people interested in reviewing the design of that feature.

I had a ~working prototype of it, which I made, IIRC, during one of the Wikimanias I attended. It is, however, probably lost because it was done in a pre-git era when branching was hard and I have no idea where it is.

The back end part basically requires that you maintain a global recent changes table, since reading RC tables from all individual wikis is not feasible. That is not really hard, as long as you make sure that you mirror all revision deletion correctly.

Surprisingly, the front end is the more problematic part here. When I tried to work on it, the UI code for watchlist showed active resistance to being adopted for the cross-wiki purposes.
Comment 23 Nathan Larson 2013-10-07 18:40:27 UTC
Victor: Yeah, you'll need to add new parameters and such to quite a lot of functions. However, I think it will be well worth it, because it will save users quite a lot of time checking all the different watchlists in the WMF wiki farm. I too made a working prototype of it that used a global recent changes table, but the interwiki watchlist special page UI duplicated much of the code from includes/specials/SpecialWatchlist.php (the existing single-wiki watchlist). It would be better, of course, to reuse code as much as possible by changing the existing functions to handle both single-wiki and interwiki use cases. Let me know if you get too busy and want to hand this off to me; otherwise, I'll leave it in your able hands.
Comment 24 Kunal Mehta (Legoktm) 2013-12-21 09:37:42 UTC
I wrote a small proof of concept script to do this completely client side: https://github.com/legoktm/xwiki-watchlist/blob/master/xwikiwatchlist.js

The basic concept is that you just make API requests to each wiki, pull the watchlist, and merge it with the changes made on other wikis, and nicely display it to the user. This also makes it easy for users to pick which wikis to include/exclude.

That said, I'd love to see a sever side solution to this bug :)
Comment 25 Andre Klapper 2014-02-28 14:45:01 UTC
(In reply to Victor Vasiliev from comment #22)
> > Victor, I'd like to echo Andre's comment above; are you still interested in
> > working on this feature?
> > 
> I am interested, if there are people interested in reviewing the design of
> that feature.
> 
> I had a ~working prototype of it, which I made, IIRC, during one of the
> Wikimanias I attended. It is, however, probably lost because it was done in
> a pre-git era when branching was hard and I have no idea where it is.

Victor: So is there any initial code currently to share?
Comment 26 Victor Vasiliev 2014-04-26 09:09:55 UTC
(In reply to Andre Klapper from comment #25)
> Victor: So is there any initial code currently to share?

I did a quick search through my local source copy and did not find anything.
Comment 27 Sam Reed (reedy) 2014-05-31 21:17:00 UTC
*** Bug 65969 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links