I can't find where I documented this before, but the core problem that needs figuring out is how to actually connect the patrolled status which is attached to the revision with the audit log record when returning results from the /api/auditlogs/ endpoint. Toolhub really doesn't have an equivalent of Special:RecentChanges at the moment. What it has is much more like Special:Log.

I do agree that we need something better to make a patrolling work queue. I'm just not sure that we will be able to do that with /api/auditlogs/ and the UI screen that displays its output.

We had a team meeting where this issue was discussed. Below is a potential solution to this:

1. Create a new api endpoint from where the revision of all tools can be fetched (If it doesn't already exist).
2. Create a seperate view on the frontend that looks similar to the image below
   

Only signed-in users can view the page. user's with just the "user" privilege will see the revisions of all projects and lists that have editing permission on. oversighters and patrollers will be able to view the revision of all tools, filter through them, etc.

We have edit revisions for lists as well as tools. The backing database tracking for both is using django-reversion which also means that we can relatively easily query across both at the same time to produce a unified "edit stream" view based on the reversion.models.Version model.

I don't think that viewing the page needs to be limited to authenticated users, but I do agree that state changing actions (mark as patrolled, revert, undo) must be limited to authenticated users with appropriate system rights for each action.

In T286858#7617150, @bd808 wrote:

We have edit revisions for lists as well as tools. The backing database tracking for both is using django-reversion which also means that we can relatively easily query across both at the same time to produce a unified "edit stream" view based on the reversion.models.Version model.

I don't think that viewing the page needs to be limited to authenticated users, but I do agree that state changing actions (mark as patrolled, revert, undo) must be limited to authenticated users with appropriate system rights for each action.

if it is not restricted to only authenticated users, the new page is going to basically have the same function as audit log view for them (maybe this might confuse them?). I mean, whatever purpose the new page can serve to unauthenticated users can also be fulfilled by the audit log, so it seems like unnecessary repetition for unauthenticated users.

In T286858#7617183, @Raymond_Ndibe wrote:

if it is not restricted to only authenticated users, the new page is going to basically have the same function as audit log view for them (maybe this might confuse them?). I mean, whatever purpose the new page can serve to unauthenticated users can also be fulfilled by the audit log, so it seems like unnecessary repetition for unauthenticated users.

The MediaWiki version of this would be https://en.wikipedia.org/wiki/Special:Log == our audit log page and https://en.wikipedia.org/wiki/Special:RecentChanges == this new global revision page.

In MediaWiki edit actions for existing pages are not included in Special:Log. They are instead exposed in Special:RecentChanges. It would seem reasonable to me if Toolhub did the same thing once we have this new screen. By that I mean we could stop including information about updates to existing toolinfo records and lists on our audit log page once we have an edit activity page. There would be a small amount of content duplication in that the initial revisions of both toolinfo records and lists should show on the revision page and also show as item creation log events, but that mirrors the MediaWiki behavior and seems acceptable.

In T286858#7617131, @Raymond_Ndibe wrote:

We had a team meeting where this issue was discussed. Below is a potential solution to this:

1. Create a new api endpoint from where the revision of all tools can be fetched (If it doesn't already exist).
2. Create a seperate view on the frontend that looks similar to the image below
   

Only signed-in users can view the page. user's with just the "user" privilege will see the revisions of all projects and lists that have editing permission on. oversighters and patrollers will be able to view the revision of all tools, filter through them, etc.

It would make sense to factor out a "RevisionItem" component -- right now this UI element is used in the ListHistory and ToolHistory views; using it in a patrolling work queue would add a third view.

Inline with the outlined team focus for the next couple of months, I have started working on this.

Change 767256 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] api: create endpoint for recent revision changes for a more unified patrolling workflow

https://gerrit.wikimedia.org/r/767256

Change 767257 had a related patch set uploaded (by Raymond Ndibe; author: Raymond Ndibe):

[wikimedia/toolhub@main] ui: create ui for recent revision changes for a more unified patrolling workflow

https://gerrit.wikimedia.org/r/767257

Change 767256 merged by jenkins-bot:

[wikimedia/toolhub@main] api: add /api/recent/ endpoints for patrolling

https://gerrit.wikimedia.org/r/767256

Change 767257 merged by jenkins-bot:

[wikimedia/toolhub@main] ui: create ui for recent revision changes

https://gerrit.wikimedia.org/r/767257

Change 786342 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342

Change 786342 merged by jenkins-bot:

[operations/deployment-charts@master] toolhub: Bump container version to 2022-04-21-215651-production

https://gerrit.wikimedia.org/r/786342