CentralNotice API
Open, NormalPublic

Description

Author: pgehres

Description:
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.


Version: unspecified
Severity: enhancement

Details

Reference
bz32536

Related Objects

StatusAssignedTask
ResolvedReedy
OpenNone
bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz32536.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Nov 21 2011, 4:33 AM

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

(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.

pgehres wrote:

(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).

+1. Definitely worth a full API, to allow scripted deployment and rollback of campaign and banner configuration.

mwalker wrote:

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.

(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?

mwalker wrote:

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?

(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.

mwalker wrote:

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)
awight renamed this task from CentralNotice API to CentralNotice API (tracking).Oct 21 2015, 7:40 AM
awight set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 21 2015, 7:40 AM
Reedy moved this task from Unsorted to Non-core-API stuff on the MediaWiki-API board.
Danny_B renamed this task from CentralNotice API (tracking) to CentralNotice API.Aug 16 2016, 12:47 AM
Danny_B removed a project: Tracking.
Danny_B removed a subscriber: wikibugs-l-list.