Added a new common.ConfigurableTransport interface which mediabrowser,
ombi, jellyseer, discord, telegram and matrix (i.e.
ThirdPartService/ContactMethodLinker) now all implement. proxies are
bound to them in main.go, Email is still a special case (but from the
previous commit, mailgun does use the proxy).
mautrix/go has been updated, and context.TODO()s stuck everywhere since
I still don't really comprehend why I should use them (FIXME literally).
jellyseerr already did this, but it's been standardised a little more.
Mediabrowser uses it's own genericErr function and error types due to
being a separate package, while jellyseerr and ombi now share errors
defined in common/.
single req() function is wrapped by methods for each http method, and
error messages are parsed and returned if given by the server.
also added note about Jellyseerr's enforcement of unique email addresses
in settings.
"import_existing" option in settings enables an every 5-minute daemon
which loops through users and imports them to Jellyseerr and copies
contact info, if necessary. Also sets new API client flag
AutoImportUsers, which decides whether to automatically import non-existent users in
it's various methods.
also cleaned up the various daemons in the software, most now using the
GenericDaemon struct and just providing a new constructor.
broken page loop in jellyseerr client also fixed.
added in the same way as ombi profiles. Most code is copy-pasted and
adjusted from ombi (especially on web), so maybe this can be merged in
the future. Also, profile names are url-escaped like announcement
template names were not too long ago. API client has "LogRequestBodies"
option which just dumps the request body when enabled (useful for
recreating reqs in the jellyseerr swagger UI). User.Name() helper
returns a name from all three possible values in the struct.
addded permissions get/set before realizing it already comes as part of
the User object. Split User attributes that will be templated into
UserTemplate struct, which User inherits. ApplyTemplateToUser takes a
UserTemplate, while ModifyUser takes a plain map with some typed fields
(display name and email, for now).
Currently uses an API key (Seems simpler for the user than importing the
jfa-go user and granting perms). Strategy as follows:
* MustGetUser(jfID) function checks the cache for user, if not, calls
Jellyseerr's importer passing jfID. From either, the user object is
returned, which (in later commits) can be used to update the user's
email (and potentially other info).
My API key is in there rn but its for a local testing instance, who
cares.
Harvey Tindall