Allow configuration of invitation org name when inviting users #1838

New Issue

OVERLORD · 2025-10-09T17:32:23+03:00

OVERLORD commented

2025-10-09 17:32:23 +03:00

Originally created by @aroberts on GitHub.

Subject of the issue

Inviting users via email results in a reference to a "bitwarden_rs" organization. This is turning out to be confusing to my users - it would be great if I could configure that string to be something else.

It looks like the string is hardcoded at src/api/admin.rs:164:

        let org_name = "bitwarden_rs";
        mail::send_invite(&user.email, &user.uuid, None, None, &org_name, None)

I think just being able to set this string via environment variables would solve my problem.

Your environment

Bitwarden_rs version: 1.13.1

Install method: docker

Originally created by @aroberts on GitHub.  ### Subject of the issue  Inviting users via email results in a reference to a "bitwarden_rs" organization. This is turning out to be confusing to my users - it would be great if I could configure that string to be something else. It looks like the string is hardcoded at `src/api/admin.rs:164`: ```rust let org_name = "bitwarden_rs"; mail::send_invite(&user.email, &user.uuid, None, None, &org_name, None) ``` I think just being able to set this string via environment variables would solve my problem. ### Your environment  * Bitwarden_rs version: 1.13.1  * Install method: docker

OVERLORD closed this issue

2025-10-09 17:32:24 +03:00

OVERLORD commented

2025-10-09 17:32:25 +03:00

@aroberts commented on GitHub:

I'd vote for a separate var, but it would be great to default the new var's value to SMTP_FROM_NAME if left blank/unset

@aroberts commented on GitHub: I'd vote for a separate var, but it would be great to default the new var's value to SMTP_FROM_NAME if left blank/unset

OVERLORD commented

2025-10-09 17:32:25 +03:00

@dani-garcia commented on GitHub:

Sounds reasonable to me. Should we use the already existing SMTP_FROM_NAME as it serves a similar purpose? Or create a separate option?

@dani-garcia commented on GitHub: Sounds reasonable to me. Should we use the already existing SMTP_FROM_NAME as it serves a similar purpose? Or create a separate option?

OVERLORD commented

2025-10-09 17:32:26 +03:00

@dani-garcia commented on GitHub:

Fixed, decided on creating a separate independent option to avoid making the configuration logic more complex than needed.

@dani-garcia commented on GitHub: Fixed, decided on creating a separate independent option to avoid making the configuration logic more complex than needed.

OVERLORD referenced this issue

2025-10-09 18:21:55 +03:00

[PR #1838] Expose $ROCKET_PORT instead of 80 #3358

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1838