No history for upload campaigns
Closed, ResolvedPublic

Description

Upload campaigns are historyless. There's no history or log entry about who set up each campaign, not even who created it.


Version: unspecified
Severity: normal

bzimport set Reference to bz30645.
Platonides created this task.Via LegacyAug 30 2011, 10:24 PM
JeroenDeDauw added a comment.Via ConduitAug 31 2011, 12:38 AM

Yes, this was never mentioned to me as something it should have. What kind of history are you proposing to have? Just a list of people who changed a campaign and the times of these events, or full revision history of the campaigns containing all their previous states?

Platonides added a comment.Via ConduitAug 31 2011, 10:49 PM

We usually keep a history of everything. Seems good to log at least campaign creation and deletion. A log of everything would be cool, but it probably breaks completely the beauty of the uw_campaign_conf.

JeroenDeDauw added a comment.Via ConduitAug 31 2011, 11:15 PM

I wouldn't mind implementing this, but don't think I can just go do that unless my "boss person" asks for it :)

Eloquence added a comment.Via ConduitSep 6 2011, 11:24 PM

I agree this should eventually have logging, but right now it only serves the WLM use case, where we can hopefully do without it for a while longer. We have other UW priorities right now, but Platonides, if you'd like to work on basic logging capabilities, that would be much appreciated.

bzimport added a comment.Via ConduitSep 7 2011, 7:42 PM

neilk wrote:

We did a bug triage & decided a simple field which appends username & date is easy. But low priority for the moment. Let's keep it at normal/enhancement

bzimport added a comment.Via ConduitSep 7 2011, 7:43 PM

neilk wrote:

(In reply to comment #5)

We did a bug triage & decided a simple field which appends username & date is
easy. But low priority for the moment. Let's keep it at normal/enhancement

er, except as raindrift just pointed out to me deleting the campaign should not delete the logs. So, a separate table is required. But this is still low priority

Platonides added a comment.Via ConduitSep 7 2011, 9:35 PM

We have a logging table! No need to reinvent the wheel.

JeroenDeDauw added a comment.Via ConduitSep 10 2011, 6:49 PM

Awesome, and it's even documented at https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Manual:Logging_table :)

I'll be utilizing this then.

JeroenDeDauw added a comment.Via ConduitMay 27 2012, 8:04 PM

I'm planning to migrate the UploadCampaign code to use the ORM* classes now in core. EducationProgram has code based on top of these to do the kind of revisioning needed here, so it can quite possibly be re-used.

MarkTraceur added a comment.Via ConduitAug 21 2012, 6:15 PM

Jeroen, are you able to work on this soonish? The WLM people have declared it a blocker, so....

JeroenDeDauw added a comment.Via ConduitAug 21 2012, 6:35 PM

I actually implemented pretty much this in the Education Program extension. That could is pretty generic so could be used here as well. Even so, this is not a small todo, would take a day or two (esp if we want the generic code to be shared and not work with copies).

OTOH the content handler facilities we're creating as part of Wikidata could also be used for this, the result of which would be better integrated with the rest of MediaWiki then when using the code I wrote for EP, but they are not done yet.

If someone at the foundation tells me to work on this, I would not mind implementing this using the code I wrote for EP, or wait till the content handler stuff is done (can take a while) and implement it then. So if you want to get this done, please have someone poke me :)

Platonides added a comment.Via ConduitAug 21 2012, 9:55 PM

I don't think not having this is really a blocker for WLM 2012. I would concentrate on other issues.
Maarten, what do you think?

Of course, if you have some idle time in the middle of September and feel like fixing this, go for it :)

JeroenDeDauw added a comment.Via ConduitAug 22 2012, 11:03 AM

Priority of other issues have little impact on the question of doing this or not, since I will not be tackling any other issues. I am working on other projects and am not currently assigned to UploadWizard - this particular feature just is one I can be tempted to tackle anyway.

MarkTraceur added a comment.Via ConduitAug 22 2012, 6:55 PM

I'd say this is relatively high, actually, or at least in a time crunch, since all other issues are either fixed, have a proposed patch, or are not blockers for WLM:

https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=runnamed&namedcmd=Unsolved%20WLM%20issues%20in%20UW&list_id=140348

it must be lonely here :)

Platonides added a comment.Via ConduitAug 22 2012, 9:17 PM

Not that I'm against it being fixed but, Where are you seeing this as a blocker? I see this bug marked as "Importance: Low, enhancement"
(The query you linked to is apparently not public)

MarkTraceur added a comment.Via ConduitAug 22 2012, 9:24 PM

Sorry, it's listed as a blocker for bug 37144, the WLM tracking bug.

Platonides added a comment.Via ConduitAug 22 2012, 10:34 PM

That's how tracking bugs work. Consider that as "related to Wiki Loves Monuments" instead of "must be fixed for Wiki Loves Monuments to run"

tomasz added a comment.Via ConduitSep 2 2012, 12:48 PM

This bug is a real pain for Wiki Loves Monuments maintenance, as you can't tell who edits the upload campaigns and cannot communicate effectively.

It's probably too late now to have this implemented in WLM2012, but our experience suggests that this will be a very welcome enhancement, and would save people a lot of stress and work.

More experiences will be known after the end of the contest ;-))

Basvb added a comment.Via ConduitSep 2 2012, 12:52 PM

It's currently giving some trouble with some of the WLM campaigns. Some settings get changed over and over and it's impossible to see who did that. This way there are happening some "editwars" without the people on both sides able to find who the other person is and thus talk towards a solution. That's the problems generated with users (admins) of good faith thinking they fix something. Potentially more dangerous is if one admin decides to become a vandal (there is 300 people it wont happen every day but can happen once) he can mess stuff up over and over without anybody knowing who deliberatly messes the campaigns up.

JeroenDeDauw added a comment.Via ConduitJan 8 2013, 11:22 PM

I ran into a similar situation with Education Program and wrote a whole pile of stuff to have such "items" look and behave more like regular wiki pages. That went pretty well. However since ContentHandler is now in core, it's better to use that, as it allows for a higher degree of integration.

Removing myself as assignee as I am not working on this and do not plan to do so unless asked by WMF.

yuvipanda added a comment.Via ConduitJun 18 2013, 11:33 PM

I'm planning on working on moving Campaigns stuff to use ContentHandler, so doing that should automagically take care of this bug. Am picking up notes at https://www.mediawiki.org/wiki/User:Yuvipanda/Campaigns_namespace_proposal.

yuvipanda added a comment.Via ConduitJun 28 2013, 1:05 AM

There's a patch in progress that fixes this, and plenty of other issues.

  1. Campaign metadata is just pages in a Campaign: namespace, with page history
  2. Campaign_talk namespace can be used for discussions easily
  3. Arbitrary number of fields supported! (no longer just idField1 and idField2)

And a fair number of other bug fixes.

According to the current plan, however, there is a downside - Special:UploadCampaign and Special:UploadCampaigns will go away. You can create a new Campaign by simply creating a page under the Campaign: namespace, edit it by hitting 'edit' on that page (editing raw JSON at this point), and delete / move it via the usual page delete / move tools. If people find raw editing the (simple!) JSON too cumbersome, we can eventually add an UI for the editing interface.

Patch in progress at: https://github.com/wikimedia/mediawiki-extensions-UploadWizard/pull/3 (or) https://gerrit.wikimedia.org/r/#/c/70446/

bzimport added a comment.Via ConduitJun 28 2013, 4:08 AM

alexxw83 wrote:

(In reply to comment #22)
Hi Yuvi Panda, sounds great! Some questions:

  • Is there a possibility to 'import' existing campaigns?
  • will there be a own right to edit this namespace or is it only editable for admins?
  • Will our external, prefilled links still work? In other words: are there still php-parameter like description or id?

Best Alex

yuvipanda added a comment.Via ConduitJun 28 2013, 10:06 AM

Hello AleXXw!

  1. Yes, we will migrate the current campaigns to use the new system automatically
  2. There already is a right ('upwizcampaigneditor', I think?) that is by default assigned to admins only, but other people can be added to it. I personally want to expand campaign creation to more people, but I think ultimately this would be a decision of the Commons community.
  3. Yes, they will work!

We're maintaining 'external' compatibility - the only changes are if you are someone who creates/edits/manages campaigns. No changes for people who only upload images via them.

bzimport added a comment.Via ConduitJun 28 2013, 1:59 PM

alexxw83 wrote:

Sounds even greater, all my fears are gone ;) thx for the update!

yuvipanda added a comment.Via ConduitJul 9 2013, 7:53 PM

This has been merged, and is available on commons betalabs to test!

I've imported all the current campaigns from commons into betalabs - you can see the list of campaigns at:

http://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Special%3APrefixIndex&prefix=&namespace=460

Each page represents a campaign, and you need to edit the page to change its properties, enable/disable them, etc. They have page history, can be watchlisted, moved, deleted, undeleted, etc. Also there's a talk page. The old interface no longer exists.

And all the UploadWizard urls (appending &campaign= and other things) should work as is. If they do not, please file bugs!

I'll leave this bug open until it gets deployed to commons, though. It should be deployed in a week or two, depending on how many testers we get.

yuvipanda added a comment.Via ConduitJul 22 2013, 10:39 PM

Deployed on Commons!

Gilles raised the priority of this task from "Normal" to "Unbreak Now!".Via WebDec 4 2014, 10:23 AM
Gilles moved this task to Closed on the Multimedia workboard.
Gilles added a project: Multimedia.
Gilles lowered the priority of this task from "Unbreak Now!" to "Normal".Via ConduitDec 4 2014, 11:20 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.