Last modified: 2012-11-10 01:52:54 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 T34536, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32536 - CentralNotice API
CentralNotice API
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: fun-com, fundraising
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
 
Reported: 2011-11-21 04:33 UTC by Peter Gehres
Modified: 2012-11-10 01:52 UTC (History)
10 users (show)

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


Attachments

Description Peter Gehres 2011-11-21 04:33:23 UTC
For many reasons, it would be incredibly useful if CN had an API.  Even a read-only API would allow for the creation of monitoring scripts that could notify when, say, no banners are allocated to the US during the fundraiser (potentially resulting in losses nearing $50k/hour) among other things.
Comment 1 James Alexander 2011-11-21 04:51:34 UTC
prioritizing as normal atm, will go over priorities in next day or two. Also tagged as fun-com since we have a lot of community members who could do this if interested.

Mingle card created for Allocation API: 368
Comment 2 MZMcBride 2011-11-21 04:53:52 UTC
(In reply to comment #0)
> For many reasons, it would be incredibly useful if CN had an API.  Even a
> read-only API would allow for the creation of monitoring scripts that could
> notify when, say, no banners are allocated to the US during the fundraiser
> (potentially resulting in losses nearing $50k/hour) among other things.

I agree that an API would be nice, but you should feel free to file separate bugs for feature requests if it's appropriate. Hacking up scripts that use a public API is fine for some things, but if proper monitoring is needed (for example), that can be filed as a separate request.
Comment 3 Peter Gehres 2011-11-21 05:00:31 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > For many reasons, it would be incredibly useful if CN had an API.  Even a
> > read-only API would allow for the creation of monitoring scripts that could
> > notify when, say, no banners are allocated to the US during the fundraiser
> > (potentially resulting in losses nearing $50k/hour) among other things.
> 
> I agree that an API would be nice, but you should feel free to file separate
> bugs for feature requests if it's appropriate. Hacking up scripts that use a
> public API is fine for some things, but if proper monitoring is needed (for
> example), that can be filed as a separate request.

I'm not sure if monitoring should be included in CN; I honestly haven't given that as much thought as I have the API.  In fact, thinking about it more, as far as monitoring for the fundraiser, this check should be part of a bigger monitoring and alerting system (possibly included in the analytics tools).
Comment 4 Adam Wight 2012-10-31 09:00:25 UTC
+1.  Definitely worth a full API, to allow scripted deployment and rollback of campaign and banner configuration.
Comment 5 Matt Walker 2012-11-01 20:37:41 UTC
Unfortunately due to the rights required for CN banners it will not be possible to script creation of banners. Not that I'm entirely sure we would want to.

It may be possible to have an API for campaign creation/deletion/modification though. Uncertain as to the use case for it.
Comment 6 MZMcBride 2012-11-01 21:55:45 UTC
(In reply to comment #5)
> Unfortunately due to the rights required for CN banners it will not be possible
> to script creation of banners. Not that I'm entirely sure we would want to.

I don't understand what this means. Can you elaborate?
Comment 7 Matt Walker 2012-11-01 23:44:43 UTC
MZ -- banners are currently created in the MediaWiki namespace which requires admin privileges. Although this is not in and of itself a problem I understand that we have some policies in place that say admin actions should not be automated -- so... I don't see a pressing need to add functionality that should never be used.

Thoughts?
Comment 8 MZMcBride 2012-11-02 00:01:50 UTC
(In reply to comment #7)
> MZ -- banners are currently created in the MediaWiki namespace which requires
> admin privileges. Although this is not in and of itself a problem I understand
> that we have some policies in place that say admin actions should not be
> automated -- so... I don't see a pressing need to add functionality that should
> never be used.

I don't know of any such "no admin action automation" policy on Meta-Wiki. Do you have a link?

And this would not really be considered automation by any reasonable definition. There are a large number of actions that are restricted to particular user groups (such as deletion, page protection, etc.) that have been available in the API for ages. One feature of this proposed API (banner creation) might require a specialized user right (such as "editinterface"), but I don't see any reason why that's relevant to this bug.

Whether the API were read-only or read/write, I think it would get moderate use.
Comment 9 Matt Walker 2012-11-10 01:52:54 UTC
MZ -- I was talking to James Alexander and he confirmed that we in fact do NOT have a policy against automated admin changes. I don't recall where I got that impression.

That being said -- I'm thinking APIs for the following things:

-- Allocations: Past, Current (Already implemented), Future
-- Banner Management: (Add/Remove banner from campaign)
-- Campaign Management (Enable/Disable; change target)

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


Navigation
Links