Change Details

**Background** The Block API currently assumes `$wgEnableMultiBlocks` is false, and provides no means to modify a specific block, and a means to //add// an additional block to a user. For the Unblock API, see T378148. **Acceptance criteria** //Request with `blockid` param// If set then the block with this id is updated with the new data. No need for a username/ip. If the block id doesn't exist, error If `newblock` or `reblock` is passed, error //Request with no `blockid` param// If no block exists for the user, then add a new block If **one** block exists for the user **and** the `reblock` param is true, update the user's block If **>=1** blocks exist for the user and the `newblock` param is unset, error If **>=1** blocks exist for the user and the `newblock` param is set, add a new block If **>=1** blocks exist for the user and the `newblock` param is set, and an existing block with the identical details exists, error (nice to have) We need `reblock` for backward compatibility. We also need `newblock` for this, because otherwise 3rd-party users who are depending on getting an error when they add >1 block might inadvertently add multiple blocks when they didn't intend to

**Background** The Block API currently assumes `$wgEnableMultiBlocks` is false, and provides no means to modify a specific block, and a means to //add// an additional block to a user. For the Unblock API, see T378148. **Acceptance criteria** //Request with `blockid` param// If set then the block with this ID is updated with the new data. If a `user` param is also sent, error If the block ID doesn't exist, error If `newblock` or `reblock` is passed, error //Request with no `blockid` param// If no block exists for the user, then add a new block If **one** block exists for the user **and** the `reblock` param is true, update the user's block If **>=1** blocks exist for the user and the `newblock` param is unset, error If **>=1** blocks exist for the user and the `newblock` param is set, add a new block If **>=1** blocks exist for the user and the `newblock` param is set, and an existing block with the identical details exists, error (nice to have) We need `reblock` for backward compatibility. We also need `newblock` for this, because otherwise 3rd-party users who are depending on getting an error when they add >1 block might inadvertently add multiple blocks when they didn't intend to

**Background** The Block API currently assumes `$wgEnableMultiBlocks` is false, and provides no means to modify a specific block, and a means to //add// an additional block to a user. For the Unblock API, see T378148. **Acceptance criteria** //Request with `blockid` param// If set then the block with this idID is updated with the new data. If a `user` param is also sent, No need for a username/ip. error If the block idID doesn't exist, error If `newblock` or `reblock` is passed, error //Request with no `blockid` param// If no block exists for the user, then add a new block If **one** block exists for the user **and** the `reblock` param is true, update the user's block If **>=1** blocks exist for the user and the `newblock` param is unset, error If **>=1** blocks exist for the user and the `newblock` param is set, add a new block If **>=1** blocks exist for the user and the `newblock` param is set, and an existing block with the identical details exists, error (nice to have) We need `reblock` for backward compatibility. We also need `newblock` for this, because otherwise 3rd-party users who are depending on getting an error when they add >1 block might inadvertently add multiple blocks when they didn't intend to