Ticket

+commit
 
+issues

E.g. want to be able to restrict who can edit my 'profile'

 

+solution

Cards can be set to be readable, editable, etc. by Author, which means the person who created the card.

 

Home card's author is set to the owner?

and its plus cards?

what if one of its plus cards gets created by someone else?

 

Give every user permission to edit permissions on cards for which they are te Author?

 

Offer a way to restrict? E.g., only their home card and plus cards with it as a part.

 

 

 


I think the most likely use case is to have this permission applicable only to a user's own card (and cards plussed with it). This lets me "own" my page and make my own addendum to any other card as a card, rather than a comment. Of course, then I'd want to be able to have one mechanism mean "read-only public, write-only rjbs" and another for "read-only rjbs." I'm not sure how yet.

  --rjbs.....Tue Jul 14 15:17:57 -0700 2009


I don't think it's going to be a role. should rename.

  --Ethan McCutchen.....Tue May 04 16:03:58 -0700 2010


I can see how it wouldn't fit perfectly with roles as they are, but a separate interface for doing this from the current (or setting-ized) permissions interface seems likely to be annoyingly redundant. What are your objections to doing it as a role?

 

Are you thinking a narrow solution around account (and related plus) cards, or did you have a more general solution in mind?

  --John Abbe.....Thu Nov 18 15:48:09 -0800 2010


This change will come with setting-ize permissions, which will let you do everything we currently do with roles but will considerably reduce the magic of the "Role" cardtype. I'll spell this out elsewhere, but since the interface is going to be the sets/settings interface, it will be a very different situation.

 

I don't think we've entirely worked out how the author thing will work, but it's likely to be about syntax, not roles.

 

-e

  --Ethan McCutchen.....Thu Nov 18 16:05:28 -0800 2010


The current proposal in setting-ize permissions spells out the current plan, which does not really involve an Author role, per se, but addresses, I believe, the key user stories that prompted this ticket. closing for now.

  --Ethan McCutchen.....Thu Jan 06 10:14:19 -0800 2011