Change Details

To people working with the MediaWiki API, exposing an `actor_id` field (as a `prop` of various lists, as a parameter of various actions currently accepting a `user`, etc.) would be useful for some of the same reasons as detailed in T167246 for MediaWiki internally: mainly, that we wouldn’t need as much storage space to manage information on “ones who act on a wiki”, and could use plain 64-bit integers instead of variable-size `(user, user_id)` tuples. My concrete use case is that in the [SpeedPatrolling](https://tools.wmflabs.org/speedpatrolling/) tool, I want to maintain a list of users whose edits should not be shown to the tool user anymore. Since the tool is concerned with unpatrolled changes, those users will often be anonymous, so I can’t use the `user_id` alone. However, storage space in the user’s session is limited, so I can’t store as many users as `(user, user_id)` tuples as I could store `actor_id`s. (There are various ways to work around this, of course, we don’t need to get distracted discussing those – this is just supposed to be a motivating example.) (I don’t know if this is already planned as part of T188327 anyways, but I couldn’t find any reference to it on Phabricator, so I’m creating this task.)

To people working with the MediaWiki API, exposing an `actor_id` field (as a `prop` of various lists, as a parameter of various actions currently accepting a `user`, etc.) would be useful for some of the same reasons as detailed in T167246 for MediaWiki internally: mainly, that we wouldn’t need as much storage space to manage information on “ones who act on a wiki”, and could use plain 64-bit integers instead of variable-size `user` (name) strings or `(user, user_id)` tuples. My concrete use case is that in the [SpeedPatrolling](https://tools.wmflabs.org/speedpatrolling/) tool, I want to maintain a list of users whose edits should not be shown to the tool user anymore. Since the tool is concerned with unpatrolled changes, those users will often be anonymous, so I can’t use the `user_id` alone. However, storage space in the user’s session is limited, so I can’t store as many users as `user` strings or `(user, user_id)` tuples as I could store `actor_id`s. (There are various ways to work around this, of course, we don’t need to get distracted discussing those – this is just supposed to be a motivating example.) (I don’t know if this is already planned as part of T188327 anyways, but I couldn’t find any reference to it on Phabricator, so I’m creating this task.)

To people working with the MediaWiki API, exposing an `actor_id` field (as a `prop` of various lists, as a parameter of various actions currently accepting a `user`, etc.) would be useful for some of the same reasons as detailed in T167246 for MediaWiki internally: mainly, that we wouldn’t need as much storage space to manage information on “ones who act on a wiki”, and could use plain 64-bit integers instead of variable-size `user` (name) strings or `(user, user_id)` tuples. My concrete use case is that in the [SpeedPatrolling](https://tools.wmflabs.org/speedpatrolling/) tool, I want to maintain a list of users whose edits should not be shown to the tool user anymore. Since the tool is concerned with unpatrolled changes, those users will often be anonymous, so I can’t use the `user_id` alone. However, storage space in the user’s session is limited, so I can’t store as many users as `user` strings or `(user, user_id)` tuples as I could store `actor_id`s. (There are various ways to work around this, of course, we don’t need to get distracted discussing those – this is just supposed to be a motivating example.) (I don’t know if this is already planned as part of T188327 anyways, but I couldn’t find any reference to it on Phabricator, so I’m creating this task.)