When unable to connect to a service, we no longer send a confusing
message saying capabilities could not be obtained. This also involved
removing nullability in a few places to simplify logic an error
handling.
The reason for this is to avoid the need for `--no-same-owner` when
extracting the archive as a super user (e.g. `sudo`). Without this
change, the UID and GID of `recyclarr` after it is extracted is whatever
user was used in github actions to create the archive, which isn't
really useful.
This change does not affect extractions as normal users; by default, the
UID/GID inside the archive is not used in those cases.
This version of `System.IO.Abstractions` adds constructor options to
`MockFileSystem` that allows the removal of a hack put in place to
remove the temp directory so it does not interfere with unit test
expectations.
When qualities are not specified by the user, qualities are not modified
if the profile exists in the service. If the profile does not exist yet,
then an error is shown. Qualities are required when the profile is being
created.
The `qualityprofile` API still performs validation on `cutoff` even when
`upgradeAllowed` is set to `false`. Because of this, we must still set
`cutoff` even if the user didn't specify `upgrade_allowed` and
`until_quality` in their configs. We do so by finding the first item in
the Items list, regardless of what that is. This fixes the HTTP 400 we
get when invoking the API with a `null` value for `cutoff`.
The assignment logic in the DTO objects changes the end result of what
gets synced. The preview and stat logic now first assigns config values
to the old DTO object to get a more accurate preview of what the new
values will be.
Initial implementation with sync support for the following fields:
- Name
- Upgrade Allowed
- Min Format Score
- Cutoff
- Cutoff Format Score
- Items
Quality profiles are always created if they are defined under
`quality_profiles` at the top-level. Within a quality profile
configuration, Recyclarr will not modify quality profile fields if those
corresponding properties in the config are omitted.
Previously, the exception stack trace was omitted to simplify the
console output. However, some situations occurred where an exception was
logged but I couldn't tell where it came from. This made certain rare
bugs impossible to fix.
My philosophy at this point is: If something exceptional happens, we
don't really care about a "clean" console output anymore...
Robert Dailey