Last modified: 2008-10-08 21:45:42 UTC
When using 'list=logevents&letype=protect' in an API query, protections made more than about a month ago are output in a different format to those made more recently. See for example http://en.wikipedia.org/w/api.php?action=query&list=logevents&letype=protect&letitle=Paul%20Newman Any chance the API module can convert the old format to the new, or otherwise output all protection log entries in a consistent format?
(In reply to comment #0) > Any chance the API module can convert the old format to the new, or otherwise > output all protection log entries in a consistent format? > I can't give a definitive answer until tomorrow, but what I think is happening here is that protection information was only added to log_params recently (about a month ago). If I'm right, this data simply isn't in the logging table for protections predating that change, so the API would naturally be unable to output any information about them. Of course the second, empty <param /> tag is weird and needs to be fixed.
(In reply to comment #1) > I can't give a definitive answer until tomorrow, but what I think is happening > here is that protection information was only added to log_params recently > (about a month ago). If I'm right, this data simply isn't in the logging table > for protections predating that change, so the API would naturally be unable to > output any information about them. > Turns out I was right, so this bug is INVALID. > Of course the second, empty <param /> tag is weird and needs to be fixed. > The second param tag is there to flag whether cascading protection is used: if it's not, you'll get <param />, if it is, you'll get <param>cascade</param>. The current display of protect parameters isn't really elegant, but as there's pretty much no useful information in the log_params field (just the part of the summary that lists the protection levels and expiries, and the cascade flag) I'm not going to bother displaying it in a special format like with moves and some other actions: there's simply not enough machine-readable information in log_params to warrant that. If you care about getting protection types, levels and expiries from the protection log in a machine-readable format, please file another bug here requesting that the format used to store protection information in log_params be changed. As a workaround, you can query current protection status through prop=info&inprop=protections , but that won't get you anywhere if the protection in question has been removed, altered or has expired.
(In reply to comment #2) > If you care about getting protection types, levels and expiries from the > protection log in a machine-readable format, please file another bug here > requesting that the format used to store protection information in log_params > be changed. As a workaround, you can query current protection status through > prop=info&inprop=protections , but that won't get you anywhere if the > protection in question has been removed, altered or has expired. It's OK... the current format is adequate, just means a little more complexity getting the protection log (first have to work out whether the old or new format is being used, then parse the "comment" field or <param> tags as appropriate and extract the protection details).
(In reply to comment #3) > It's OK... the current format is adequate, just means a little more complexity > getting the protection log (first have to work out whether the old or new > format is being used, then parse the "comment" field or <param> tags as > appropriate and extract the protection details). > Well the API was invented to eliminate parsing text which may change its format at any time. Since you'd benefit from it, I'll bug people about changing the log_params format so protection data can be presented cleanly.
(In reply to comment #4) > Well the API was invented to eliminate parsing text which may change its format > at any time. Since you'd benefit from it, I'll bug people about changing the > log_params format so protection data can be presented cleanly. Thanks... don't worry too much about it though, even that would still mean parsing two formats (as the old protections have the data embedded in the summary field).
