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

[Sandy Armstrong <sanfordarmstrong gmail com>]

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.

>> 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.

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.  :-)

>> 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?

>>> 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.

> 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