Re: Specifying the default sharing account

From: Brian Kirsch < bkirschosafoundation.org">bkirschosafoundation.org>;

Date: April 17, 2007 12:52:35 PM PDT

To: Mimi Yin < mimiosafoundation.org">mimiosafoundation.org>;

Cc: Chandler Design list < designosafoundation.org">designosafoundation.org>;, Morgen Sagen < morgenosafoundation.org">morgenosafoundation.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

From: Morgen Sagen < morgenosafoundation.org">morgenosafoundation.org>;

Date: April 17, 2007 11:31:00 AM PDT

To: Chandler Design list < designosafoundation.org">designosafoundation.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

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 < bkirschosafoundation.org">bkirschosafoundation.org>;

Date: April 17, 2007 12:52:35 PM PDT

To: Mimi Yin < mimiosafoundation.org">mimiosafoundation.org>;

Cc: Chandler Design list < designosafoundation.org">designosafoundation.org>;, Morgen Sagen < morgenosafoundation.org">morgenosafoundation.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 < morgenosafoundation.org">morgenosafoundation.org>;

Date: April 17, 2007 11:31:00 AM PDT

To: Chandler Design list < designosafoundation.org">designosafoundation.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