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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
