2019-04-29 07:47:31 +00:00
|
|
|
<?php
|
|
|
|
|
/**
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
|
*
|
|
|
|
|
* @file
|
|
|
|
|
*/
|
|
|
|
|
|
2024-09-25 16:17:29 +00:00
|
|
|
namespace MediaWiki\Api;
|
|
|
|
|
|
2023-05-28 09:50:24 +00:00
|
|
|
use MediaWiki\Block\AbstractBlock;
|
2021-04-16 12:55:24 +00:00
|
|
|
use MediaWiki\Block\Block;
|
Support new block schema
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
2023-10-27 03:34:10 +00:00
|
|
|
use MediaWiki\Block\CompositeBlock;
|
2023-04-25 19:33:42 +00:00
|
|
|
use MediaWiki\Block\DatabaseBlock;
|
Separate Block into AbstractBlock, Block and SystemBlock
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
2019-03-18 22:09:49 +00:00
|
|
|
use MediaWiki\Block\SystemBlock;
|
2024-09-25 16:17:29 +00:00
|
|
|
use MediaWiki\Language\Language;
|
2023-09-19 12:13:45 +00:00
|
|
|
use MediaWiki\User\User;
|
2023-08-19 03:35:06 +00:00
|
|
|
use MediaWiki\Utils\MWTimestamp;
|
Separate Block into AbstractBlock, Block and SystemBlock
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
2019-03-18 22:09:49 +00:00
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
/**
|
|
|
|
|
* @ingroup API
|
|
|
|
|
*/
|
|
|
|
|
trait ApiBlockInfoTrait {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get basic info about a given block
|
2021-04-16 12:55:24 +00:00
|
|
|
* @param Block $block
|
2019-10-20 00:04:00 +00:00
|
|
|
* @param Language|null $language
|
2019-04-29 07:47:31 +00:00
|
|
|
* @return array Array containing several keys:
|
|
|
|
|
* - blockid - ID of the block
|
|
|
|
|
* - blockedby - username of the blocker
|
|
|
|
|
* - blockedbyid - user ID of the blocker
|
|
|
|
|
* - blockreason - reason provided for the block
|
|
|
|
|
* - blockedtimestamp - timestamp for when the block was placed/modified
|
2021-12-02 16:27:31 +00:00
|
|
|
* - blockedtimestampformatted - blockedtimestamp, formatted for the current locale
|
2019-04-29 07:47:31 +00:00
|
|
|
* - blockexpiry - expiry time of the block
|
2021-12-02 16:27:31 +00:00
|
|
|
* - blockexpiryformatted - blockexpiry formatted for the current locale, omitted if infinite
|
|
|
|
|
* - blockexpiryrelative - relative time to blockexpiry (e.g. 'in 5 days'), omitted if infinite
|
2019-10-03 17:45:58 +00:00
|
|
|
* - blockpartial - block only applies to certain pages, namespaces and/or actions
|
2019-04-29 07:47:31 +00:00
|
|
|
* - systemblocktype - system block type, if any
|
Support new block schema
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
2023-10-27 03:34:10 +00:00
|
|
|
* - blockcomponents - If the block is a composite block, this will be an array of block
|
|
|
|
|
* info arrays
|
2019-04-29 07:47:31 +00:00
|
|
|
*/
|
2019-10-20 00:04:00 +00:00
|
|
|
private function getBlockDetails(
|
2021-04-16 12:55:24 +00:00
|
|
|
Block $block,
|
2019-10-20 00:04:00 +00:00
|
|
|
$language = null
|
|
|
|
|
) {
|
2022-12-05 20:37:13 +00:00
|
|
|
$language ??= $this->getLanguage();
|
2019-10-20 00:04:00 +00:00
|
|
|
|
2021-04-16 12:55:24 +00:00
|
|
|
$blocker = $block->getBlocker();
|
|
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
$vals = [];
|
|
|
|
|
$vals['blockid'] = $block->getId();
|
2021-04-16 12:55:24 +00:00
|
|
|
$vals['blockedby'] = $blocker ? $blocker->getName() : '';
|
|
|
|
|
$vals['blockedbyid'] = $blocker ? $blocker->getId() : 0;
|
2019-10-20 00:04:00 +00:00
|
|
|
$vals['blockreason'] = $block->getReasonComment()
|
|
|
|
|
->message->inLanguage( $language )->plain();
|
2019-04-29 07:47:31 +00:00
|
|
|
$vals['blockedtimestamp'] = wfTimestamp( TS_ISO_8601, $block->getTimestamp() );
|
2021-12-02 16:27:31 +00:00
|
|
|
$expiry = ApiResult::formatExpiry( $block->getExpiry(), 'infinite' );
|
|
|
|
|
$vals['blockexpiry'] = $expiry;
|
2019-04-29 07:47:31 +00:00
|
|
|
$vals['blockpartial'] = !$block->isSitewide();
|
2020-08-20 20:48:21 +00:00
|
|
|
$vals['blocknocreate'] = $block->isCreateAccountBlocked();
|
2020-10-02 14:28:10 +00:00
|
|
|
$vals['blockanononly'] = !$block->isHardblock();
|
2023-05-28 09:50:24 +00:00
|
|
|
if ( $block instanceof AbstractBlock ) {
|
|
|
|
|
$vals['blockemail'] = $block->isEmailBlocked();
|
|
|
|
|
$vals['blockowntalk'] = !$block->isUsertalkEditAllowed();
|
|
|
|
|
}
|
2020-08-20 20:48:21 +00:00
|
|
|
|
2021-12-02 16:27:31 +00:00
|
|
|
$user = $this->getUser();
|
|
|
|
|
// Formatted timestamps
|
|
|
|
|
$vals['blockedtimestampformatted'] = $language->formatExpiry(
|
|
|
|
|
$block->getTimestamp(), true, 'infinity', $user
|
|
|
|
|
);
|
|
|
|
|
if ( $expiry !== 'infinite' ) {
|
|
|
|
|
$vals['blockexpiryformatted'] = $language->formatExpiry(
|
|
|
|
|
$expiry, true, 'infinity', $user
|
|
|
|
|
);
|
|
|
|
|
$vals['blockexpiryrelative'] = $language->getHumanTimestamp(
|
|
|
|
|
new MWTimestamp( $expiry ), new MWTimestamp(), $user
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
Separate Block into AbstractBlock, Block and SystemBlock
This commit splits the existing Block class into AbstractBlock, Block
and SystemBlock.
Before this patch, the Block class represents several types of
blocks, which can be separated into blocks stored in the database,
and temporary blocks created by the system. These are now
represented by Block and SystemBlock, which inherit from
AbstractBlock.
This lays the foundations for:
* enforcing block parameters from multiple blocks that apply to a
user/IP address
* improvements to the Block API, including the addition of services
Breaking changes: functions expecting a Block object should still
expect a Block object if it came from the database, but other
functions may now need to expect an AbstractBlock or SystemBlock
object. (Note that an alternative naming scheme, in which the
abstract class is called Block and the subclasses are DatabaseBlock
and SystemBlock, avoids this breakage. However, it introduces more
breakages to calls to static Block methods and new Block
instantiations.)
Changes to tests: system blocks don't set the $blockCreateAccount or
$mExipry block properties, so remove/change any tests that assume
they do.
Bug: T222737
Change-Id: I83bceb5e5049e254c90ace060f8f8fad44696c67
2019-03-18 22:09:49 +00:00
|
|
|
if ( $block instanceof SystemBlock ) {
|
2019-04-29 07:47:31 +00:00
|
|
|
$vals['systemblocktype'] = $block->getSystemBlockType();
|
|
|
|
|
}
|
2020-08-20 20:48:21 +00:00
|
|
|
|
Support new block schema
Support migration stages when reading and writing blocks.
I tried to set it up for an easy next stage, in which support for the
old schema is removed. I tried to avoid factoring out of shared code
between the two schemas, so that the old schema cases can simply be
deleted without the need to revert unnecessary abstractions.
However, I added HideUserUtils to factor out ipb_deleted queries. Code
review showed that this was already quite complex, with multiple
approaches to the problem, so it benefits from refactoring even without
the schema abstraction.
HideUserUtils is a service rather than a standalone class to support
unit tests, since unit tests do not allow global config access. When
the migration stage config is removed, it will be a service with no
constructor parameters -- an unnecessary abstraction which should
ideally be resolved at that time.
When interpreting result rows, it is possible to share code by using
field aliases. But when constructing WHERE conditions, the actual field
names need to be used, so the migration is more intrusive in
ApiQueryBlocks and SpecialBlockList, where complex conditions are used.
Bug: T346293
Bug: T51504
Bug: T349883
Change-Id: I408acf7a57b0100fe18c455fc13141277a598925
2023-10-27 03:34:10 +00:00
|
|
|
if ( $block instanceof CompositeBlock ) {
|
|
|
|
|
$components = [];
|
|
|
|
|
foreach ( $block->getOriginalBlocks() as $singleBlock ) {
|
|
|
|
|
$components[] = $this->getBlockDetails( $singleBlock, $language );
|
|
|
|
|
}
|
|
|
|
|
$vals['blockcomponents'] = $components;
|
|
|
|
|
}
|
|
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
return $vals;
|
|
|
|
|
}
|
|
|
|
|
|
2023-04-25 19:33:42 +00:00
|
|
|
/**
|
|
|
|
|
* Get the API error code, to be used in ApiMessage::create or ApiBase::dieWithError
|
|
|
|
|
* @param Block $block
|
|
|
|
|
* @return string
|
|
|
|
|
*/
|
|
|
|
|
private function getBlockCode( Block $block ): string {
|
|
|
|
|
if ( $block instanceof DatabaseBlock && $block->getType() === Block::TYPE_AUTO ) {
|
|
|
|
|
return 'autoblocked';
|
|
|
|
|
}
|
|
|
|
|
return 'blocked';
|
|
|
|
|
}
|
|
|
|
|
|
Improve custom folding and grouping
PHPStorm can use custom folding regions defined in either the
VisualStudio style or the NetBeans style. The VisualStudio style is more
pleasing to the eye and also works as a vim foldmarker. So get rid of
the previous vim foldmarkers, and use region/endregion.
region/endregion need to be in a single-line comment which is not a doc
comment, and the rest of the comment is used as a region heading (by
both PHPStorm and vim). So to retain Doxygen @name tags, it is
necessary to repeat the section heading, once in a @name and once in a
region. Establish a standard style for this, with a divider and three
spaces before the heading, to better set off the heading name in plain
text.
Besides being the previous vim foldmarker, @{ is also a Doxygen
grouping command. However, almost all prior usages of @{ ... @} in this
sense were broken for one reason or another. It's necessary for the @{
to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of
the individual members in the group are separately documented.
@name alone is sufficient to create a Doxygen section when the sections
are adjacent, but if there is ungrouped content after the section, it
is necessary to use @{ ... @} to avoid having the Doxygen group run on.
So I retained, fixed or added @{ ... @} in certain cases.
I wasn't able to test the changes to the trait documentation in Doxygen
since trait syntax is not recognised and the output is badly broken.
Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
|
|
|
// region Methods required from ApiBase
|
|
|
|
|
/** @name Methods required from ApiBase
|
2019-10-20 00:04:00 +00:00
|
|
|
* @{
|
|
|
|
|
*/
|
|
|
|
|
|
2019-12-29 11:06:17 +00:00
|
|
|
/**
|
|
|
|
|
* @see IContextSource::getLanguage
|
|
|
|
|
* @return Language
|
|
|
|
|
*/
|
2019-10-20 00:04:00 +00:00
|
|
|
abstract public function getLanguage();
|
|
|
|
|
|
2021-12-02 16:27:31 +00:00
|
|
|
/**
|
|
|
|
|
* @see IContextSource::getUser
|
|
|
|
|
* @return User
|
|
|
|
|
*/
|
|
|
|
|
abstract public function getUser();
|
|
|
|
|
|
2020-01-09 23:55:13 +00:00
|
|
|
/** @} */
|
Improve custom folding and grouping
PHPStorm can use custom folding regions defined in either the
VisualStudio style or the NetBeans style. The VisualStudio style is more
pleasing to the eye and also works as a vim foldmarker. So get rid of
the previous vim foldmarkers, and use region/endregion.
region/endregion need to be in a single-line comment which is not a doc
comment, and the rest of the comment is used as a region heading (by
both PHPStorm and vim). So to retain Doxygen @name tags, it is
necessary to repeat the section heading, once in a @name and once in a
region. Establish a standard style for this, with a divider and three
spaces before the heading, to better set off the heading name in plain
text.
Besides being the previous vim foldmarker, @{ is also a Doxygen
grouping command. However, almost all prior usages of @{ ... @} in this
sense were broken for one reason or another. It's necessary for the @{
to be in a doc comment, and DISTRIBUTE_GROUP_DOC doesn't work if any of
the individual members in the group are separately documented.
@name alone is sufficient to create a Doxygen section when the sections
are adjacent, but if there is ungrouped content after the section, it
is necessary to use @{ ... @} to avoid having the Doxygen group run on.
So I retained, fixed or added @{ ... @} in certain cases.
I wasn't able to test the changes to the trait documentation in Doxygen
since trait syntax is not recognised and the output is badly broken.
Change-Id: I7d819fdb376c861f40bfc01aed74cd3706141b20
2020-12-22 23:52:00 +00:00
|
|
|
// endregion -- end of methods required from ApiBase
|
2019-10-20 00:04:00 +00:00
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
}
|
2024-09-25 16:17:29 +00:00
|
|
|
|
|
|
|
|
/** @deprecated class alias since 1.43 */
|
|
|
|
|
class_alias( ApiBlockInfoTrait::class, 'ApiBlockInfoTrait' );
|