Reviewed points

• changes are backward compatible
  _(the default value is the old static value, so there is no change at all by default)
• removed options are declared with mkRemovedOptionModule
  (no removed change)
• changes that are not backward compatible are documented in release notes
  (no such change)
• module tests succeed on darwin/linux
• options types are appropriate
• options description is set
• options example is provided
  (not provided, but .user options seem to not have examples in general)
• documentation affected by the changes is updated
  (no documentation for this package in manual)

Possible improvements

• Include package name in the added options, as existing descriptions for .user (and .group) options mention the name of the service. Suggestion: "User account under which Transmission runs.", as this pattern seems to be used a lot.

Comments

• I have just started trying to help review nixpkgs PRs, so this review should be taken with a grain of salt, as I may have misunderstood and missed things (I hope not).

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-already-reviewed/2617/54

Wanted to run a Transmission daemon under a different user than the default transmission.

Which user?

@pstch Thanks for your review! I've incorporated the change to the description you suggested.

@aanderse I'm running Transmission (together with Sonarr, Radarr and Jackett) in a NixOS container which also runs an OpenVPN client. My downloads directory is mounted from the host to the container and transmission is configured to run in an user account that is also present on the host system. I would have preferred a user mapping on the container level, but the OpenVPN client requires root.

@c0deaddict a system user account, or a regular user account for a person? I'm trying to head off people running systemd system level services as regular user accounts because services running as regular user accounts should usually be run as systemd user level services. We've run into some problems when people configure user options as their own account and I believe we'll run into more. There is no policy or preferred way to code something like this yet, so I can't point you in the right direction... I'm just trying to keep an eye out for more problems.

A system user account (named downloads), and in a group of which my user is also a member so that I can also access the files (it's running on my NAS). I get the issue, and am aware of systemd user services. It would be nice if there was a way to unify NixOS services and home-manager, so services defined here could also be run as systemd user level services from home-manager.

@timokau I wasn't meaning to imply I was against this PR. I have the thumbs up on the most recent reply to show my support. I think this change is fine and it's a bonus that the issue is understood by all involved here.