- Add 'tags' parameters to appropriate API modules
- Add tag-adding logic to appropriate functions that carry out
relevant functions
- ManualLogEntry::{set,get}Tags to handle adding tags to log
entries in a cleaner fashion
- Use ManualLogEntry::setTags in LocalFile::recordUpload2
Bug: T97720
Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
This will mean that EnhancedChangesList does not
do odd things.
Log changes also have this set to null
This also adds a tiny bit of cleanup for the past which
could be removed in a month or 2.
This will fix all current RC entries as well as new ones.
Once no old RC entires for CategoryMembership changes exist
we can kill the type check.
Bug: T126428
Change-Id: Ib19819373af70e10b0c750ffdb06156764b7fa3d
Change tags to apply to an edit can now be passed directly to the
WikiPage::doEditContent function. They are then passed to the
RecentChange::notifyNew/Edit functions where tagging is made
after the recent change is saved. This ensures that other callers
of doEditContent will not run into the same issue as T100248.
ApiRollback is fixed in this way.
In addition, we'll have to pass tags in this way for core tagging
of edits (I2e48bd458fc8d7c289f04dc276f9287516e0b987), and this makes
it possible to merge the arrays of tags and call ChangeTags::addTags
only once.
Change-Id: I829960c7a33b70464065839d7504d7529dfd0b72
This allows to patrol file uploads, both new files and new file
versions, from the description page, provided $wgUseFilePatrol
is set to true. Special:NewFiles can be filtered to hide patrolled
files.
Bug: T11501
Change-Id: If71af58719a4461f12d125455b7bef07164525ca
This provides a mechanism to associate a revision id to an action.
For example in core, it makes sense for moves and uploads, which both
generate null revisions (also protections, but it isn't interesting if one
has patrolling in mind).
Crucially, in that case an unpatrolled status is allowed for the RC item.
So if the performer of the action is not autopatrolled, it will be displayed
as unpatrolled, and if the performer is autopatrolled, it will record an
autopatrol action.
When one associates a rev id to a type of action, one should also implement
a mechanism to patrol said action, since getting the diff for the associated
revision is not user friendly and works only if RC patrol is enabled.
This is done for uploads in If71af58719a4461f12d125455b7bef07164525ca (with
a new file patrol) and for moves in Ie0fa417feaf930c096b69521fc54d57aecd6cd51
(within RC patrol).
Extensions might possess other such actions that could benefit from patrolling.
Bug: T122089
Change-Id: I694424eca32b69e277f89d4c15183870983d0993
This is part of a chain that reverts:
e412ff5ecc.
NOTE:
- The feature is disabled by default
- User settings default to hiding changes
- T109707 Touching a file on wikisource adds and
removes it from a category... Even when page
has no changes.... WTF? See linked issue,
marked as stalled with a possible way forward
for this patch.
@see https://gerrit.wikimedia.org/r/#/c/235467/
Changes since version 1:
- T109604 - Page names in comment are no longer
url encoded / have _'s
- T109638 & T110338 - Reserved username now used
when we can't determine a username for the change
(we could perhaps set the user and id to be blank
in the RC table, but who knows what this might do)
- T109688 - History links are now disabled in RC....
(could be fine for the introduction and worked
on more in the future)
- Categorization changes are now always patrolled
- Touching on T109672 in this change emails will never
be sent regarding categorization changes. (this
can of course be changed in a followup)
- Added $wgRCWatchCategoryMembership defaulting to true
for enabling / disabling the feature
- T109700 - for cases when no revision was retrieved
for a category change set the bot flag to true.
This means all changes caused by parser functions
& Lua will be marked as bot, as will changes that
cant find their revision due to slave lag..
Bug: T9148
Bug: T109604
Bug: T109638
Bug: T109688
Bug: T109700
Bug: T110338
Bug: T110340
Change-Id: I51c2c1254de862f24a26ef9dbbf027c6c83e9063
Using the following command line, I have found doc comments (and
a wfDeprecated() call) mentioning "1.26" when they should mention
"1.27" instead, which I have fixed manually:
git diff -M REL1_26 | grep --color=always -C 10 -iP \
'^\+.*\D1\.26(\D|$)' | aha > oldver.html
Follows-up these commits:
* 047b60b96d
* 169b7b98b5
* 25a44aa3e4
* 2fb2a3f14b
* 3f1e9fa268 [1]
* 8c84af70b6
* c0cb80beac
* d04a92a551
* d3b85592ea
[1] Release notes moved in I195dd1cf.
Because a release note stating that the UserRights hook is deprecated
was added in 37062a0c0d (before the branch cut), this commit does not
change the Hooks::run call that had been changed in 21206c8fbe.
Change-Id: I5a427f003e7e3b4559fe377bcdfdca466a570708
This adds optional flags to Revision::getRecentChange
And uses them in CategoryMembershipChange
Bug: T109700
Change-Id: I197ebccf1f62cdcb03ce4daa2527b973e495236c
wfSuppressWarnings() and wfRestoreWarnings() were split out into a
separate library. All usages in core were replaced with the new
functions, and the wf* global functions are marked as deprecated.
Additionally, some uses of @ were replaced due to composer's autoloader
being loaded even earlier.
Ie1234f8c12693408de9b94bf6f84480a90bd4f8e adds the library to
mediawiki/vendor.
Bug: T100923
Change-Id: I5c35079a0a656180852be0ae6b1262d40f6534c4
* Make MachineReadableRCFeedFormatter use it
* Some unit tests
* Also fixed some line-too-long warnings in RecentChange.php
Change-Id: I443d14f5d4cdac0945cb9c03608d55745bbb865b
* These updates add to editing time and can be done
after sending the HTTP response for performance
* Also improved the active users job insertion logic
Change-Id: I5b25217c4f08db7fa9a05eac046283f02d45865e
* Also added a selectFieldValues helper method to the DB classes
since this use case keeps coming up.
Change-Id: I62cdbb497dc2c8fe4758e756d13688b85165e869
Seems stupid omission. Title has one. Why do I need to think how
to determine how to users objects point to the same user. Allows
more expressive code.
Also fixes a bug in multiple places where users "0" and "00" were
considered equal.
Change-Id: I682392e564b332b77ab489f2ad394fa2d28098a5
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I7b65fe04db431342cc58b469dc48f41a50c4e891
RC_MOVE and RC_MOVE_OVER_REDIRECT are obsolete, since at least 2006.
So it is considered safe to remove.
Bug: 63755
Change-Id: I0f17c4d164585a48fb9f0d40b90a7d3b975c7ab8
Like we do in ApiQueryRecentChanges as well, expose the named
rc.type property, not the internal integer constants.
Change-Id: I89a948eee999032bb2e42cc23345affa879afb42
The user can now specify which feeds to send to in
RecentChange::notifyFeeds if they don't want to use
$wgRCFeeds.
Additionally, the 'formatter' in $wgRCFeeds can now be an object
rather than just a class name.
Change-Id: Ibfdffc17a934e35223887c123331795563102752
Prior parseRCType was an private method in includes/api/ApiQueryRecentChanges and also
duplicated in includes/api/ApiQueryWatchList. This method has been made static and moved
to includes/changes/RecentChange.php.
Bug: 65071
Change-Id: Ic911fbcf9411c782685c4f956f8522051f2517f0
Variants included 'in <version>', 'as of <version>' and just the
version number.
Some @deprecated annotations do not have the version number at all,
I want to hunt them down separately.
Change-Id: I8208c6097098f4735d4f51bc42254675f1f27f6d
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
Changed RecentChange::notifyRCFeeds() to allow more
filter options than just omit_bots. In order to mirror
the on-wiki Special:RecentChanges UI, the options
omit_anon, omit_user, omit_minor, omit_patrolled were added,
which omits anonymous, registered, minor, and patrolled
edits, respectively.
Bug: 60941
Change-Id: I716c741f1f7d42b6506a97e9a5733beac23ac16c
This is akin to $wgSkipSkin/$wgSkipSkins. It is quite plausible for a wiki
to have more than one self prefix (e.g. enwiki has w: en: wikipedia: and
maybe others).
Some recent changes code seems to use $wgLocalInterwiki for quite unclear
purposes:
- I removed the line using $wgLocalInterwiki from the RecentChange
class, as the 'lang' field of $mExtra is not used anywhere in core code.
Extensions may use it, but it would seem more appropriate for them to
use something like $wgDBname (or indeed to consult $wgLocalInterwikis
directly) if they need to identify a particular wiki.
- In the IRC formatter, the first prefix in the array is used (if set).
Appropriate documentation is added to DefaultSettings.php.
Related to bug 954 comment 3.
Bug: 954
Bug: 955
Change-Id: I9dbb566385b464402c5e78510b95dd2ffb4d9489
