Page MenuHomePhabricator

Protection log entries can be cut off
Closed, ResolvedPublic

Description

Author: cbm.wikipedia

Description:
The protection log for [[Mozilla Firefox]] in English Wikipedia includes the following:

2007-12-04T22:08:11 Cbrown1023 (Talk | contribs | block) changed protection level for "Mozilla Firefox" ‎ (Firefox has been protected for nearly a week now and, looking at the discussion page, it seems like one of the edit warriors has agreed to walk away. Could it be unprotected now? -MBlume 05:39, 4 December 2007 (UTC) (restoring semi-protection) [edit=autoc)

This log entry was apparently truncated because of excessive length. The truncation cut off the details of the protection level, making it impossible to parse the log entry to determine the protection level. Also, the expiration date is completely removed.

If a protection log entry is too long, it should be trimmed before the restriction level and expiration date are appended.


Version: unspecified
Severity: minor

Details

Reference
bz12234
ReferenceSource BranchDest BranchAuthorTitle
repos/releng/scap!217master-I7240ab57c5461e5805562bfcf42a29b2d3680b83masterdancycanary_checks: Improve format of Waiting for canary traffic message
repos/releng/scap!215master-I3745ed1b83962bc72c9e0874060cc9efbf61dea4masterdancyMention how long we're waiting for canary traffic
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:56 PM
bzimport set Reference to bz12234.
bzimport added a subscriber: Unknown Object (MLST).

robert wrote:

This would be because log_comment is only a VARCHAR(255), however increasing this to the next biggest level (BLOB\TEXT) would use a hell of a lot of resources. Perhaps if the different sections were stored in different columns the situation could be helped, however the easiest solution would be to disallow or trim comments that add up with the other parts of the summary to a value higher than 255 characters.

cbm.wikipedia wrote:

trim protection log comments

attachment loglen.diff ignored as obsolete

cbm.wikipedia wrote:

trim log comments

The first patch changed the order of the page history entry slightly, update patch to keep the same output format

Attached:

Those details really should use log_params

Fixed in r40713. This is not retroactive.

ayg wrote:

(In reply to comment #1)

This would be because log_comment is only a VARCHAR(255), however increasing
this to the next biggest level (BLOB\TEXT) would use a hell of a lot of
resources.

Not enormously. It would force temporary tables to disk and maybe have a few other consequences, but this column is normally only included in result sets, so it shouldn't be the end of the world. We should switch log_comment and rev_comment to SMALLBLOB at some point, especially for i18n purposes -- some languages might have half the number of characters available and this isn't reflected in the field's maxlength, which goes by characters instead of bytes. But those are big ALTERs and so no one seems to be interested in doing them.