No way to change the owner of a document
This is available on legacy documentcloud via Edit -> Change Owner, but is missing from the new frontend.
I don't think this is documented in the API, so we should do that, too.
The way to bulk update the ownership of documents is as follows:
if new_org_id and new_org_id not in users_orgs:
self.set_message(
"Error: If new organization ID is set, "
"it must be an organization you belong to"
)
raise ValueError
data = {"user": self.data["new_user_id"]}
if new_org_id:
data["organization"] = new_org_id
for page_documents in grouper(documents, BULK_LIMIT):
json = [
{"id": d.id, **data}
for d in page_documents
if d is not None
# you must own the document
and d.user_id == me.id
# and it must either not be public or in an organization with you
and (d.access != "public" or d.organization_id in users_orgs)
]
count += len(json)
try:
self.client.patch("documents/", json=json)
The code reassigns ownership of documents to a new user (and optionally a new organization), but only for documents the current user owns and that are either private or belong to one of the user's organizations. It processes the documents in batches for efficiency and sends the updates to the server using a bulk PATCH request. Documents that don't meet the ownership or access criteria are skipped.
With the new auto-generated drf-spectacular docs, I'm not sure where I should document this. In update() user and organization aren't listed I believe because in the serializer organization and user are marked as read only. The call still works though.
Documentation update pending in https://github.com/MuckRock/documentcloud/pull/304
This is complete from my side can use a PUT or PATCH and specify user and organization given the documented caveats https://api.www.documentcloud.org/api/schema/redoc/#tag/documents/operation/documents_update
Here's the legacy UI:
I can't tell who this set of users represents. Orgs are the user's current orgs.
@eyeseast It is a list of users in the below mentioned orgs sorted by the default which is the DocumentCloud (ID) . These combinations can make incompatible choices however for transfer, like you could assign it to MuckRock Staff (Homicide Watch D.C) which may not be an actual individual <-> organization combo. Instead we should probably allow the user to first select which organization they want to change ownership to (can include personal organizations, just should mark this somehow) and then filter that by which user in that organization the user would like to transfer to.
I realized as soon as I started working on this that I'm going to have to use it as soon as it's live. One of my scraper jobs is putting everything in the wrong org.
Let's try this: You can select an org first, a real one or your individual one. If you choose your individual org, that's it, you can save or cancel.
If you select a real org, you get a choice of users to give it to, from that org.
That should cover all possibilities, right?
This eliminates the possibility to transfer a document from a personal org to another personal org (user -> user) or from org to a different personal user (say the document was uploaded under one of my accounts Sanjin (MuckRock Staff) and I wanted to transfer it to a different one of my accounts Sanjin_2 (sanjin_2). We can mitigate this by adding Sanjin_2 to MuckRock Staff temporarily and transferring it to Sanjin_2(MuckRock Staff) and instructing Sanjin_2 to then transfer it to their personal org, but this is not a good user experience. Not that allowing people to transfer documents to a personal org which they probably don't understand is a good model either.
I'm open to being outvoted here
So, if I want to transfer a document to you, personally, is there a way to do that now? I'd have to set it to your personal org and you as a user, right?
Correct, which was not optimal on the Legacy documentcloud because the autocomplete didn't differentiate between personal orgs and non-personal ones, so if you had a case where an org also had a user by the same name it could be that you transferred to MuckRock_user (MuckRock_org) instead of MuckRock_user(MuckRock_personal_org).. ask me how I know..I don't think we necessarily have to worry about this exact edge case as it should be rare and we shouldn't really even allow users to have names that match closely to the org name
The tradeoffs, as I see it:
- We can make it easier to pass a document to another individual, with the chance that it fails in a way that's hard to predict beforehand.
- We can reduce failures by making you choose an organization first, but at the cost of making it harder to pass a document directly to an individual.
I think I prefer option 2, just because it's always safer to keep documents with some organization so people don't lose access.
I left a comment on Slack for reasoning, but I tend to agree with you here
@eyeseast I think that makes sense, as long as there's some way (even an add-on?) to migrate to personal orgs. We do see that use case come up where an investigative power user will be leaving their current company and going independent or something and want to take their private docs.
Under option 2, you could still move documents to your personal organization, but it would be harder for you to move documents to my personal organization. If we're in the same org, you could still transfer them to me without changing the organization.
I wrote my way to this conclusion in Slack, but having ownership as both User and Org feels unnecessarily complex—why not just treat Organization as the ownership field, and then a document can belong to either an individual (Private access) or a group (Org access)? It's not clear to me why I should need to pick a user within my organization—shouldn't all org admins have control over a doc owned by an org?
Actually, reading the API docs, it looks like you shouldn't be able to change ownership to an org you don't belong to:
Changing the owner requires the current user to own the document and for the document to either be private or belong to an organization they are a member of. The new owner must belong to at least one organization that the current owner is a member of.
So that rules out giving a document to someone else's personal organization.
To @allanlasser's point: You don't actually have to assign a new user as owner. You can just change the org a document belongs to and keep ownership yourself.
This actually seems like a common use case and should be obvious how to do.
We throw up that big red warning in the current version, but you actually shouldn't be able to lose access to a document unless you transfer it to a new org and a new user and it's private, not org access.