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

[Philipp von der Linden]

Hello, Hans!

I am sorry for not being more helpful, but I really do not have anything 
more to say than: If you think, it is covered, it is covered. If you 
think, it is all duplicates, then it will be the case, I trust.

HG, PvdL

-- 
Philipp von der Linden, M.A.
OsloerStr.93 D-13359 Wedding
eMail: "PvdL" 

On 30.05.2017 21:01, Hans Joachim Desserud wrote:
> I've read through this now, but just to double-check:
> There's various bug reports with package-conflicts for files in 
> '/etc/signon-ui/webkit-options.d/*' between account-plugins and 
> kaccounts-providers. (For instance bug 1617564)
> 
>>From what I see, this issue will remove the conflicting files from the
> account-plugins side and thus fix the issue. Does that mean that these
> other issues should all be marked as duplicates of this one?
>

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Hans Joachim Desserud]

I've read through this now, but just to double-check:
There's various bug reports with package-conflicts for files in 
'/etc/signon-ui/webkit-options.d/*' between account-plugins and 
kaccounts-providers. (For instance bug 1617564)

>From what I see, this issue will remove the conflicting files from the
account-plugins side and thus fix the issue. Does that mean that these
other issues should all be marked as duplicates of this one?

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Steve Langasek]

Here is my output for /etc/signon-ui/webkit-options.don a 16.10 desktop
system that was upgraded from 16.04:

$ dpkg -S /etc/signon-ui/webkit-options.d/*
account-plugin-google: /etc/signon-ui/webkit-options.d/accounts.google.com.conf
account-plugin-twitter: /etc/signon-ui/webkit-options.d/api.twitter.com.conf
account-plugin-identica: /etc/signon-ui/webkit-options.d/identi.ca.conf
account-plugin-windows-live: /etc/signon-ui/webkit-options.d/login.live.com.conf
account-plugin-flickr: /etc/signon-ui/webkit-options.d/login.yahoo.com.conf
account-plugin-facebook: /etc/signon-ui/webkit-options.d/www.facebook.com.conf
$

These are conffiles.  It is not sufficient to stop shipping them in the
package, you must also remove them from the filesystem on upgrade using
dpkg-maintscript-helper.  You can do this, for example, by adding a file
debian/account-plugin-google.maintscript to your packaging which
contains the following line:

rm_conffile /etc/signon-ui/webkit-options.d/accounts.google.com.conf
0.13+16.04.20161212~ account-plugin-google

You need to do this for each of the packages which is removing a
conffile.  And this change also needs to be made for 16.10 and 17.04,
since users of those releases who upgraded from 16.04 will still have
those files left behind.

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Alberto Mardegan]

Can some admin please remove the packages from -proposed?

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[David Barth]

** Tags removed: verification-needed
** Tags added: verification-failed

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Launchpad Bug Tracker]

** Branch linked: lp:~ci-train-bot/account-plugins/account-plugins-
ubuntu-xenial-1669

** Branch linked: lp:~ci-train-bot/gnome-control-center-signon/gnome-
control-center-signon-ubuntu-xenial-1669

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Launchpad Bug Tracker]

** Branch linked: lp:~mardy/account-plugins/webkit-files-1565772

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[olfa hedde]

** Branch unlinked: lp:~mardy/gnome-control-center-
signon/username-1565772

** Branch unlinked: lp:~mardy/account-plugins/usernames-1565772

** Branch unlinked: lp:~ci-train-bot/account-plugins/account-plugins-
ubuntu-xenial-landing-062

** Branch unlinked: lp:~ci-train-bot/gnome-control-center-signon/gnome-
control-center-signon-ubuntu-xenial-landing-062

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Alberto Mardegan]

A couple of notes about this bug verification:

While the ultimate goal of these proposed packages is to solve the co-
installation errors of Unity and KDE in Ubuntu due to a number of file
conflicts, this proposed upload alone won't be enough to solve the whole
issue, which is mainly due to bug 1451728.

I suggest verifying this bug by:

1) Creating Google, Facebook, Twitter and Flickr accounts and verify
that there are no regressions (that is, that the account creation
succeeds and that the user name is properly assigned on the newly
created accounts)

2) Verifying that a number of files have been removed under 
/etc/signon-ui/webkit-options.d/; mainly, verify that the file
  /etc/signon-ui/webkit-options.d/www.facebook.com.conf
  is not being shipped by "account-plugin-facebook" anymore.


If you are a KDE user, please also try installing "kaccounts-providers" from 
this PPA:
  https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging-misc/+packages

and check that there are no file conflicts against our "account-
plugin-*" packages.

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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

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

[David Barth]

Thanks Martin

On Mon, Aug 29, 2016 at 2:11 PM, Martin Pitt 
wrote:

> g-c-signon now has a higher version in yakkety, resetting to v-needed.
>
> ** Tags removed: verification-failed
> ** Tags added: verification-needed
>
> ** Changed in: gnome-control-center-signon (Ubuntu Yakkety)
>Status: In Progress => Fix Released
>
> ** Changed in: account-plugins (Ubuntu Yakkety)
>Status: In Progress => Fix Released
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1565772
>
> Title:
>   [SRU] Allow plugins to decide which username to set on new accounts
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/account-plugins/+bug/1565772/+subscriptions
>

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Martin Pitt]

g-c-signon now has a higher version in yakkety, resetting to v-needed.

** Tags removed: verification-failed
** Tags added: verification-needed

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

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

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Martin Pitt]

Same for account-plugins -- this was marked for being fixed in y, but
the comment that closes it was for xenial already, and yet the xenial
task is still open. This is horribly confusing and wrong, so I mark as
v-failed for the time being as at least the wrong gnome-control-center-
signon in yakkety needs to be fixed.

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

** Tags removed: verification-needed
** Tags added: verification-failed

** Changed in: account-plugins (Ubuntu Yakkety)
 Assignee: (unassigned) => Alberto Mardegan (mardy)

** Changed in: gnome-control-center-signon (Ubuntu Yakkety)
 Assignee: (unassigned) => Alberto Mardegan (mardy)

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  In Progress
Status in gnome-control-center-signon source package in Yakkety:
  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

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

[Martin Pitt]

Argh, I saw too late that this is already marked as fixed for yakkety ,
but the version there is 0.1.9+16.04.20160405-0ubuntu1 . I. e. it is
smaller than the version in xenial, which breaks upgrades. This is a
blocker for releasing the update, so y needs to be updated ASAP.

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

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

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  In Progress
Status in gnome-control-center-signon source package in Yakkety:
  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

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

[Martin Pitt]

Hello Alberto, or anyone else affected,

Accepted gnome-control-center-signon into xenial-proposed. The package
will build now and be available at https://launchpad.net/ubuntu/+source
/gnome-control-center-signon/0.1.9+16.04.20160719-0ubuntu1 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

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

** Tags removed: verification-done

** Tags added: verification-needed

-- 
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:
  [SRU] 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 Released
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:
  Fix Committed
Status in gnome-control-center-signon source package in Xenial:
  Fix Committed
Status in account-plugins source package in Yakkety:
  In Progress
Status in gnome-control-center-signon source package in Yakkety:
  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

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

[David Barth]

** Tags added: verification-done

-- 
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:
  [SRU] 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 Released
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
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Pat McGowan]

** Changed in: canonical-devices-system-image
   Status: Fix Committed => Fix Released

-- 
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:
  [SRU] 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 Released
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
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Launchpad Bug Tracker]

** Branch linked: lp:~ci-train-bot/account-plugins/account-plugins-
ubuntu-xenial-landing-062

** Branch linked: lp:~ci-train-bot/gnome-control-center-signon/gnome-
control-center-signon-ubuntu-xenial-landing-062

-- 
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:
  [SRU] 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
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Will Cooke]

** Also affects: gnome-control-center-signon (Ubuntu Yakkety)
   Importance: Critical
   Status: Fix Released

** Also affects: account-plugins (Ubuntu Yakkety)
   Importance: Critical
   Status: Fix Released

** Changed in: gnome-control-center-signon (Ubuntu Yakkety)
Milestone: ubuntu-16.04.1 => None

** Changed in: account-plugins (Ubuntu Xenial)
Milestone: None => ubuntu-16.04.1

** Changed in: gnome-control-center-signon (Ubuntu Xenial)
Milestone: None => ubuntu-16.04.1

-- 
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:
  [SRU] 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
Status in account-plugins source package in Yakkety:
  Fix Released
Status in gnome-control-center-signon source package in Yakkety:
  Fix Released

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: [SRU] Allow plugins to decide which username to set on new accounts

[Will Cooke]

** Changed in: gnome-control-center-signon (Ubuntu)
Milestone: None => ubuntu-16.04.1

-- 
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:
  [SRU] 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: [SRU] Allow plugins to decide which username to set on new accounts

[Will Cooke]

** Summary changed:

- Allow plugins to decide which username to set on new accounts
+ [SRU] Allow plugins to decide which username to set on new accounts

-- 
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:
  [SRU] 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