Then to call it Transfer and enable an Organization Owners (or other roll) to also Transfer it back to a individual Owner would solve it right?
Looks like they fixed this.
I just tried and if you select a shared item and un-check the selected collection the item disappeared from the shared organization account.
I’m afraid not. Look in “Unassigned” under “Collections” in the web vault, it’s still there.
I just did some testing and noticed something contradicting the logic of a transfer.
If the terminology is indeed “transfer” and ownership is given to the organisation, the user should not be able to delete the shared item, or the shared item should at least remain in the organisation.
But it looks to me that it is possible for the private user to delete the item from his/her own vault, making it disappear from the organisation without the owner/admin being aware.
It even looks like another user, not the creator of the item can delete it after it has been shared making it disappear from the organisation and the creator.
Is this the same for everyone?
Another missing feature that is keeping me from adopting this tool. As the “owner” of the item being shared, I need to maintain ownership of it and be able to unshare it as needed. Also, I need to be ensured that what I share cannot be deleted.
I get that I can create a collection that restricts capability but there needs to be a general ownership hierarchy.
In my opinion the terminology should be changed. Transfer seems reasonable and then it should be more cohesive.
For example; if I transfer the ownership to the organisation, the entry should not stay inside the private vault(an optional field to delete the private entry by transfer?).
Even better would be, that a copy should remain inside the private vault so there is no link between the entry in the organisation. or the link should be only indirect, so if the organisation or the user decide to delete the entry, the other one isn’t robbed of his entry.
which is made worse by the points of several others: that any user in the org can delete it from all other users, even though they do not own it. yes the org keeps it but all other users lose access.
@kspearrin your points are arguments for a proper share system, where ownership is not transferred and control is maintained by the creator allowing them to remove the access from others as they desire.
- not with a proper share system. because ownership does not transfer then it does not need to be tracked.
- in the case of actual transfer—which i think should remain an option—then a user should not be able to “claim” an item back.
- only the owner
it is only because bitwarden uses a transfer instead of share that those are issues at all. the real issue is not terminology, but that the system as built is not functional for the needs of the users.
example: some people move in together, roomy-A has a tv subscription service and is fine with letting the room-mates use the service as well. roomy-B already has a bitwarden account and suggests that everyone use that to let everyone access the subscription. roomy-A has been thinking about a password manager for a while but never gotten around to it; thinks this is the perfect time to start using one and is convinced by B that bitwarden is pretty awesome. all the room-mates get bitwarden and roomy-B creates an organization. roomy-A makes an entry updating the password to a “secure” password and “transfers” the account credentials to the org. things go swimmingly for a while, but whenever you put people in close proximity it is inevitable that tension occurs. the relationship sours and eventually all the room-mates move out. now because roomy-A never had to remember their “secure” password, when roomy-B removes it from the collection in the org they own and control exclusively, they have effectively locked out roomy-A from their own account. roomy-A will have to go through the arduous process of recovering their account, while roomy-B continues to take advantage of their unfettered access to the account.
the transfer/organization paradigm works great for an organization, where there is clear hierarchy of ownership and responsibility. but does not work for ad-hoc groupings that may be temporary or flat, in which things need to flow and morph easily.
tl;dr = keep transfer, keep orgs, add actual true proper sharing.
edit: minor grammatical change
Any update on this? I would be awesome if users could take ownership back.
Misunderstanding of meanings. Because what is needed is to share a password for many different reasons for a short time, not the whole item or move the ownership.
Why, example: when we hire a profi to setup a device, he needs to have access to our equipment only a certain time (temporary), just until the work is done, after there is no need to. So the method would be to share the password with him inside our organization and after work
s done unshare and change it. The remaining stuff dont have to do anything because the new password would show up automatically. Then we would have not just the history at one place but in case of abusing we could also identify the intruder, through the logs on the equipment.
OK, I found it.
The way to share the password temporary is to to share it to the temporary collection, where it can be ushared.
What does this mean? I don’t have a “Temporary” collection. I can’t find anything relevant by googling for “bitwarden temporary collection.” How does this feature you’re describing work, exactly? Is there documentation for it somewhere?
In the Organization open a new Collection and name it f.e. TEMP or any-name you wish, but is for temporary passwords.
This is not a solution.
It works and is safe, I guess there won’t be anything else.
Makes it a pain if you can’t duplicate/clone the original. Not a simple workaround.
I guess that begs the question: Can organizations disallow duplicating?
This thread is fascinating. So I decide to leave Lastpass b/c support is terrible. Bitwarden seems great! I sign up for Family plan (which is kinda a weird Organization plan with marketing spin?) I import my Lastpass files.
Then I start sharing!
Step one, share a login with the Org.
Step two, unshare login from the Org.
Step three, become confused login is gone from everywhere.
Step four, spend 30 mins reading similar confusion on reddit that eventually leads to this thread.
Step five, read how it’s evidently hard to share/unshare something by the Official response.
Step six, think how Lastpass does this just fine. Everything’s a folder, and some folders are shared, then unshared. Then reshared.
Oooohkay? Family plans need to be easy. Sharing and unsharing that triggers deletes (or requires you to manually duplicate then delete) is too hard for families. My family isn’t a group of techs.
Can we just mimic Lastpass and move on? I mean it’s super easy. Let’s doooooo it!
did you mean to have this as a reply to my specific message or to the entire thread? i am confused if you are trying to communicate something to me in particular or not. as far as i can tell you and i want the same things a good method for sharing access to credentials that does not require tedious management interactions to set up and remove access when circumstances change.
Make a new collection in a org you wants to share with. Then share the password to the org in the clllection you just created. If you wants to unshare just go to the dedicated user you shared tej pass with and uncheck his acces to collection you made for sharing.
Unfortunately the sharing in BW means to forward the ownership of pass to an org and is irreversible.
I can’t believe this is not an option!!! Of course someone may want to present a password as a temporary item to the organization and then have the ability to remove it from the share! This should immediately be included into the Bitwarden interface!
Totaly agree with you!
Only this issue stops me using the bitwarden!
Hey bitwarden, when you add unshare function???
and other question for bitwarden:
If i have 50 users in my org i should create 50 collections for the share each personal password to each user? it’s very bad and useless