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
As part of the task to make it possible to send notifications to
approvers for a CR, this PR adds a table that can link users to CRs
they've been requested to make an approval for.
Migrate from make-fetch-happen to ky
## Summary:
- Replaced all usages of make-fetch-happen with
[ky](https://github.com/sindresorhus/ky) for HTTP requests.
- Upgraded nock to v14 so it's capable of mocking native fetch
implementation
- Removed the make-fetch-happen dependency
- Ensured all fetch logic is compatible with ky API.
## Why:
- ky provides a modern, lightweight, and promise-based HTTP client with
a simpler API.
- Reduces dependencies and simplifies codebase.
## Testing:
We'll do testing in sandbox environment of the modified functionality
(which is not much) and we also rely on automated testing.
---------
Co-authored-by: Simon Hornby <simon@getunleash.io>
#10121 points out that we're using md5 functions still. This PR updates
our migrations to no longer use md5 at all (so if you haven't run the
migrations, you won't get email hashes until you get to the included
migration with this PR). If you've already run the migrations, we'll
drop the existing `email_hash varchar(32)` column and replace it with a
`email_hash TEXT` column.
We're also replacing the md5 function with `encode(sha256(email),
'hex')`. encode has been supported since PG10, sha256 came with PG11.
Do we want an index on the email_hash? I wasn't sure, but if we want to
do lookup we probably should have an index on it (though not a unique
one)
Made a few QoL improvements:
- Don't use default export for class
- Move users store to a feature package (didn't move the interface as it
might be referenced elsewhere)
- Add types for query builders (and ts-expect-error when needed)
Removes all usages of flag addEditStrategy and refactors code where
necessary.
This is only the first step of the cleanup. After this, there's still
lots of code to be removed. I've got a different PR that removes ~5k
lines of code (https://github.com/Unleash/unleash/pull/10105) that I
want to reach in pieces to make sure that everythnig works on the way
there.