Ability to chown grains

[ndarilek]

I would like the ability to change a grain's owner. I'm considering using Sandstorm for a set of loosely-defined organizations from which members may come and go. A member might, say, create an Etherpad document, then leave later. They may not want the doc cluttering up their workspace, but we may need it as part of our organization. Similarly, we may wish to create administrative accounts that own official organizational documents, but only change a document's ownership when we decide to upgrade it from "pet project" to official status.

I know this can be accomplished administratively, but perhaps a "Change owner" button that generates a request to an account chosen from those which have access. If the receiving account approves the request, the grain's owner is changed. Maybe the original owner can be given whatever permissions the new owner had, or permissions of the new owner's choosing when the request is approved.

[tebanep]

+1

[keypair]

just had this problem. ability to change ownership of grains or ownership of user (via setting email) is absolutely necessary in any organization. now looking again how to edit the database.

[ocdtrekkie]

@zenhack Here's the tracking issue for this one. As said in the other discussion, top questions are what happens to the graph of people the original owner shared with, and what permissions the original owner gets after transfer.

[zenhack]

Re: the original graph, I think nothing should happen to it -- I don't think this even interacts with the access stuff.

For the original owner, my instinct is we should grant them the broadest permission set possible to start with; they can either drop the grain or the new owner can revoke their permissions if something less is desired.

[ocdtrekkie]

So, doesn't everyone's share link explicitly define who shared it with them? Which means you'd have a tree of shares starting at the grain owner, if you mapped it out?

Also, roles in Sandstorm let you configure some pretty arbitrary arrangements of permissions, I am unsure we have a programmatic way to determine "the most permissions" that would make sense for all scenarios. Which is why I am thinking we may need to allow the transferrer to set their role post-transfer.

[zenhack]

So the other weird thing is that permissions are actually per UiView, not per grain.

It probably would be easier to just have a dropdown for the role to assign yourself after transfer; we could union all the permission bits, but that could in principle get you a set of permissions that isn't a "role," which is weird.

You're right about the tree, though I think it would "just work" provided that the old owner still has access. We could take two approaches here:

1. Leave this as-is.
2. Re-root the sharing tree onto the new owner.

(2) avoids a possible footgun where somebody is leaving the organization, so they transfer the grain to somebody else as an owner, then that person revokes the original owner's access, accidentally revoking everyone's access transitively.

I think if we were going to do (1) I might want to have a tree-view of permissions, and the ability to re-root children rather than revoking when a parent in the tree is revoked. So maybe we should re-root at least for the first version of this.

[ocdtrekkie]

Yeah, I think one of those ideal grain settings features is being able to see this tree in its entirety, which would make good decisions easier for people messing with sharing permissions.

[zenhack]

(Fwiw, this was on my shortlist of things to work on anyway; I have several grains that I would like to delete from my own grain list but can't because I shared them with other people and I don't want to revoke access. I wish I could just give them the grain).

[zenhack]

Had some other thoughts re: what to do for role assignment of the original owner:

• My first thought was that we could have ownership transfer require confirmation from the recipient, and the confirmation form could include assigning a role to the original owner. We would re-root the sharing tree onto the new owner, and then add the new role for the original owner.
• Alternatively, anywhere where role selection crops up, we just add a "pseudo role" for "unlimited access." Then, we can assign the owner this role instead of hoping the app author has already defined such a role.

Thoughts?

[ocdtrekkie]

Hmmm, I'm a bit worried about the UI complexity of an approval flow, but that's probably an "right" way to handle it. Depending on the grain, I can imagine scenarios where a user being "given" ownership without consent could be problematic.

[zenhack]

(It is especially problematic if the server enforces quotas: here, you pay for this).

[ocdtrekkie]

Yeah, we don't have many Sandstorm servers changing by quota, to my knowledge, but I see additional concerns with putting say, illegal material in a grain and then giving ownership to someone. Or even just using it as a way to transfer spam into their grain list...

[zenhack]

Quoting Jacob Weisz (2021-09-20 02:40:10)

Or even just using it as a way to transfer spam into their grain list...

I mean, even this much is theoretically already a problem with just sharing.