[Design] Specifying the default sharing account

[Brian Kirsch]

On Apr 17, 2007, at 10:15 AM, Mimi Yin wrote:

> So just to restate so I'm clear, it sounds like both Sharing and  
> Email accounts are doing the same thing right now? If there's no  
> default account set up, then Chandler chooses the next one that's  
> available? Can we stick with that for Preview? I agree that at some  
> point, we will need to have a more sophisticated notion of Default  
> accounts.
>
> One question: Morgen, the hack you described below doesn't actually  
> change anything that the user can see? It just skips over the OOTB  
> default sharing account and uses the next sharing account in the  
> list as the default under the hood? I just tried Publishing in r13983.
>
> I think then what we have now for both Mail and Sharing is okay for  
> Preview?

+1

I am fine with the current mail default account logic. As long as  
Sharing and Mail follow the
same algorithm then I think we should be good to go for Preview.


-Brian


>
> Mimi
>
> Begin forwarded message:
>
>> From: Brian Kirsch <bkirsch at osafoundation.org>
>> Date: April 17, 2007 12:52:35 PM PDT
>> To: Mimi Yin <mimi at osafoundation.org>
>> Cc: Chandler Design list <design at osafoundation.org>, Morgen Sagen  
>> <morgen at osafoundation.org>
>> Subject: Re: [Design] Specifying the default sharing account
>>
>> Hi Mimi,
>> I echo Morgen's sentiment that not having a means to specify the  
>> default is at times frustrating.
>>
>> The removal of the default option from the accounts dialog  
>> resulted in a lot of
>> coding work for me to try and add logic to essentially what is a  
>> vague situation;
>> having default accounts but no way to change which account is the  
>> default.
>>
>> Having said that, the email code is really strong now at handling  
>> cases such as the
>>  default account is not filled in but another account is.
>>
>> Essentially, the notion of a default account in the Mail Service  
>> is not needed in that the code
>> to determine the current Incoming and current Outgoing mail  
>> accounts is dynamic because it has
>> to be. The mail code avoids the situation Morgen described, where  
>> a user enters information
>> in another account but on send or receive an alert dialog is  
>> displayed because the default
>> is not filled in.
>>
>> Removing the notion of default all together at this stage in  
>> Preview is risky in my opinion.
>>
>> The Account Preferences dialog would need to be modified and a lot of
>> code in Chandler would need to be re-factored to remove the notion  
>> of defaults.
>>
>> At this point I feel the email code is smart enough to provide the  
>> user with a
>> positive experience around setting up and using accounts.
>>
>> post-Preview I think we should get rid of default accounts or add  
>> the ability to
>> explicitly specify which account is the default.
>>
>> For Preview, I do think the sharing and mail code should use the  
>> same logic when
>> determining which account to use for an action i.e.
>>
>> 1. Check the default account first. If it is filled in use it.
>> 2. Else find the first account that matches the action requested  
>> (send, receive, publish)
>>      that is filled in and use that.
>>
>>
>> Here is how I determine the current Outgoing (SMTP) mail account.
>>
>> def getCurrentOutgoingAccount(view, ignorePassword=False):
>>     """
>>     This function returns the default C{OutgoingAccount} account
>>     or the first C{OutgoingAccount} found if no default exists.
>>
>>     @return C{OutgoingAccount} or None
>>     """
>>
>>     outgoingAccount = None
>>
>>     # Get the current SMTP Account
>>     outgoingAccount = schema.ns('osaf.pim',  
>> view).currentOutgoingAccount.item
>>
>>     if outgoingAccount is None or not outgoingAccount.isSetUp 
>> (ignorePassword):
>>         for account in OutgoingAccount.iterItems(view):
>>             if account.isSetUp(ignorePassword):
>>                 return account
>>
>>     return outgoingAccount
>>
>>
>>
>> -Brian
>>
>> On Apr 17, 2007, at 8:01 AM, Mimi Yin wrote:
>>
>>> (bkirsch, question for at the bottom.)
>>>
>>> Oh I think the default is the WebDAV because we're waiting to  
>>> switch the default to the new sharing f/w?
>>>
>>> On Apr 17, 2007, at 10:47 AM, Morgen Sagen wrote:
>>>
>>>> No, I would like to be able to create a Chandler Hub Sharing  
>>>> account (which uses the new morsecode protocol), and have it be  
>>>> the default.  Any time a user has more than one sharing account,  
>>>> they should be able to choose one to be the default when  
>>>> publishing.
>>>>
>>>> The real problem is that if your default sharing account is not  
>>>> filled in, you can't publish anything, even though you *have*  
>>>> added another sharing account that is filled in.  Since there is  
>>>> no way to tell Chandler to make the new account the default,  
>>>> Chandler will continue to try and use the out-of-the-box default  
>>>> account, which if not filled in, will prevent you from publishing.
>>>
>>> Oh that's weird.
>>>
>>>>
>>>> To work around this for now, I added code that does the  
>>>> following:  When you click Ok in the accounts dialog, it will  
>>>> see if your default account is one that is not filled in.  If  
>>>> so, it will look to see if the user *has* filled in any other  
>>>> sharing accounts, and will randomly select one to be the new  
>>>> default.  This at least gets around the following scenario  
>>>> people have been running into:
>>>
>>> Does this work for email accounts too?
>>>
>>>>
>>>> 1) Start a new Chandler
>>>> 2) Create a collection to share
>>>> 3) Bring up Accounts dialog
>>>> 4) Create new Chandler Hub Sharing account and fill it in
>>>> 5) Try to publish the collection
>>>> 6) Chandler complains that you haven't set up a Sharing account  
>>>> (because the default sharing account is not filled in)
>>>>
>>>> My workaround prevents #6 from happening because the account  
>>>> created in #4 will be automatically be the default.
>>>>
>>>>
>>>> So it just hit me that since your first question was whether  
>>>> there *was* a default sharing account out of the box, that maybe  
>>>> you don't really think we *need* the notion of a default  
>>>> account.  If that's the case we need to resolve this because the  
>>>> current account dialog and sharing code is geared toward having  
>>>> a default account to use.  We *could* get rid of the notion of a  
>>>> default sharing account, but as someone who has quite a few  
>>>> sharing accounts, I appreciated being able to select a default  
>>>> from time to time.  We either need to embrace the notion of a  
>>>> default or get rid of it, because at the moment we're in a state  
>>>> of limbo.
>>>
>>> I think having a full-blown Defaults functionality is kind of  
>>> complicated, I'd prefer to avoid addressing this before Preview?  
>>> The current notion of Default is simply to let the user know that  
>>> there are 3 OOTB accounts that cannot be deleted. But perhaps  
>>> that's unnecessary? If an user wants to delete an account, they  
>>> should be able to?
>>>
>>> bkirsch, do you have any thoughts on this? Am I forgetting  
>>> something?
>>>
>>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>>
>>>> Open Source Applications Foundation "Design" mailing list
>>>> http://lists.osafoundation.org/mailman/listinfo/design
>>>
>>
> Begin forwarded message:
>
>> From: Morgen Sagen <morgen at osafoundation.org>
>> Date: April 17, 2007 11:31:00 AM PDT
>> To: Chandler Design list <design at osafoundation.org>
>> Subject: Re: [Design] Specifying the default sharing account
>>
>>
>> On Apr 17, 2007, at 11:01 AM, Mimi Yin wrote:
>>
>>> (bkirsch, question for at the bottom.)
>>>
>>> Oh I think the default is the WebDAV because we're waiting to  
>>> switch the default to the new sharing f/w?
>>
>> Yes.  Eventually the default will be switched to Chandler Hub  
>> Sharing.
>>
>>>
>>> On Apr 17, 2007, at 10:47 AM, Morgen Sagen wrote:
>>>
>>>> No, I would like to be able to create a Chandler Hub Sharing  
>>>> account (which uses the new morsecode protocol), and have it be  
>>>> the default.  Any time a user has more than one sharing account,  
>>>> they should be able to choose one to be the default when  
>>>> publishing.
>>>>
>>>> The real problem is that if your default sharing account is not  
>>>> filled in, you can't publish anything, even though you *have*  
>>>> added another sharing account that is filled in.  Since there is  
>>>> no way to tell Chandler to make the new account the default,  
>>>> Chandler will continue to try and use the out-of-the-box default  
>>>> account, which if not filled in, will prevent you from publishing.
>>>
>>> Oh that's weird.
>>
>> It's because we *had* an implementation that allowed the user to  
>> specify a default, but was removed from the UI.  However, the  
>> sharing layer is still based on the notion of having a user- 
>> selectable default.
>>
>>>
>>>>
>>>> To work around this for now, I added code that does the  
>>>> following:  When you click Ok in the accounts dialog, it will  
>>>> see if your default account is one that is not filled in.  If  
>>>> so, it will look to see if the user *has* filled in any other  
>>>> sharing accounts, and will randomly select one to be the new  
>>>> default.  This at least gets around the following scenario  
>>>> people have been running into:
>>>
>>> Does this work for email accounts too?
>>
>> I didn't touch email -- I don't know if email has the same need  
>> for a default account.
>>
>>>
>>>>
>>>> 1) Start a new Chandler
>>>> 2) Create a collection to share
>>>> 3) Bring up Accounts dialog
>>>> 4) Create new Chandler Hub Sharing account and fill it in
>>>> 5) Try to publish the collection
>>>> 6) Chandler complains that you haven't set up a Sharing account  
>>>> (because the default sharing account is not filled in)
>>>>
>>>> My workaround prevents #6 from happening because the account  
>>>> created in #4 will be automatically be the default.
>>>>
>>>>
>>>> So it just hit me that since your first question was whether  
>>>> there *was* a default sharing account out of the box, that maybe  
>>>> you don't really think we *need* the notion of a default  
>>>> account.  If that's the case we need to resolve this because the  
>>>> current account dialog and sharing code is geared toward having  
>>>> a default account to use.  We *could* get rid of the notion of a  
>>>> default sharing account, but as someone who has quite a few  
>>>> sharing accounts, I appreciated being able to select a default  
>>>> from time to time.  We either need to embrace the notion of a  
>>>> default or get rid of it, because at the moment we're in a state  
>>>> of limbo.
>>>
>>> I think having a full-blown Defaults functionality is kind of  
>>> complicated, I'd prefer to avoid addressing this before Preview?
>>
>> Well, that is the problem: either I have to modify the sharing  
>> layer to not have a notion of a default sharing account, or we add  
>> back the ability to specify a default sharing account.
>>
>>> The current notion of Default is simply to let the user know that  
>>> there are 3 OOTB accounts that cannot be deleted.
>>
>> See, here's the disconnect: the notion of Default is not just for  
>> the accounts dialog -- the "publish" dialog code uses the default,  
>> and the sharing code that answers the question "is sharing  
>> sufficiently set up to publish a collection?" also examines the  
>> default.  Since it seems like the user will not be able to specify  
>> a default in the preview timeframe, I need to change all sharing  
>> code which currently looks at the default and update it to do  
>> something else.  This means the "publish" dialog will simply list  
>> the sharing accounts in alphabetic order, with the first account  
>> selected.
>>
>>> But perhaps that's unnecessary? If an user wants to delete an  
>>> account, they should be able to?
>>
>> Probably, the user should be able to remove any of the accounts --  
>> however we should probably warn them if any collections are shared  
>> with an account they're about to delete.
>>
>> ~morgen
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070417/47e3e8d8/attachment.htm