I think there should at least be a Clone/Copy option as a short term solution. Deleting and recreating means I lose my custom fields, URL settings, notes, and other important data with that site. The password isn’t the only important thing.
1 Like
Cloning is currently available 
- you just need to be an admin/owner of the vault item to perform the process.
2 Likes
Looks like a step in the right direction. Will play with the feature a bit.
Thanks!
1 Like
Hey folks - there are a couple of items going on in this thread:
- Share/“un-share” UI/UX. There is a request to make sharing via collections more point+click and less visually confusing, as well as making it easier to manage who has access to what data. This is good feedback, and we are always looking to make things as easy for end users as possible, within the scope of security and our architecture’s purpose.
We handle sharing the way we do currently (from a UI/UX standpoint) with a leaning towards enterprise-group-usage moreso than many individual user-user shares
- Request to actually “un-share” data . This is where it gets tricky and opinionated. Data can’t be truly unshared, as @d.b described - and the best practice is to remove the credentials & change them.
In regard to product functions, the guise of “un-sharing” can be had by doing one of 2 things:
- The org admin / owner can clone the item and delete the shared item
- The item in question can simply be unassigned from any collections, or to a collection available only to a specific user-group (perhaps one that handles password changes?)
Hopefully this answers more questions than it creates
@tgreer I have one question: what has been done in 2 years towards solving the problem that has been clearly stated more than 2 years ago?
Please don’t tell us that all that has happened is that you folks took 2 year to understand the issue, you are surely well above and beyond, so it’s reasonable that we expect some sort of concrete solution on this by now.
2 Likes
Wow this does seem to be a mountain out of a molehill.
I tried Bitwarden a year or two ago for family sharing and dismissed it because of these issues. I’m giving it another go now as there aren’t too many good options, but I really can’t believe this is still an issue.
I disagree with the argument that transfer into a private vault shouldn’t be allowed as it’s a security risk (as the password could be widely known) - these are 2 separate things - changing the password is what actually takes the resource back to private ownership - completely irrespective of whatever happens to our records in Bitwarden. What we want to transfer in Bitwarden is the data associated with a resource (which is often more than just a password: notes, other fields etc) to reflect the fact this information is no longer relevant to other users in the organisation.
I’m a developer and if I was going to solve this (within their current sharing architecture) I would:
- Add a setting on the organisation so owners can set whether or not “Unshare/Take Ownership” (or whatever you want to call it) is available. That should appease the people who prefer how it works now.
- If that’s ticked, any item in that organisation that you can delete, you also get the option to “Take”. This simply transfers into your personal vault and deletes the org item - ie reverse of a transfer into the org. If the item has a password associated, the UI would warn that others in the organisation may know this password and you should change it.
- The vault health report could identify any items where the password hasn’t been changed since they were taken from an organisation
That should be a pretty simple change, is there any reason we can’t do that?
Personally I’d also favour changing terminology “folders” to “tags” and “share” to “transfer” - that would make things more intuitive for new users, but if that’s going to bother existing users, I don’t think it’s a big deal to make that mental adjustment once you understand how it works.
6 Likes
@thewarden - sorry for the delay on your question. The 2 years has been spent improving other aspects of the platform, adding enterprise functions, etc. - and the reality is that the UI for share/unshare was not a high priority item. It’s also important to remember that Bitwarden was an incredibly tiny team until the beginning of 2020 - so only the most critical items were the focus.
@madz - I think this would be a great idea to toss into the contribution category, and we can see what options there may be for you to help solve this
1 Like
Hello tgreer,
The clone function does not help to solve the ownership issue because the original ownership is always transferred to the clone copy.
I went into my personal vault to make a copy of a shared item as the owner of the associated organization. The clone copy also belonged to the organization. Furthermore the Bitwarden pieces of software refused to make the clone copy when I ticked off all the collections. It HAD TO be associated to a collection. I tried in the Linux application and in the Web interface to no avail.
I played around with Bitwarden functions and parameters for a very long time without finding a simple way to “unshare” an item, i.e., to transfer ownership from an organization to the owner of the organization. The only two ways I found were (i) to open two instances of a Bitwarden interface and to manually copy all the item fields from the original item to a newly created one in the personal vault; (ii) to export the organization vault in json, manually delete everything but the target item, and update its ownership in a text editor to import the file in the personal vault. Two error-prone ways, specially the second one.
Since you seemed to announce the clone function as a way to solve the ownership issue, did I misuse it or the function does not help?
Thanks for your constant help in the forum.
1 Like
Hi @mpiter! Thanks and welcome!
If you’re an organization owner, inside your organization web vault when you clone an item, you should see an option at the bottom to select who owns the item. You can change from the org name > your email address and then the clone will belong to your user only.
Though, probably the easiest (from a management standpoint) to “un-share” is to have a collection that no one but the owners/admins have access to, and simply assign the item to only that collection.
5 Likes
Thank you very much. That was exactly what I needed. I cannot believe that I was so blind that I missed the right field when I cloned an item.
I showed Bitwarden to a friend yesterday. He tried it and liked it a lot. I think he will also buy a family plan. I have just gone premium to support Bitwarden.
Thanks again for your quick help.
3 Likes
Deleted my reply about how stupid this decision is, great!
You’re free to voice your thoughts in a polite manner.
You’re also more than welcome to disagree with mine or anyone else’s opinion - politely.
2 Likes
I agree the lack of an unshare feature is unintuitive, and I hope it will be implemented (with appropriate warnings and/or checks as suggested). Meanwhile, I’m relieved to have found a usable enough workaround (based on tgreers’ suggestion above – thank you!):
As the “owner” of an “organization” representing a two-person family, I’ve made two collections, one called “Shared” (available to both of us) and the other called “Unshared” (available only to me). To unshare a login, I edit it so that it belongs only to the Unshared collection.
(Since I trust my wife, I don’t bother to change the password after unsharing. I only unshare it to avoid the confusion of having two autofills available for a given site.)
One thing that makes even this workaround confusing is the fact that in the Web Vault, the Edit Item screen lacks Collections information.
Thankfully, Collections can be edited in various other ways: from a list of logins in the Web Vault (click the gear icon to the right of a login), from the browser extension (Edit Item), from the mobile apps (Edit Item).
3 Likes
Hello Everyone,
building on this, I thought how one could implement this. For 2FA authentications there is a possibility to implement it. Therefore I Wrote a new feature request since it is not exact the same … .
Maybe this implementation is also useful for you 
:
1 Like
I am currently on the Family Plan trial week. I have decided to not continue with the Family Plan and go with two Premium accounts for my wife and I. First of all, it’s less expensive, but that’s not the main reason. To me, being able to share a password and then retract it should be such a common feature, there shouldn’t be any discussion about it. Personally, I don’t want the aggravation of cloning and changing passwords in order to accomplish what should be basic practice. It’s Bitwarden’s philosophy that I disagree with. I agree with the philosophy of other password managers that do have this service - LastPass and Dashlane come to mind. To me, I don’t see what’s so difficult about setting up a switch, utilizing an owner’s privilege to choose whether or not to allow Sharing and Retracting (or Unsharing) for a specific item, an individual, that particular organization, or even in the entire vault. I mentioned before that I disagree with Bitwarden’s philosophy. It seems to be that Bitwarden users are treated like children, in relation to this issue, rather than adults. The choice is made for us. Even with many customers begging for this change, we’re just not mature enough, nor have enough foresight, to realize the dangers of simply Sharing and Retracting (or Unsharing). I haven’t used Bitwarden (the free version) long, but I do appreciate that Bitwarden solicits user feedback in order to improve the product for their users. However, when it comes to this particular issue, apparently we’re just too ignorant and/or immature to know what’s best for us. I realize that, as a private company, Bitwarden has a right to do whatever it wants to do, and if the user doesn’t like it, he can always go somewhere else. But, this to me, goes against the grain of trust associated with the whole open source model.
2 Likes
This is necessary, mostly when we’ve used the feature often in LastPass.
2 Likes
We migrated off LastPass with a couple trial organization, however, cannot recommend bringing more over without this ability to “stop sharing” items that were originally created in the personal vault
3 Likes
We migrated off LastPass with a couple trial organization, however, I cannot recommend bringing more over without this ability to “stop sharing” items that were originally created in the personal vault.
2 Likes
You misunderstand the technical implementation of an organization and conflate it with not having permissions after sharing.
The organization owns the entry and a person’s account can have admin privs to an org. My wife and I each have our own org. I have read-only access to her’s and she to mine. We can both share with the click of a button to our own orgs.
edit: “And unshare” Seems I was mis-remembering something. It is not often that I need to unshare. Via the web ui, I can move an entry out of my org and back into one of my folders.
The limitations of the orgs has nothing to do with some philosophical view that Bitwarden is attempt to enforce. It’s because the features of an org is virtually 1-to-1 with the underlying datastructure. They could make it so it functions like the entries stay with the original creator, but this would be syntactical-sugar on top of their current datastructure and would take time to implement. Not to mention it would change per-existing functionality around sharing, which could be dangerous. So they would have to take that into consideration in how they transition.
1 Like
I respectfully disagree. It’s obvious that it is a common practice in the password manager field, so why wouldn’t Bitwarden implement it then? Also, many (many) people want this feature, thus all the discussion and the votes. And Bitwarden implemented this “vote on changes you want” practice. It comes down to being a simple philosophical difference. Otherwise, with all the people that want it, I believe Bitwarden has enough integrity that they would move in the direction of making it happen. Now, I think, when explaining themselves, their reasons will be technical/hyped shells that when stripped away, the standard philosophical truth will remain - they think they are safeguarding the customer, which equates with not allowing the customer to weigh their own risks and move ahead.
1 Like