I found this method when running through the environment store that has
0 references. I also can't find any references to it in enterprise and
it's not in the interface. I think it's safe to remove.
## About the changes
Users could have been created in Unleash without a corresponding event
(a.k.a. audit log), due to a non transactional user insert
([fix](https://github.com/Unleash/unleash/pull/10327)). This could have
happened because of providing the wrong role id or some other causes
we're not aware of.
This amends the situation by inserting an event for each user that
exists in the instance (not deleted) and doesn't have it's corresponding
user-created event.
The event is inserted as already announced because this happened in the
past.
The event log will look like this (simulated the situation in local
dev):
```json
{
"id": 11,
"type": "user-created",
"createdBy": "unleash_system_user",
"createdAt": "2025-07-08T16:06:17.428Z",
"createdByUserId": null,
"data": {
"id": "6",
"email": "xyz@three.com"
},
"preData": null,
"tags": [],
"featureName": null,
"project": null,
"environment": null,
"label": "User created",
"summary": "**unleash_system_user** created user ****"
}
```
The main problem is we can't create the event in the past, so this will
have to do it
## About the changes
When inserting a user with an invalid role id, the user creation will
succeed but there will be no record in the audit log.
The API call returns a 400 misleading you to believe the user was not
created, but it actually was.
This makes the whole user creation transactional, so if something fails,
data will be in the right state.
## Testing
The e2e test was split in 2 scenarios, one with smtp and another one
without.
This test was added, and it was failing before adding the transaction,
because when fetching the users, the user was there, despite having
returned a 400 error in the API call:
80a2e65b6f/src/test/e2e/api/admin/user-admin.e2e.test.ts (L181-L204)
I noticed event search, as it is doing `ILIKE` search, is slow
sometimes. Lets get some statistics about it.
Meanwhile added timers for other interesting queries.
As the title says. This adds name and email of requester to CR approval
mails. This will hopefully have users complain to their coworkers rather
than Unleash if they get too many mails.
Simple 2 columns for event type and event id.
I thought about adding check for type, but decided to handle checking in
backend code.
Currently the types will be
1. transaction
2. change-request
And ID is ulid
This change adds the `crDiffView` flag to Unleash, potentially enabling
the new JSON diff tab in change request changes instead of the "view
json diff" hover functionality.
Adding this should allow us to only notify users that haven't been
notified before.
Necessary because the change_added event does not include a preData that
allowed us to diff requestedApprovers based on the event alone.
Also added a index on this column, since we're going to be using it to
filter.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Accepts the new impact metrics into the singleton registry and then does
nothing with them. If the relevant flag is off, the metrics are stripped
from the existing metrics data format and dropped on the floor
