This PR fixes the three issues in the nav bar:
1. The GitHub icon was rendered in black in light mode. It should be
white.
2. The toggle theme button's background was white in light mode. It
should be a darker green.
3. The navbar would intersect with the logo due to not compacting
correctly.
The first two issues were caused by using CSS nesting, which is
apparently not supported in Safari yet (and might only be supported if
you have enabled a flag in other browsers).
The last issue was fixed by changing the syntax of a media query. The
new syntax is unsupported in Safari.
Improving the email template design
- @andreas-unleash i need you to fix the button for the change request
in case it's not correct like this
- also removing some leftover style from the "scheduled change conflict"
email
---------
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
## Key Updates in the ADR
- **Separation of Migrations in PRs**: Migrations are now required to be
carried out in separate pull requests. This change is intended to
improve the monitoring and management of database schema changes during
deployment.
- **Primary Key Requirement for New Tables**: A new paragraph mandates
the inclusion of primary keys in all new tables, emphasizing the
importance of data integrity, efficient data retrieval, and supporting
table relationships. Additionally, by adding primary keys, we resolve
the issue of migrations failing during upgrades in replicated database
setups, as we are not using PostgreSQL replica identities. Exceptions to
this rule require a compelling justification.
Also added better structuring and styling to ADR for better readability.
We were sending `user.id` to the service, but if an admin token is used,
there is no `user.id.` Instead, there is
`user.internalAdminTokenUserId`. so we need to use the special method
`extractUserIdFromUser`.
This PR adds this implementation, and now the service correctly
retrieves the appropriate ID for admins.
Related to: https://github.com/Unleash/unleash/pull/5924
Added conflict count to CR metrics and CR id.
Something to think about:
There was idea that we can aggregate this data based on CR id, but CR id
is just a number from 0 to x. So it will not be unique across instances.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
## About the changes
Schedules a best-effort task setting the value of
events.created_by_user_id based on what is found in the created_by
column and if it's capable of resolving that to a userid/a system id.
The process is executed in the events-store, it takes a chunk of events
that haven't been processed yet, attempts to join users and api_tokens
tables on created_by = username/email, loops through and tries to figure
out an id to set. Then updates the record.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
Update the Unleash docs navbar according to the new spec:
Changing "estimated time burden" to "estimated time" (or "estimated
reading time"), is just a matter of changing the text in the files.
There's nothing special making it say burden other than plain text. That
can be done in a follow-up PR.
The new nav bar includes the Unleash academy and certification dropdowns
as well as the docs and quickstart items. On smaller screen sizes
(between 997 and 1150 px), we hide the word "Unleash" from "Unleash
academy" and "Unleash certification".
The narrowest nav bar:
When Unleash pops back in:
---------
Co-authored-by: markunl <mark@getunleash.io>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
- Simplified wording
- More descriptive ALT text for images
- Included YouTube tutorial link
- Improve code indentation in some code blocks
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
YouTube link at the top of a tutorial or near the bottom?
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
## About the changes
Change the sorting of features to migrate created_by_user_id for, and
filter out unresolvable feature/users
Query tested manually in enterprise
## About the changes
Resets created_by_user_id on events incorrectly marked as -1337 when an actual user has been set in created_by column, to clean up after a bug
## About the changes
Sets data migration of features and events created_by_user_id to
disabled by default
Map to promise and await all in created by user id migration for features
Includes some small fixes and improvements to the actions table UI:
- Fix webhook icon not properly loading
- Make actions execution param names bold in the tooltip
- Make filters param names bold in the tooltip
This escape with `??` double escaped the LIKE query causing no results.
This updates to using whereLike, which does the correct escaping for
string query.
## About the changes
Adds a scheduled task that every 5 seconds updates 500 entries in the
features table setting `created_by_user_id`.
It does this by looking at the related event, checks created_by and
joins users table for match on username or email, and joins api_tokens
table on username matches. Then picks either a users id if set, or uses
-42 (admin token user)
## About the changes
This PR replaces the old systemUser -1 in user-service.ts with the new
SYSTEM_USER -1337 and adds a migration to move events created_by = -1 to
-1337
## Discussion points
Does it make sense to do both of these things? Or should we skip the
migration? How would this behave in a large system with hundreds of
thousands of events, should this be split up?
