Re: [Snowy] Note sharing with other users - Plan of attack

[Jeff Schroeder <jeffschroeder computer org>]

Just wanted to get this out there before the hackfest.

On Fri, Oct 8, 2010 at 9:00 AM, Sandy Armstrong
<sanfordarmstrong gmail com> wrote:
> On Fri, Oct 8, 2010 at 8:42 AM, Jeff Schroeder
> <jeffschroeder computer org> wrote:
>> On Fri, Oct 8, 2010 at 8:06 AM, Sandy Armstrong
>> <sanfordarmstrong gmail com> wrote:
>>> Good stuff.  Some comments below.
>>>
>>> On Thu, Oct 7, 2010 at 8:40 PM, Jeff Schroeder
>>> <jeffschroeder computer org> wrote:
>>>> Instead of making notes completely private or wide open to the world,
>>>> lets go one step further and share notes with specific people.
>>>> Jean-François Fortin Tam (aka Jeff) did some pretty[1] mockups[2]
>>>> which inspired me to think about implementing his sharing[3]
>>>> interface.
>>>>
>>>> The proposed implementation doesn't require sql schema changes and
>>>> only needs a small model change:
>>>> ====================================
>>>> diff --git a/notes/models.py b/notes/models.py
>>>> index af5bd1b..1aa77d3 100644
>>>> --- a/notes/models.py
>>>> +++ b/notes/models.py
>>>> @@ -27,6 +27,7 @@ from snowy.notes.managers import NoteManager
>>>>  class Note(models.Model):
>>>>     NOTE_PERMISSIONS = (
>>>>         (0, _(u'Private')), (1, _(u'Public')),
>>>> +        (2, _(u'Shared'))
>>>>     )
>>>>
>>>>     guid = models.CharField(max_length=36)
>>>> ====================================
>>>
>>> We could conceivably simplify this even more.  We could simply have a
>>> boolean field indicating whether a note is public.  If it is not
>>> public, then system:sharing:read*:user email com would be checked.
>>
>> Hmmmmmmm. Why make things less flexible than they already are? The
>> note model already has this:
>>    permissions = models.IntegerField(choices=NOTE_PERMISSIONS, default=0)
>>
>> What you're proposing seems like it means you'd throw that field out
>> and replace it with a BooleanField. Can you explain (I'm rather dense
>> sometimes) how that is better? It also means we'd have to setup and
>> use south to do a schema migration.
>
> From a model point of view, I don't really care.  We could leave
> things as they are and it would be basically the same as having a
> boolean field.
>
> I don't see what is gained by the flexibility here, though.

These are the use cases I'm envisioning:
 1.) Note is private
 2.) Note is private
 3.) Note is shared with person X
 4.) Note is shared with group   X (schfifty five!)

If my understanding of what you're asking is correct, there would be a
bool for setting a note public or private. To support #3/4, you'd need
to do a db lookup. So say the implementation details that on notes
shared with other users, the flag be set to false (seems like the most
sense). That means on every note that has the bool set to false, an
extra db query is performed. Now you could inverse it and say that if
you share a note with person X, then you should mark the field public
= True, but that doesn't seem to make a lot of sense.

The current design (which I'm not proposing we change) gives you the
option to query on public, private, or any arbitrary other permission
level. ie: Give me all of the notes shared with a group. Give me all
of the notes shared with another user. Give me all of the public or
all of the private notes. That is my only real hesitation in switching
it to use a bool.

>>> Then we could add a public field to the Note object in the API spec (I
>>> forget if this is already in the draft; l.g.o is down right now).
>>
>> Isn't this already handled by whatever populates note.permissions to
>> either 0 (for private) and 1 (for public)? Forgive my complete
>> ignorance on the tomboy / snowy client side of things. Perhaps you
>> just need to implement the permissions bit in the api spec? l.g.o is
>> up now (I had to fix ldap).
>
> Snowy's model is not necessarily a 1-to-1 mapping with the Tomboy Web REST API.
>
> Right now, there is nothing in the API regarding note sharing.  What
> we add there is what I care about more than the model Snowy uses to
> represent it.  It impacts clients and other servers.
>
> It seems to me that the clearest API would be a "public" boolean
> field.  When True, the note is readable by all.  When False, it is
> readable only by those with read capabilities according to the note
> tags you came up with.

When the default note permissions are private, why add an extra lookup
for every single one? I'm not vehemently against your proposal, it
just seems like unnecessary work that is avoided without changing the
current model.

> Write capabilities would always be determined based on the tags.
>
> The flexibility you desire seems like it would be best implemented at
> the tag level (for example, specifying groups to share with instead of
> individuals).
>
> This is totally up for debate, of course.  :-)

Agreed! But how would that be implemented? You don't exactly want it
to be like facebook places where any person can arbitrarily put you
into a group. How can I as snowy user share a note with you, not
knowing your username in the tomboy online snowy database, but knowing
your email? Additionally, how would groups be created? Seems like a
cool feature, but scary to implement and manage. Do any of the UI
experts like Jeff Fortin or Sanderd have any comments?

>>> Is there something I'm not thinking of that would cause this approach
>>> not to work?
>>
>> I'll try to implement it however you think is best. Lets do what makes
>> changing things down the road is easier should a use case we didn't
>> expect come up. In specific, I was thinking of when we eventually do
>> integration with snowy + sparkleshare. It would be sad to paint
>> ourselves into a box early on. At that point we might want something
>> more than just Public/Private/Shared with these users.
>
> Such as?

No clue, but if it doesn't add much more complexity, flexibility is good.

>>>> If a note's permission attribute is set to 2, allow attaching a
>>>> NoteTag with the email address of the person to share with.
>>>>
>>>> The sharing tag's name would look something like this on the backend:
>>>> system:sharing:readonly:user email com
>>>
>>> Why readonly?  Why not read?  Were you thinking of having readonly,
>>> edit, and readedit or something?  It seems easier to just have read
>>> and edit, as separate tags.
>>
>> Great point. How about this:
>>
>> system:sharing:read:user email com
>> system:sharing:edit:user email com
>
> In retrospect, we could probably say that edit implies read, and that
> the presence of both would not be required if edit was there.

Very good point. The key would be to document this all very well so
clients don't mess it up.

>> One thing I forgot to mention. If a user != note.author has edit
>> capability of a note, that will not give them the ability to delete
>> that note. It seemed like it would do more harm than good.
>
> Agreed.  As discussed in IRC, edit is a complicated thing, especially
> on the client side, and we'll need to talk a lot more about how that
> would work, practically speaking.
>
> Sandy

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com