mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 01:35:54 +03:00
[GH-ISSUE #245] Support for groups #122
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#122
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ptman on GitHub (Nov 9, 2018).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/245
https://help.bitwarden.com/article/groups/
@dani-garcia commented on GitHub (Nov 9, 2018):
I'm not sure if I'm missing something, but I don't see any difference between this and organizations.
Instead of having an organization with multiple groups, you can create multiple organizations, and it serves the same purpose, it seems.
For now I'll mark this as low priority, and if someone wants to help implement it, I'll merge it.
@dani-garcia commented on GitHub (Nov 9, 2018):
To keep the issue tracker more focused, I'm closing this issue in favor of the meta issue at #246.
@miko007 commented on GitHub (Jun 21, 2019):
this meta issue thing is kind of a stupid idea. i can not really focus on the "groups" discussion, because all topics are mixed up in issue #246.
group support is essential for the use of this implementation in organisations. has there been any progress been made on this topic?
the "multiple organisations" workaround has the major downside, that datasets can not be shared between organisation. one has to keep track of all the likewise entries in all organisations and keep them synchronized. i do not think, that this is of "low priority".
@dani-garcia commented on GitHub (Jun 21, 2019):
There hasn't been any progress in the groups functionality and unless someone steps up to implement it there won't be any, as I have zero interest in implementing this.
If you need to share entries between organizations, create a new organization for all the users that need the shared entries. If your organization is so big that doing that becomes unworkable, you probably have enough resources to deploy the official server, and then you'll have your groups.
My vision of bitwarden_rs is focused on small to medium deployments, where the implementation of groups really is "low priority".
PD: In the future I'd refrain from calling things stupid, there is no need for that language here, we are all volunteering our time for free, you might not like our ideas, but as a minimum they deserve a little respect.
@miko007 commented on GitHub (Jul 16, 2019):
Well, it seems you totally got me on the wrong foot there. First, i can not see in which relation calling an idea stupid stands to any form of respect for people. I just put out my opinion, and in that, the idea is stupid. Does not have anything to do with you, nor other people contributing to the project.
Next, our company, which has round about 25 employees has a "medium deployment", i think. We already have the official server deployed an we also pay for every single license. This is not the point here. I thought, i would bring some insights from your target audience to this open project.
And from an administrators point of view, i want to tell you, that groups are a feature, which is used quite often, and makes life so much easier.
We have for example interns, which only should be able to look at the "read-only" accounts. We have developers, which need to see all the administration datasets as well as the "read-only" ones, an so forth.
Splitting all this up into different organizations would mean, those datasets can not coexist inside the same collection, as collections are organization bound, and therefore would be difficult to find.
I hope, at least somebody can relate.
love and respect. Mike.
@aiveras commented on GitHub (Jul 20, 2019):
We are also an SME and would need this feature. Especially in combination with LDAP group policies are necessary to scale a company.
If you have to create a new organization for each group, it also complicates maintaining passwords. That's why I can only agree with @miko007 that this is a basic feature and has nothing to do with the size of a company or the willingness to buy. Especially in the sensitive area of passwords, a filigree identity management is almost equally weighted with the security of the password storage. After all, most leaks are not caused by technical errors but by people passing them on. For this reason, and I think every system administrator can confirm this, the lowest access rights are always granted in IT systems to protect data sovereignty.
@ptman commented on GitHub (Jul 21, 2019):
While I agree, that organizations and collections make groups a nice-to-have instead of a must-have, groups are most likely very nice once you have enough users.
@sangdrax8 commented on GitHub (Jan 14, 2021):
Ouch, I didn't realize groups were missing. This could actually strongly relate to issues implementing the ldap-connector support I was looking at. Pulling in groups from LDAP becomes a moot point if groups don't exist on the server side to sync them to.
@lethargosapatheia commented on GitHub (Apr 23, 2021):
I find the statement a little bit bewildering. The point is, of course, to be able to add a group of users to a collection, instead of each individual user. What if you've got 50 people in one team and you want to share a collection with them?
Instead of adding the group, you have to click 50 times, basically. Having 50 people in one team doesn't mean you're a huge company. Creating another yet organisation doesn't make any sense in so many cases and doesn't make things easier.
That you don't want to because you think there's too much effort to be made or don't have the time or whatever is understandable. That you think this is useless functionality for small/medium companies is quite disconcerting.
@pepa65 commented on GitHub (Apr 23, 2021):
In our organization, we didn't see the need for organizations, and we thought it would be confusing to our users, so we called them "groups". But the functionality is actually not the same, and having groups to me is much more interesting that having organizations (even if they are called "groups"...).
@BlackDex commented on GitHub (Apr 23, 2021):
Any well written PR would be welcome.