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?

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.

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

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.

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

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

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

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

I'll be utilizing this then.

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.

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

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 :)

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 :)

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.

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 :)

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)

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

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"

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 ;-))

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.

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.

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.

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/

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

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.

alexxw83 wrote:

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

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.

Deployed on Commons!