[Design] Specifying the default sharing account

Mimi Yin mimi at osafoundation.org
Tue Apr 17 13:15:15 PDT 2007


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?

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

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


More information about the Design mailing list