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 <[EMAIL PROTECTED]>
Date: April 17, 2007 12:52:35 PM PDT
To: Mimi Yin <[EMAIL PROTECTED]>
Cc: Chandler Design list <[email protected]>, Morgen Sagen
<[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Date: April 17, 2007 11:31:00 AM PDT
To: Chandler Design list <[email protected]>
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
