"currency" is not returned in search results metadata

[dobey]

When performing a search at https://search.apps.ubuntu.com/api/v1/search?q= the returned JSON objects for each click package contains a "price" field, but does not include a "currency" field to state which currency the price is actually in. This means that on the client we are unable to correctly show the price to the user.

[Martin Albisetti (beuno)]

Hi James, can you prioritise for next week?

[James Tait (jamestait)]

The short answer to the question "What is the currency of the price field" is "Whatever it is in SCA", which I believe is USD. We do have a prices field available to us, though, that contains all prices, keyed on currency, e.g.:

{
    "_links": {
        "curies": [
            {
                "href": "https://search.apps.staging.ubuntu.com/docs/v1/relations.html{#rel}",
                "name": "clickindex",
                "templated": true
            }
        ],
        "self": {
            "href": "https://search.apps.staging.ubuntu.com/api/v1/package/com.ubuntu.developer.matiasb-testing.qr-code"
        }
    },
    "name": "com.ubuntu.developer.matiasb-testing.qr-code",
    "price": 0.99,
    "prices": {
        "USD": 0.99
    },
...

We've suggested before that the price field doesn't make sense where the store allows several currencies - my preference would be to drop the price field entirely and instead return prices in the abridged package resource embedded in search results, highlights and department resources.

[dobey (dobey)]

Right. I'm trying to fix bug #1362716 at the moment, in a reasonably generic way, so we can appropriately display USD vs $ vs EUR v s €, etc… depending on what the server gives us and the locale of the user. Having the matching field of currency in the search results would help with that greatly for now.

Perhaps we can re-visit providing the "prices" field later, but I do not like it, as it means the client needs to somehow determine which currency to use.

[James Tait (jamestait)]

On 2 September 2014 15:42, Rodney Dawes <email address hidden> wrote:

> Right. I'm trying to fix bug #1362716 at the moment, in a reasonably
> generic way, so we can appropriately display USD vs $ vs EUR v s €, etc…
> depending on what the server gives us and the locale of the user. Having
> the matching field of currency in the search results would help with
> that greatly for now.
>

Part of the problem here is that the currency isn't exposed in the
devportal feed that Click Package Index consumes. Now, ​I've had a dig into
the devportal code, and for Click packages there is a dictionary of prices,
which is exposed in the prices field, and the price field is just a
convenient accessor to the USD entry in that dictionary. Currently,
however, there is no UI that I can find to actually set a price. On that
basis, I think a conversation still needs to happen around managing
multiple prices for Click packages, and it needs to involve Click Package
Index, Software Center Agent and client teams. I'm reluctant to just add a
placeholder currency field to the Package resource in the short term
without understanding the long term plan.

Also, is this a duplicate of bug #1258542 ?

Perhaps we can re-visit providing the "prices" field later, but I do not
> like it, as it means the client needs to somehow determine which
> currency to use.
>
>
​Right - we already talked briefly about this in Malta. As I said there, I
don't think we have all the information we'd need to properly format a
display price on a per-request basis. In the Index, we don't even know who
the user is, so we currently have no way ​

​server-side to figure out what payment methods they've set up and what
currencies those payment methods support. We kind of have the user's locale
via the Accept-Language header. We could pass through the list of
currencies supported by the client, but in doing so we'll render a lot of
the front-end caching useless (because now any given request can vary based
on architecture, supported frameworks, geographic locality, ​accepted
languages, accepted content types and accepted currencies).

I don't know what information the Click Scope has about payment methods and
currencies, but maybe QLocale::toCurrencyString() is enough to format a
price appropriately for a given locale if we can find an intersection
between the currencies offered for a package and the currencies offered by
a payment method?

--
James Tait, BSc. | https://launchpad.net/~jamestait/
Software Engineer, Canonical Online Services
Ubuntu - Linux for human beings | www.ubuntu.com