ombi_template, configuration, displayprefs, and policy still stuck
around for the admin new user feature. They are now sourced from the
default profile, and eventually a feature to select the source (or no
source) will be added.
this was still used when creating a new user as admin for some reason.
template is now sourced from the default profile.
don't think there's a way to negate a query with badgerhold, so i can't
do "delete(not (where JellyfinID in <ExistingUsers>))", and the old
method of rebuilding the store is no longer possible.
migrating to badger, with the badgerhold frontend. So far, done:
* Announcements (small, for a quick test)
* Discord/Telegram/Matrix/Email
most interaction with badgerhold is done through the standard
Get<x>/Get<x>Key/Set<x>Key/Delete<x>Key. UserExists functions have been
added for email and matrix, and those and the original ones now use a
query against the database rather than sifting through every record.
I've tagged these searched fields as "index" for badgerhold, although this
definitely isn't used yet, and i'm not entirely sure if it'll be useful.
migrateToBadger is now in migrations.go, and a temporary config key
"migrated_to_badger" has been added, although it isn't being used yet,
migration is just running every time during development.
Low German/Saxon (NDS) is empty entirely, which caused discord lang
registration to error, so i've just filled in the name. Somebody
directly translated "English (US)" into italian instead of putting
Italian in italian, corrected that. Use some common sense!
functionality not done yet, just comitting here because there were lots
of adjustments to layout stuff, accomodating for most combinations of
card presence/size.
the user shouldn't know if the reset has actually been sent (i.e. if an
account with the given contact address exists), so the backend response
is always sent after 1 second.
realized half the info from the signup form wasnt being stored in the JWT
used to create the account after email confirmation, and instead of
adding them, the -whole request- from the browser is stored temporarily
by the server, indexed by a smaller JWT that only includes the invite
code. Someone complained on reddit about me storing the password in the
JWT a while back, and although security-wise that isn't an issue (only
the server can decrypt the token), it doesn't happen anymore. Happy?
An almost identical set of functions to the discord/telegram/matrix
storage ones is now used for accessing invites. No more
parallelism-related issues, yay. Need to do this for everything
eventually.
less external access to Discord/TelegramDaemon internals, will be easier
to keep user/admin-side uses functioning similarly. Also changed their
internal token stores to use a map, and store an expiry. verifiedTokens
is also now a map in telegram. Also fixed issue where token wasn't being
deleted after use on the user page.
also comes with a "style" attribute, to apply a color to the aside it's
shown in. Used in User Page/Messages to mention the customize button,
and on User page w/ a critical color to mention the jellyfin login
requirement.
