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
|
|
|
|
|
*/
|
|
|
|
|
|
2021-04-16 12:55:24 +00:00
|
|
|
use MediaWiki\Block\Block;
|
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;
|
|
|
|
|
|
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
|
|
|
|
|
*/
|
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();
|
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
|
|
|
|
2019-04-29 07:47:31 +00:00
|
|
|
return $vals;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
}
|