[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-06-29 Thread Alberto Mardegan 
When will this SRU land in Xenial?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to account-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  Confirmed
Status in gnome-control-center-signon source package in Xenial:
  Confirmed

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-06-16 Thread Amr Ibrahim 
** Tags added: xenial

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to account-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  Confirmed
Status in gnome-control-center-signon source package in Xenial:
  Confirmed

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-31 Thread Launchpad Bug Tracker 
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: gnome-control-center-signon (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center-signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  Confirmed
Status in gnome-control-center-signon source package in Xenial:
  Confirmed

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-31 Thread Launchpad Bug Tracker 
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: account-plugins (Ubuntu Xenial)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center-signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  Confirmed
Status in gnome-control-center-signon source package in Xenial:
  Confirmed

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-25 Thread Mathew Hodson 
account-plugins (0.13+16.04.20160405-0ubuntu1) xenial; urgency=medium

  [ Alberto Mardegan ]
  * After the authentication, retrieve the username in Google, Facebook,
Flickr and Twitter plugins (LP: #1565772)
  * debian/control, debian/libaccount-plugin-facebook.install,
debian/libaccount-plugin-flickr.install,
debian/libaccount-plugin-twitter.install:
add packages containing plugin modules.
  * debian/account-plugin-facebook.install,
debian/account-plugin-flickr.install,
debian/account-plugin-twitter.install:
remove unneeded webkit-options files.

  [ CI Train Bot ]
  * No-change rebuild.

 -- David Barth   Tue, 05 Apr 2016 12:57:47
+

** Changed in: account-plugins (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: account-plugins (Ubuntu Xenial)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center-signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  New
Status in gnome-control-center-signon source package in Xenial:
  New

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-25 Thread Mathew Hodson 
gnome-control-center-signon (0.1.9+16.04.20160405-0ubuntu1) xenial;
urgency=medium

  [ Alberto Mardegan ]
  * Allow plugins to retrieve username (LP: #1565772)
  * debian/libaccount-plugin-1.0-0.symbols
- new symbols

  [ CI Train Bot ]
  * No-change rebuild.

 -- David Barth   Tue, 05 Apr 2016 12:57:57
+

** Changed in: gnome-control-center-signon (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: gnome-control-center-signon (Ubuntu Xenial)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center-signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  Fix Released
Status in gnome-control-center-signon package in Ubuntu:
  Fix Released
Status in account-plugins source package in Xenial:
  New
Status in gnome-control-center-signon source package in Xenial:
  New

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-25 Thread Brian Murray 
** Also affects: gnome-control-center-signon (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: account-plugins (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center-signon in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  In Progress
Status in gnome-control-center-signon package in Ubuntu:
  In Progress
Status in account-plugins source package in Xenial:
  New
Status in gnome-control-center-signon source package in Xenial:
  New

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1565772] Re: Allow plugins to decide which username to set on new accounts

2016-05-24 Thread Alberto Mardegan 
Version 0.13+16.04.20160405-0ubuntu1 which fixes this bug is in Yakkety.

** Also affects: account-plugins (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: account-plugins (Ubuntu)
   Status: New => In Progress

** Changed in: account-plugins (Ubuntu)
   Importance: Undecided => Critical

** Changed in: account-plugins
   Status: In Progress => Fix Released

** Changed in: gnome-control-center-signon
   Status: In Progress => Fix Released

** Also affects: gnome-control-center-signon (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: gnome-control-center-signon (Ubuntu)
   Status: New => In Progress

** Changed in: gnome-control-center-signon (Ubuntu)
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to account-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1565772

Title:
  Allow plugins to decide which username to set on new accounts

Status in Online Accounts: Account plugins:
  Fix Released
Status in Canonical System Image:
  Fix Committed
Status in Online Accounts: GNOME Control Center:
  Fix Released
Status in webapps-sprint:
  Fix Committed
Status in account-plugins package in Ubuntu:
  In Progress
Status in gnome-control-center-signon package in Ubuntu:
  In Progress

Bug description:
  This bug is related to bug 1547647, even though it makes sense in any
  case.

  Currently, the ApOAuthPlugin class in libaccount-plugin gets the
  username from the SignonIdentity, which in turn gets it from signon-
  ui, which in the current WebKit1 implementation gets it from the DOM
  of the login webpage. This is a hack, it's fragile, not trivial to
  port to the Oxide web engine, and possibly against some providers'
  guidelines.

  We should retrieve the username using some REST API provided by the
  service, and in order to do so we need to extend libaccounts-plugin
  with some hooks which subclasses can use to get the username.

  Once we fix this we can also get rid of the files /etc/signon-ui
  /webkit-options.d/, which are conflicting with those installed by the
  KDE account plugins packages.


  SRU information
  ===

  [Impact] The same file /etc/signon-ui/webkit-
  options.d/www.facebook.com.conf is installed by the account-plugin-
  facebook package (used by Unity) and by kaccount-providers (used by
  KDE). See this bug's duplicates to see actual bug reports.

  [Test Case] Install both account-plugin-facebook and kaccount-
  providers and you'll get the conflict.

  [Regression Potential] Users running KDE will be completely unaffected
  by this. Users running Unity might see a change when creating accounts
  in System Settings->Online Accounts: with this bugfix, the account's
  display name is obtained by making a REST API call to the remote
  service, rather than by scrapping the DOM of the server webpages
  (which is a hack, and prone to errors if the providers' webpage
  changes). The new way of retrieving the username is the proper one,
  and it's been tested to work reliably. In any case, the worst thing
  that might happen is that accounts get created with an empty display
  name, which is mostly an aesthetic problem (the display name is used
  only for UI purposes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp