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 new `blockid` param// If set then the block with this id is updated with the new data. No need for a username/ip //Request with no new `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 --- Previous //Modifying an existing block:// * Accept a `blockid` parameter, which tells the backend to apply all other parameters to that specific block * Providing //only// a block ID is acceptable; You should not have to also specify a username. ** If both a blockid and username are provided, and there's a mismatch, error out with a detailed message. This is because the API is used for automation, and there's no way to require "confirmation" as we can for T378140 and T378144. //Adding a new block to a user:// * Accept a `newblock` boolean parameter, that tells the backend to apply all other parameters to a //new// block for the given user //Possible new validations and errors..:// * What if you try to modify or add a block and the details are //identical// to an existing block? That should probably error out.

**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 new `blockid` param// If set then the block with this id is updated with the new data. No need for a username/ip //Request with no new `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) --- Previous //Modifying an existing block:// * Accept a `blockid` parameter, which tells the backend to apply all other parameters to that specific block * Providing //only// a block ID is acceptable; You should not have to also specify a username. ** If both a blockid and username are provided, and there's a mismatch, error out with a detailed message. This is because the API is used for automation, and there's no way to require "confirmation" as we can for T378140 and T378144. //Adding a new block to a user:// * Accept a `newblock` boolean parameter, that tells the backend to apply all other parameters to a //new// block for the given user //Possible new validations and errors..:// * What if you try to modify or add a block and the details are //identical// to an existing block? That should probably error out.

**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 new `blockid` param// If set then the block with this id is updated with the new data. No need for a username/ip //Request with no new `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) --- Previous //Modifying an existing block:// * Accept a `blockid` parameter, which tells the backend to apply all other parameters to that specific block * Providing //only// a block ID is acceptable; You should not have to also specify a username. ** If both a blockid and username are provided, and there's a mismatch, error out with a detailed message. This is because the API is used for automation, and there's no way to require "confirmation" as we can for T378140 and T378144. //Adding a new block to a user:// * Accept a `newblock` boolean parameter, that tells the backend to apply all other parameters to a //new// block for the given user //Possible new validations and errors..:// * What if you try to modify or add a block and the details are //identical// to an existing block? That should probably error out.