failure_reason is not returned

[Michael Vogt]

In https://wiki.canonical.com/Ubuntu/SoftwareCenter/10.10/Roadmap/SoftwareCenterAgent it reads:
"""
if the transaction was unsuccessful, the other attributes are unnecessary, but an extra "failure_reason" can be returned and a additional "user_canceled" to tell the client that the failure is expected and there is no need to show a error message.
"""

however it appears that the server is sending it as a "failures". Is that intentional? Shouldn't it better be "failure_string" or "failure_reason" ? I can adapt the client easily, but I want to know if its accidental or or purpose.

[Michael Nelson (michael.nelson)]

Sorry Michael - that was intentional and I forgot to update the spec. The reason is that there can be multiple failures. You are probably only interested in the first one, but I wanted to be sure the API exported a property that included all failures.

As an example (off the top of my head), if the launchpad subscription creation fails, and then the payment cancel request fails, the failures attribute will contain both (in order).

[Anthony Lenton (elachuni)]

So, we're going to update the spec to say "failures", and update the code in sca to always return "failures" --- it's returning both currently, failure_reason in "openid_failure" pages, and "failures" in the subscription purchase pages.

The value will remain a string as it is currently, so that it is backwards compatible, but the desktop app will in the future log the message and show a generic failure message instead, as these error messages could be too technical for the end user.

Once this has been updated on production we can mark the bug as affecting the desktop app so they can update their code.

[Michael Vogt (mvo)]

Here is the string that we use currently, mpt if you could have a look at the string, that would be good:

            dialogs.error(self,
                          _("Failure in the purchase process."),
                          _("Sorry, something went wrong. Your payment "
                            "has been canceled."))

[Matthew Paul Thomas (mpt)]

Where would those strings appear?

The first string is unsuitable as a window title, because it uses sentence case and punctuation; correct for a window title would be something like "Purchase Unsuccessful". And it would be unsuitable as alert primary text, because it's not a complete sentence; it needs "Sorry, there was a" at the start of it. (To be fair, "Save changes to XYZ?" is not a complete sentence either, but it's a well-worn contraction of one.)

The main problem with the second string is that it says "something went wrong" but not what. If there's no way of telling *what* went wrong, that sentence can't do anything and should be removed. A secondary problem is that the string doesn't tell me what I should do now. Should I try again, or should I give up? If I should try again, when should I try? In a few minutes? Tomorrow?

[Michael Nelson (michael.nelson)]

On Mon, Nov 1, 2010 at 11:17 AM, Matthew Paul Thomas <email address hidden> wrote:
> Where would those strings appear?

These strings will appear in the Software Center client (not the
opened browser window).

>
> The first string is unsuitable as a window title, because it uses
> sentence case and punctuation; correct for a window title would be
> something like "Purchase Unsuccessful". And it would be unsuitable as
> alert primary text, because it's not a complete sentence; it needs
> "Sorry, there was a" at the start of it. (To be fair, "Save changes to
> XYZ?" is not a complete sentence either, but it's a well-worn
> contraction of one.)

Great - that's why we were asking for your help :)

>
> The main problem with the second string is that it says "something went
> wrong" but not what. If there's no way of telling *what* went wrong,
> that sentence can't do anything and should be removed. A secondary

The exact failure reasons are returned to the client and will be
logged, but we (I) assumed that it would not be helpful to present
those to the purchaser. ie. 'Unable to verify your identity as the
identity API is not available.', or 'Unable to create Launchpad
subscription as the Launchpad API is unavailable' etc., hence going
for something generic in the client which can also be localized.

If you think it would be better to provide exact errors to the
purchaser, I can provide you with all the current failure reasons if
you can help us make them more user-friendly. If we do decide to go
this way, we might also be better off updating the agent to return
error codes and include the strings in the client.

> problem is that the string doesn't tell me what I should do now. Should
> I try again, or should I give up? If I should try again, when should I
> try? In a few minutes? Tomorrow?

Given that the real reason could be any of the various services being
unavailable (LP api, payments api, identity-provider, payment backend
etc.), could we say "please try again later", ideally with a link to a
page outlining support options (ie. faq + other options). (BTW:
forwarding you a conversation about software center support options).

So, please tweak the following, or help us create a better option:

Dialog title: Purchase Unsuccessful
Dialog text: Sorry, there was an error during your purchase and your
payment has been cancelled. Please try again later. If the problem
persists please [link]contact Software Center support[/link]. (yuk,
lots of room for improvement there).

[Matthew Paul Thomas (mpt)]

> If you think it would be better to provide exact errors to the purchaser

Providing exact errors would be better if (a) knowing more would make people more forgiving (for example, if it wasn't our fault), or (b) it would help people choose what to do next. So, would either be true here? Would the suggested action differ at all depending on the error? In "try again later", how much later?

[Michael Nelson (michael.nelson)]

On Mon, Nov 8, 2010 at 1:28 PM, Matthew Paul Thomas <email address hidden> wrote:
>> If you think it would be better to provide exact errors to the
> purchaser
>
> Providing exact errors would be better if (a) knowing more would make
> people more forgiving (for example, if it wasn't our fault), or (b) it
> would help people choose what to do next. So, would either be true here?

Looking through the code, there seems to be one failure for which (a)
and (b) will be true: when the user goes through the Payments ui
without issue, but when the SCA gets a notification and checks the
status of the payment it is not authorised. This is (3) below. All
other possible failures are failures on from us (well, SSO, Launchpad,
connection to payments etc., in some way, our fault) for which we
can't give any better recommendation than "try again later" afaik.

So, a full list:

These first two were only relevant during the restricted beta:
1) Error while verifying whether user is allowed to [App name] (ie. an
error while using SSO api)
2) Software purchases are not yet publically available. (ie. only
possible if a config switch is on)

This is the relevant one for which we do need feedback:
3) Payment status returned by payment service was [payment status]
(ie. payment status returned by payments API is something other than
AUTHORISED)

And the rest which fall into the "Try again later" category:
4) Error while checking or creating a LP person: [user_name] (ie. an
error while using LP API)
5) Unable to create payment: [first line of payment exception] (ie. an
error when using payments api)
6) Unable to create Launchpad subscription: [first line of error] (ie.
an error while using LP API)
7) Unable to capture payment: [first line of error] (ie. error during
call to payment API capture_payment)

Hope that helps.

> Would the suggested action differ at all depending on the error? In "try
> again later", how much later?
>

[Matthew Paul Thomas (mpt)]

Thank you for that info. So, I suggest:

For #3, primary text of "Sorry, the card issuer did not authorize your payment." and secondary text of "Your card has not been charged." I'm assuming that just trying again won't help, but it's unfortunate that we don't have specific advice to give. Or do we?

For #4, #5, #6, and #7, primary text of "Sorry, there was a problem completing your purchase. Try again in a few hours." and secondary text of "Your card has not been charged."

[Launchpad Janitor (janitor)]

This bug was fixed in the package software-center - 3.1.1

---------------
software-center (3.1.1) natty; urgency=low

  [ Kiwinote ]
  * softwarecenter/app.py:
    - don't require '.deb' extentions for deb files (LP: #656967)
    - don't require absolute paths for deb files (LP: #669398)
  * softwarecenter/view/appdetailsview_gtk.py:
    - correctly reload appdetailsview after a transaction has run
    - _update_minimal() only gets two args

  [ Gary Lasker ]
  * softwarecenter/backend/channel.py,
    softwarecenter/view/channelpane.py,
    softwarecenter/view/viewswitcher.py:
    - convert channel getters to properties
  * softwarecenter/backend/config.py:
    - don't crash on a corrupted config file (LP: #662414)
  * softwarecenter/view/dependency_dialogs.py:
    - fix TypeError crash in remove dependency dialog
      (LP: #669161)
  * softwarecenter/utils.py,
    softwarecenter/view/softwarepane.py,
    softwarecenter/view/widgets/imagedialog.py,
    softwarecenter/view/widgets/spinner.py:
    - refactor spinner code
    - make a spinner panel widget and add label support
  * softwarecenter/backend/aptd.py:
    - fix crash during reload (LP: #673991)

  [ Michael Vogt ]
  * softwarecenter/view/purchasedialog.py:
    - show generic error on purchase failure and log the error
       (LP: #632361)
  * test/test_startup.py:
    - add startup speed baseline/regression test
  * software-center:
    - add --measure-startup-time commandline to allow external apps
      to drive statup performance measuring
  * utils/update-software-center-agent:
    - add --ignore-etag to force reload even if we have a cached version
  * softwarecenter/db/update.py:
    - do not fail if "MimeType" is missing from a desktop file
  * softwarecenter/apt/apthistory.py:
    - use python-apt tagfile parser instead of python-debian
  * debian/control:
    - drop python-debian dependency
  * test/test_gui_buy_something.py:
    - run test with --ignore-etag
  * softwarecenter/apt/aptcache.py, test/test_addons.py:
    - make the addons test more robust

  [ Martin Pitt ]
  * debian/rules: Supply dh --with option after $@, for compatibility with
    current debhelper.
  * debian/control: Build with scour for SVG optimization. Add python-scour
    build dependency.
 -- Michael Vogt <email address hidden> Thu, 18 Nov 2010 16:58:02 +0100