Allow viewing private logs, like suppression, from just the logid
(if the user can see them)
Bug: T269761
Change-Id: Ief2f31c2339c3866d7629c5d09d8ec5caef3d960
Title::makeTitleSafe is expensive and there is no need to create the
title to just pass namespace and dbkey to the LinkBatch
The underscore/space normalisation is done in LinkBatch::add
Also combine the linkbatch on Special:Undelete, because the user of
files are often the same as of the (null) revision
On Special:Log use log_user_text for the preload, it is always set
Change-Id: Iff8797df11d18107005402ba88b4a0e4beb3dd7d
This covers only directly used services by this special page and pager
Services used by the base class are not part of this patch set
Bug: T259960
Change-Id: Ib4b5edf6b4c56ef626875df8d95496225cddf501
This is very similar to I53a7ed59 (T223151). In that bug it was choosing
the `times` index when it should have used `actor_time` due to a
non-empty performer. This time it's choosing `times` when it should be
using `type_time` due to a non-empty set of types being queried.
Bug: T237026
Change-Id: I02c77dde6b5b54d7bea801135051b006d39459b0
The method LogPager::getFilterParams combines data aggregation and query
modification which is problematic: it starts with "get" and is public
but has a side-effect. Instead, make a dedicated private method for
building the query and remove the side-effect.
The new private method is now dedicated to building the query, and so
it can also make sure whether selection by log id is requested. If it's
the case, it won't filter the log types out (fix for T220834).
Also remove redundant comment: it's irrelevant to require callers to
call a private method.
Bug: T220834
Change-Id: I0fb6e6ee30ac626192cdf4ef920a731c03b2732f
We'll hope MariaDB doesn't trigger T221458 in that situation.
Bug: T222324
Signed-off-by: Scott Bassett <sbassett@deploy1001.eqiad.wmnet>
Signed-off-by: James D. Forrester <jforrester@wikimedia.org>
Change-Id: I06364e9d0bce45bd97b2ec837d1f479feff76699
For some unknown reason, when the `actor` table has few enough rows (or
few enough compared to `logging`) MariaDB 10.1.37 decides it makes more
sense to fetch everything from `actor` + `logging` and filesort rather than
fetching the limited number of rows from `logging`.
We can work around it by telling it to not reorder the query.
Bug: T220999
Bug: T221458
Change-Id: I9da981c09f18ba72efeeb8279aad99eb21af699a
$logId holds the log entry ID of some specific log and the datatype
is an integer (int) which is correct but looking at the constructor,
it does take a bool (false) which contradicts the docs above. So per
@Thiemo's advice after review of prev PS, it would be better to replace
false with 0 and leave the docs untouched.
Change-Id: Ieceb79a6cbaa248e1b7a7d3c1d51eb26bb3a2d84
I'm intentionally only touching these protected properties and nothing
else, because I believe these are uncontroversial. They should be protected
according to modern SOLID standards, and actually are declared as
protected in the base class. What this patch effectively does is documenting
this fact, but it does not change anything.
Change-Id: I625307b58bd419c4a72e9842b2b46c08ed9b4f8e
Also, the $default value in LogEventsList#getFiltersDesc was not
being generated properly and would have always been an empty array.
Bug: T199856
Change-Id: Id286c76259406521f12cda67a4a715032e022637
* All Xml generation code has been removed.
* The LogEventsListGetExtraInputs hook now needs a form
descriptor array and not plain HTML.
See I37e0d3e81a46239750465b9299279fbbd7c7f87a.
* LogPager and LogEventList also take the $day parameter
for 'From date (and earlier)' and pass it to getDateCond
as well.
* Since FormOptions can't automatically extract the date
from the request this is being done manually in the
execute method of Special:Log using MWTimestamp.
Bug: T117737
Change-Id: Iba3c6aa5ac40dcdee0792c2d045b238b02d76521
The number provided by the query can be arbitrary, so let's narrow the
input validation to booleans.
Bug: T194616
Change-Id: If03e6e2d5bbcf4f2d85047cc23ee5388b39fe114
$pattern is a boolean, it is documented as "Do a prefix search rather
than an exact title match". However, its type was incorrectly
documented to be a string, and the default value was '' instead of
false (which was harmless, as it is correctly treated as a boolean
value everywhere).
Change-Id: Id093d12891a231d5934f9908e619065afff7380e
Make it possible to get a URL for a single log entry,
as an alternative to using Special:Redirect/logid/123.
The existing single-log-entry link of Special:Redirect/logid/123
is also simplified to be a redirect to this new parameter.
Bug: T191608
Bug: T187638
Change-Id: I5f2e52531cd2ba617a25570e40aa8c5168e284d9
Apparently when log_user_text was added no one bothered to populate it
for existing rows. Sigh, #Technical-Debt.
Bug: T188826
Change-Id: Ice1e6454e439a4abdf9594f6e964478dd484bc20
Follow-up to ce881e02e8 where the check for performer
restrictions and action restrictions was reversed.
Bug: T188145
Change-Id: I85a44f925212929ac87fb7a7e494023258f2d148
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
Previously, if you did not have the right to patrol/view patrolmarks,
you were not allowed to filter Special:Log to remove autopatrol
entries.
Now if wikiadmins want to disable the filtering, they have to
directly change the config value.
This was stupid because:
* Users without patrol rights are just as likely to not care about
autopatrol spam as users with the priv.
* Sometimes wikiadmins want to hide old patrol log entries even
after they disabled the patrol feature.
It should be noted there have been two previously attempts at fixing
this issue that didn't go anywhere:
* I9de17fc197a06402a4999a9fb792b86657641f76
* I88448ca0f09069943fd514a5b8213dfdafa57299
Bug: T44246
Change-Id: I590db72c169f3a9ad96c710f088923419d40e48d
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
This is similar to I994d11e. Even more trivial, because this here is
about comments that don't say anything but "constructor".
Change-Id: I474dcdb5997bea3aafd11c0760ee072dfaff124c
ls_field_val was renamed to PRIMARY, but this is only partially
complete in WMF production. There is only one other index on the
log_search table, so ignoring that one is equivalent to forcing
the other one.
Bug: T17441
Change-Id: I63182a9f94eabb4cc47414d86b02c82bde1e58b0
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
This is more consistent with LoadBalancer, modern, and inclusive
of master/master mysql, NDB cluster, and MariaDB galera cluster.
The old constant is an alias now.
Change-Id: I0b37299ecb439cc446ffbe8c341365d1eef45849
- This makes Special:Log's behaviour consistent with other special
pages, e.g. Special:Contributions.
Change-Id: Ic0a9322d920d7514bacac1f29a1da4fe57cae854
This moves the action filtering logic from SpecialLog to LogPager,
in a limitAction function, as this seems to be how this is done
for other params (title, performer, etc).
This also uses $pager->getPerformer and getTagFilter() for resp.
performer and tag filter as the options to show, rather than the
raw request values (in a WYSIWYG logic).
Change-Id: I4918a8a2dca3fdbadd7d65c9c9972e6f67a1761b
