Let SC client handle subscription progress UI

[Michael Nelson]

Now that bug 609025 is committed, we can move the UI for an in-progress subscription to the client.

That is, instead of waiting for SubscriptionComplete or SubscriptionCancelled to do the title change event for the client, we could move it to PaymentInitiated, and then allow the client to poll the subscription itself via the API, providing better progress feedback.

[Michael Nelson (michael.nelson)]

This came up during a discussion at UDS as a way to:
  1) improve the payment progress UI (integrate it into the client UI),
  2) not allow the purchaser to disrupt the purchase process (currently they can close the window after purchasing, which would mean the client never sees the title-change event).

Note: if we don't do this, then we will need to style the payment-in-progress pages in SCA (or be happy with it unstyled for now :)). Also, one aspect of bug 606170 will need updating (see comment 4).

Doing this would involve one simple change in the agent, and a change in the client so that when the title change event is received (including the api uri for the new subscription), the client would poll the subscription status via the API until it is completed/cancelled - updating the progress bar appropriately.

[Michael Nelson (michael.nelson)]

This will require fixing bug 615342 also.

[Anthony Lenton (elachuni)]

The current agreed way to fix this will be to provide a valid OAuth token for the signed in user via the embedded browser title, that the desktop app can then use to poll via the api, while the embedded browser is closed.

This fix can be landed first, and then let the desktop app use that information at their own leisure.

[Anthony Lenton (elachuni)]

We'll also need to:

a) Provide the id for the newly created subscription in the page title in the checkout_complete view, and
b) Provide a get() api call for the desktop app to be able to fetch the state of the subscription without needing to use getForMe()

[Matthew Paul Thomas (mpt)]

Is this bug report just about text feedback, or proportion feedback too? If the latter, bug 649715 is a duplicate.

[Michael Nelson (michael.nelson)]

It's about handing over control of the feedback to the client. Currently the client waits on the JS title-change event which only happens when the purchase is complete/failed - we'd like that event to instead happen when the purchase is initialised, and enabling the client to use the API to check the status itself and update the UI. So yes, bug 649715 sounds like a different way of achieving a similar result, afaics.

[Anthony Lenton (elachuni)]

As well as the items listed in comments #3 and #4, provide a script for QA to test this feature, as it might be a while until the desktop client starts using these features.

[Danny Tamez (zematynnad)]

On Wed, Mar 30, 2011 at 12:26:07PM -0500, Danny Tamez wrote:
> Hey!
Hi,

> I'm working on https://bugs.launchpad.net/software-center-agent/+bug/622732

Great!

> and had a question about backwards compatability for the desktop client. What
> I am looking at doing is changing the <title>Software purchase in
> progress</title> portion of the subscription_purchase_in_progress.html page to
> include the oath token and subscription id. This is so that a new api can be
> called with the subscription id to check the status directly and not be
> dependent on the js updating the title.
>
> So my question is will adding the oath token and subscription id to the title
> break the existing client? If so, do you have an alternate suggestion on how
> to pass back this info?

Hm, so adding the info is not a problem. However the client is
expecting "successful" that is either True or False. So this mechanism
will not work with the existing client, sorry for that.

We could add a new mechanism via the statusbar, webkit supports a
callback on statusbar changes. Or alternatively "console-message" that
is called when "A JavaScript console message was created.". This time
we need to build-in a version so that the client can simply ignore
message versions its does not understand :)

Let me know which one you pick so that I start testing, time is up
for natty unfortunately, we are behind feature/UI freeze.

Cheers,
 Michael

[Danny Tamez (zematynnad)]

QA: Here is a way to test the api call that the desktop client is going to make.
Get https://bugs.launchpad.net/software-center-agent/+bug/622732 locally and run fab bootstrap.
Place the attached script in the root of the branch.

On staging find or create an application to purchase and make note of the architecture, distro and archive_id.
Initiate a purchase in your browser via:
https://sc.staging.ubuntu.com/subscriptions/en/ubuntu/maverick/+new/?archive_id=some_archive_id&arch=i386
replacing maverick with a different distro if necessary,
replacing some_archive_id with the actual app's archive_id,
replacing i386 if necessary with a different architecture (e.g. amd64)

After entering this url you will be redirected to enter payment information. Enter standard dummy payment info (VISA 4111111111111111 and similar).

You will then be redirected to SCA.
Open up your browser's debugger (e.g. in firefox - press F12) and then open up the tab for console output.
You will see a string of json printed out in the console. Copy this to your clipboard.

Go back to your terminal and the sca branch mentioned above with the attached script. Run the script as follows:
$./test_api.py 'a bunch of json goes here between single quotes'
this will make the same authenticated call that the desktop client will make and will print out the subscription state every second.

[Gary Lasker (gary-lasker)]

I've removed the milestone as we have missed the window for implementing this for Precise.