* Do not allow working on Special:EditWatchlist
* Do not reset all notification markers
* Do not delete expired restrictions
Change-Id: I7a990c0a80b9c7a6340465dd082a110dafea8f14
Remove $wgUseDynamicDates and everything related to it.
I left DateFormatter::reformat() alone, since it might possibly be
used elsewhere, and to be honest I'm afraid to touch it.
Change-Id: I609db8471c14e5e5946916f085d2ee5b96204d81
Changed third parameter of PingLimiter hook to a
reference since that's what all the docs say and because
extensions need to be able to override the result of
the ping limiting.
Change-Id: Ia8e9d3c4de9a6f298a00949007cad53021ab782c
This allows to display the "password sent by e-mail." string in the user's language
since it's now in the action text rather than always in content language due to the
fact it was hardcoded in the log's comment.
Insertion of log entries for the new users log is now acomplished using the
ManualLogEntry class rather than the old LogPage one.
Removed 'newuserlog-byemail' message since it's no longer used (also checked
extensions in Wikimedia's Git repo).
IRC notifications will use the same message for 'create2' and 'byemail' for backward
compatibility. The only difference is that 'byemail' entries will no longer have
"password sent by email." in the comment.
Change-Id: Icdf1d714259d054cf8c256faf894c533be0dc73c
This happens when an anonymous user wants to create an account for himself through
the API. This is due to the fact that User::addNewUserLogEntry() was always using
$wgUser as performer, but the API does not replace $wgUser by the newly created user
object when the peformer is an anonymous user.
Changed User::addNewUserLogEntry() to directly take the log action as first parameter,
rather than a boolean value saying whether the password was sent by e-mail or not,
and force the performer to be the user itself in the log action is "create". This
avoids such problems in that case, no matter the value of $wgUser, and it makes this
parameter much more readable that the old one. Backward compatibility is maintained.
Creating an user and sending its password by e-mail will still log the performer's
IP address in the log if this is made by an anonymous user.
Finally the second parameter of the AddNewAccount is now correct when creating an
account from the API, it was always false previously.
Change-Id: I188ecf420b85e9d1dab6fb933ed50d5f58532109
Added the "resetkinds" option to action=options, so that when the
"reset" option is set, the user can control which kinds of options
are reset, rather than having to do all or none.
Also added documentation to the "change" parameter, since passing
it option keys without any "=value" after it will result in resetting
that specific option to its default value.
Change-Id: Id5bc1fffa0d487c0f152b79115205d2722f380d3
Before change I98df55f2 it was possible to set arbitrary preferences (ie.
with anything as the key) using the action=options API. That change
removed this ability by enforcing full validation of the preferences, also
introducing several regressions which were fixed by follow-ups.
Per the discussion on bug 40124, this changeset aims to restore this
ability, but in a slightly restricted way: arbitrary preferences' names
must start with userjs- prefix, to avoid any possibility of conflicting
with new MediaWiki versions or extensions.
The contents of these preferences is not escaped, sanitized nor validated
in any way; script authors are expected to sanitize them themselves to
prevent XSS attacks and other security vulnerabilities.
This commit also adds the User::getOptionsKinds() method (to determine
whether given preference keys are used by MediaWiki itself or an extension,
intended to be used via the API, or entirely unknown) and enhances the
User::resetOptions() method to allow for resetting only preferences of
chosen kinds.
These changes allow for fixing of Special:Preferences not to clear those
additional fields when saving user settings.
Change-Id: I5f9ba5b0dfe7c2ea5458d836f03429cf6d93969d
CentralAuth calls User::loadFromId() directly after calling setId().
This avoid having to load the object two times in this case.
Change-Id: Iade37631a9346dff45e18acfa078af37c1fbbfab
* migrateUserGroup.php: Call User::invalidateCache
* While at it, also fix the issue where User::clearInstanceCache
did not clear cache for User::getGroups.
Although it does clear the caches of methods used to calculate
other group-related lists (such as User::getEffectiveGroups),
the one for the query from user_groups was still cached in
$this->mGroups.
Presumably this was forgotten when this pattern was introduced
as the instance cache precedes the user_group table.
Change-Id: I22abdba00f8ccf587a3d7696e57970ed4653afc8
Eclipse and phpstorm where showing 'User' as return type before, which causes me to not check for false somewhere and thus fatals happening :)
Change-Id: Ibd5b5598f05e6b08481ad65060c7cae18762dc4e
I've fixed several PHP notices and the problem that rights returned
by User::getRights() might have duplicates if altered by a hook
(same for User::getEffectiveGroups).
Change-Id: Id92af387d8c09414076bac40e83052cd6f913f42
The link to the user contributions on Special:ListUsers weren't red
as the needed parameter for this wasn't set in the call to
Linker::userToolLinks and User::getEditCount returned strings while
it was supposed to return integers.
Change-Id: I8d5faaedefec02d309e3e9c2da80f135b44fa5f1
The bug has actually already been fixed, so this
patch just removes extraneous function calls and code in
User::getOption() and User::setOption(). It also adds
unit tests for user options (including a test for the
case provided in the bug report).
Change-Id: Idd8af9cf1a26a4adbde3ca71dde64539ecd0a207
Caching the result of User::getDefaultOptions as it always returns
the same data, despite for unit tests, which can't use the cached
values as they do evil things with variables being constant in normal
operation.
Change-Id: I02d557006d2f879e7ce510a5e47fa1543baab8a6
Made action=query&list=users use User::getRights() if
usprop rights given. This not only removes redundant
code, but makes it execute the UserGetRights hook, so
that this now includes rights given by Extensions (eg.
CentralAuth does that).
Patch Set 2: Modified the User class to be able to
inject further data into User::newFromRow() and using
that to inject the groups taken out of one SQL query
(for performance reasons). Furthermore I've split up
the query in ApiQueryUsers.php into one for user data
and one for the groups, to only have one row for each
user.
After all the perfomance of this should now be ok, not
extremly good, but bearable (though I couldn't test it
deeply, as I don't have much data in my CentralAuth
environment).
Change-Id: Ie5b2924abb82ac254c77e1d04cc4d5b308962dad
* Has to keep actual messages for IRC notification
* Catch really old log entries with no parameters and use an
appropriate message in that case to not always display erroneous
"X changed group membership for Y from (none) to (none)".
Change-Id: Ie188bc6fcdf672fe31f0f389a158aab6256031fa
(bug 41198) If clearInstanceCache() is to clear cached user data apart
from the data from the user table, as addToDatabase() expects, then
$this->mOptionsLoaded needs to be set to false. Clearing $this->mOptions
may reduce memory usage a bit, but is not sufficient.
Change-Id: I6912415dc154d06f62839a1ee777c2c3747253d6
User::edits() lets you fetch a cached number of edits from a slave database.
in case the field is not yet filed, we initialize if by hitting the `revision`
table and saving the result in user_editcount.
User::incEditCount() updates the edit countr and also does a lazy
initialization, if needed.
As both methods use the same $dbw->update() statement for this, I've
created a new, protected initEditCount() function which can take care of that.
Change-Id: If111270a84d4278bc4ea14d32ae602069f7c276f
Moved the logic from the old static User::edits() into
User::getEditCount() and deprecated User::edits() as it's
not following the class hierarchy.
Change-Id: Id2b939ffb903accb8f4dc132a6ac6b6576f81beb
Currently, if a user with Accept-Language: zh-tw header accesses a zh site,
the page contents are served in zh-tw variant, but the interface language
is zh (falling back to zh-hans) so the user is seeing interface messages
in zh(-hans) unless a &variant= is manually set (originally variant set in
URL is checked by getDefaultVariant).
There were debates that serving different languages based on headers from
the same URL breaks cache, but currently contents are served in different
variants based on headers and it works. So I assume this is not an issue.
PS2-4: HTTP header settings shouldn't affect user preference settings of
logged-in users.
PS5-6: Move code loading variant settings for anonymous requests from
User::getDefaultOptions() to User::loadOptions() to avoid pollution of
defaults. A visual bug of this is that if I have variant set to zh and
load index.php?title=Special:Preferences&variant=zh-cn, the dropdown is
shown as zh-cn because I was using the default value and now it thinks the
default value is zh-cn instead of zh.
PS7-8: Rebase to add dependency and tweak commit summary etc.
PS9: Remove the argument added to getDefaultVariant, which was intended to
keep B/C of getDefaultVariant (not to check headers by default).
Change-Id: Ie600ab24294a1add804875e921c32febe6ed645f
Created a new method User::groupHasPermission and check also
$wgRevokePermissions for the given right
Change-Id: I41edb091fa35c8c68b6f95cc5fd208ea99418cdb
Fix the DB error which comes from User::addToDatabase() if it is called
when the user already exists. This is the most common DB error we log at
WMF in normal operation, perhaps because of double clicks on the "create
account" button, or perhaps due to CentralAuth autocreation when
multiple pages on another wiki are opened in the browser simultaneously,
as the bug reporter suggests.
See the doc comment for the interface rationale. Patched
Special:Userlogin to be aware of the new return value. Most extension
callers will continue to work, I will patch a couple that need it in
subsequent commits.
Change-Id: I1f6ef5e6319bfe692fb82a3fa50dc66c9fde8f15
(After a question in r26457): Let User::clearInstanceCache
clear out the cached edit count as well, as a user session
can be open for a long time.
Change-Id: I4444f352e3b5df7b24f37668a5f1fbf9d64d6978
Rather than have separate calls to User::loadDefaults()
every time User::loadFromSession() fails, there is now just
one call in User::load() if loadFromSession() returns false.
This fixes the case where a UserLoadFromSession hook aborts
loading from session, leaving the User object uninitialized.
Change-Id: I8d1a114d7ec361b27b260791f742c473a1497f26
Signed-off-by: Tyler Anthony Romeo <tylerromeo@gmail.com>
* Added parameter to login link so that wpStickHTTPS
is set to true by default when the user is coming
from HTTPS.
* Added redirect in Special:Userlogin so that when
$wgSecureLogin is enabled it automatically redirects
to HTTPS.
* Adjusted User::setCookies() to add a parameter for
forcing secure/insecure cookies, and then added the
appropriate argument to Special:Userlogin so that
cookies are set appropriately.
Change-Id: I17ac68014840daa47bfd4768e978e9ff2edb00db
Sets a cookie on user login (removed on logout) if wpStickHTTPS
was checked, which causes the browser to get a redirect if they
visit the HTTP version of the site.
Change-Id: I60f44a1062a93d15198edae6674bb3310a148b2d
Allow AuthPlugin to determine if user passwords should be stored
locally.
* Released as part of 1.20wmf10, 1.19.2, 1.18.5
Change-Id: Ie41bed7ecf5390f8815128c227bae371880a6058
Last round of easy replacements. About 30 uses in core remain (outside of HISTORY
and GlobalFunctions::wfMsg*). I'll work with IAlex and Nikerabbit to work towards
getting rid of those, too.
Updated method documentation in a few places.
Change-Id: I2491c006b62a9cc183230e31a0bd96c91e5b6142
