Search your Bitwarden audit log and check leavers in plain English

Build me an investigation console over my Bitwarden organization's event log. Bitwarden's built in reporting only lets me scroll a date range, and the event types come back as integer codes while actors and targets come back as GUIDs, so the screen is useless as it stands. The entire point of this app is to turn that raw log into readable history I can actually search.

The main view is a search over List Events with filters for member, date range and event type. Render every row as a plain English sentence with its timestamp, for example "Priya Nair viewed an item in the Finance collection" or "Tom Reilly was removed from the Engineering group". Keep the underlying event type code available in a details panel for anyone who wants it, but never let it be the primary thing on screen.

To make those rows readable, load List Members, List Groups and List Collections when the app opens and build lookup maps from id to display name. Resolve the acting user id to a real person with their name and email, and resolve the target id to a collection name, group name or member name depending on which field the event carries. Maintain a mapping from Bitwarden's integer event type codes to human phrasing, covering at least logins and failed logins, item created, updated, deleted and viewed, password viewed, collection and group changes, member invited, confirmed, updated, revoked, restored and removed, and policy updates. When an id cannot be resolved because the object was deleted, say so plainly, for example "a collection that no longer exists", rather than falling back to a bare id.

From any row I want to open a per person timeline. Clicking the actor opens a view scoped to that one person, showing their events in chronological order across whatever date range I pick, with a summary at the top: how many events, which collections and groups they touched, and when they were first and last active.

Add a leaver check mode. I pick someone whose status is revoked, or who no longer appears in the member list at all, and the app shows me everything they touched in their final thirty days of activity, ending at their last recorded event. Highlight the things that deserve a second look, such as password views, item exports, unusual bursts of item access and collection membership changes, so I can sign off their offboarding with confidence. Let me change the thirty day window to match our policy.

Let me select rows anywhere in the app with checkboxes and save the selection as an evidence pack to a Google Sheet using Append Values. Each appended row should carry the timestamp, the resolved actor name and email, the readable event description, the resolved target, the underlying event type code, and the device or IP address when the event includes one. Ask me which spreadsheet and tab to append to, and confirm how many rows were written.

From that same selection, let me raise a follow up ticket in Jira Service Management using Create Customer Request, with the timeline written into the description as a readable chronological list. Include who the investigation is about and the date range it covers, let me edit the summary and description before anything is created, and show me the resulting ticket key afterwards.

Two Bitwarden constraints need to be handled in the interface rather than hidden. First, only 367 days can be queried in a single date range even though the data is retained indefinitely, so validate my date range and tell me plainly when I have asked for more than that. Second, List Events pages through a continuationToken that comes back null on the last page, so page through it automatically and show loading progress rather than silently returning only the first page. On top of that, client side events take about a minute to reach the server, so whenever my range includes the last few minutes, show a small notice that the most recent minutes may still be catching up.

This is a pull tool, something I open when I have a specific question, so do not frame it as a digest or an alerting surface. It must never write anything back to Bitwarden. Note somewhere in the app that event logs require a Teams or Enterprise Bitwarden organization.