Generating tickets to share collections. Re: [Chandler-dev] [Proposal] Web UI Work Q

[Mimi Yin]

Hi Phillip,

I agree the workflow you describe is ideal. We never got around to  
implementing this functionality and are unlikely to in the near  
future. But this is definitely what we should shoot for as we iterate  
going forward.

Mimi

On Feb 14, 2008, at 1:42 PM, Phillip J. Eby wrote:

> Maybe I'm misunderstanding something about how the existing setup  
> works, but wouldn't the simplest user model be that you *always*  
> use some explicit "invite" mechanism in order to share your stuff?   
> Especially if that invitation mechanism just asks me for the email  
> addresses of the person(s) I'm giving access to, so I don't have to  
> know or think about URLs.  (Of course, if I've just created a  
> collection on the server, or published one from the desktop, having  
> some kind of prompt that the invite mechanism exists, or going  
> right into it, would be a good idea.)
>
> Then, on the receiving end, if I get an invite via email in the  
> desktop, I should just be able to "accept" it to set up my  
> subscription.  (Or of course, just click on the link to view stuff  
> on the hub, if I'm using a different email client.)
>
> Ideally, I shouldn't need to know or care what a "ticket" is, but  
> post-1.0 it would be nice if it generated different URLs for each  
> invitee, so that they could be individually "un-invited".  :)
>
> Last, but not least, it'd be good if the hub had a way to download  
> a file to initiate a subscription, using a shell association, so  
> that if you go to the hub in a web browser (e.g., you got a ticket  
> from a non-desktop user), you could just click in your browser to  
> fire up the desktop and add the subscription.
>
> I don't know if anything I just said is how practical to implement  
> (especially for 1.0), or how it relates to what we actually do.   
> I'm just saying that as a naive user, that's how I'd *like* it all  
> to work, or the way that would appear the most seamless and "low- 
> maintenance".  :)
>
>
> At 12:22 PM 2/14/2008 -0800, Mimi Yin wrote:
>> Okay, I thought about this some more and I think it might be a little
>> more complicated.
>>
>> First, let me re-iterate what I think we've agreed to so far to make
>> sure I understand it. Right now we are proposing 2 models:
>>
>> 1. On the Server / Hub, we don't automatically generate sharing
>> tickets. We only do so if the user asks to.
>>
>> 2. On the Desktop, we do, with the caveat that if an user created a
>> collection on the Server/Hub and then syncs it down to the Desktop,
>> they need to explicitly ask for tickets.
>>
>> Practically speaking this means doing the following work on the  
>> Desktop:
>>
>> 1. If a collection was created in the Desktop and published to Hub,
>> today's behavior stays the same.
>> 2. However, if a collection exists on the Desktop as a result of
>> having been created on the Server/Hub, then we do the following:
>> + Generate tickets if the users goes to Share>>Invite...
>> + Replace the [Copy URL(s)] button from the Manage Share... dialog
>> and replace it with an [Invite...] button that effectively takes you
>> to the Share>>Invite... dialog.
>>
>> {OR}
>>
>> We could make it so that the Server/Hub and Desktop have the same
>> model: Neither automatically generates sharing tickets unless the
>> users asks explicitly. For the Desktop, this means:
>> + Don't automatically generate tickets when publishing collections;
>> INSTEAD
>> + Replace the [Copy URL(s)] button from both the Publish... and
>> Manage Share... dialogs with an [Invite...] button; WHICH
>> - Generates 2 sharing tickets; AND
>> - Pops up the Share>>Invite... dialog.
>>
>> {OR}
>>
>> As Jared suggested we could simply add an option to the 'Settings'
>> dialog so that users can 'turn off'  auto-ticket generation and defer
>> the 'at-will ticket request' functionality.
>>
>> I'm wondering if this last option = least amount of work for both
>> Server and Desktop. But don't have to decide right now what we should
>> do.
>>
>> Mimi
>>
>> On Feb 14, 2008, at 11:39 AM, Grant Baillie wrote:
>>
>>>
>>> On 14 Feb, 2008, at 11:00, Mimi Yin wrote:
>>>
>>>> Grant, there is a question for you re: generating sharing tickets
>>>> for collections created on Chandler Hub/Server.
>>>>
>>>> On Feb 13, 2008, at 4:28 PM, Travis Vachon wrote:
>>>>
>>>> ...
>>>>>>
>>>>>> We could:
>>>>>> + Add an 'Invite...' link which would generate 2 tickets in the
>>>>>> 'Collection Details / Sharing dialog.
>>>>>> + I think we would also need to automatically generate 2 tickets
>>>>>> if the user invokes 'Invite' from the Desktop
>>>>>>
>>>>>> I was looking for the cheapest solution possible. FWIW many if
>>>>>> not most Desktop users publish collections to the server, not to
>>>>>> share with others, but just to back it up for their own use. So
>>>>>> I'm not sure if this distinction between shared versus not
>>>>>> shared is that clear. Or if it is, we should offer it for the
>>>>>> Desktop as well.
>>>>>
>>>>> Yeah, especially given the security model changes Randy is
>>>>> working on I think the cheapest solution is the one I proposed
>>>>> since it doesn't require any server work and requires a minimum
>>>>> of client work. Basically, we'd make the ticket creation process
>>>>> transparent and on-demand when users want to share calendars  
>>>>> read- write.
>>>>
>>>> Hrm, so I think to solve the user workflow problem we'd mostly
>>>> have to tweak the Desktop. Basically, create tickets when the user
>>>> invokes Share>>Invite... Grant, does that seem reasonable?
>>>
>>> Eminently reasonable. Implementable, even!
>>>
>>> --Grant
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "chandler-dev" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "chandler-dev" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/chandler-dev
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev