View Issue Details

IDProjectCategoryView StatusLast Update
0004797Talermechant backendpublic2017-06-06 14:18
ReporterMarcello Stanisci Assigned ToMarcello Stanisci  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.3Fixed in Version0.3 
Summary0004797: /track/transaction takes public keys among parameters
DescriptionRight now, this call takes the instance as a plain string. It should also
provide the way to pick an instance via its public key.

For example, GET /track/transaction/?tid=x&instance_pub=BASE32PUBLICKEY

The reason is that when FEs want to track transactions they firstly get /history from BEs which return only instances' *keys* per history entry.
TagsNo tags attached.


Christian Grothoff

2017-03-06 00:22

manager   ~0011894

I don't understand this report, can we discuss it?

Marcello Stanisci

2017-03-06 14:34

viewer   ~0011896

The /history's (by merchant backend) response is a list of orders
that occurred over the time. Each list's element is associated with
a merchant instance (the one who fulfilled that order).

In earlier version of this API, we used to return history elements from
_all_ instances, basically mixing them in the same response. For some reason,
in this old API, each history element referred to its instance using
the instance's public key.

Now, since /track/transaction wants the instance as a instance's *name*,
the backoffice needed to do some extra work to retrieve the instance's
name starting from the instance's public key it got from /history beforehand.

So this bug wanted to change the type of /track/transaction's 'instance'
argument from 'name' to public key, so it can avoid that extra work needed
to retrieve the instance's name.

Nonetheless, this bug is now obsolete, as history elements now mention the
associated instance by their _names_, so no extra work is needed anymore.

Let me know if you want more details.

If the discussion is over, feel free to close this.

Christian Grothoff

2017-03-06 15:42

manager   ~0011897

I think I understand, and if no more change is required anyway, yes, we can resolve this.

Issue History

Date Modified Username Field Change
2016-11-17 15:06 Marcello Stanisci New Issue
2016-11-17 15:06 Marcello Stanisci Status new => assigned
2016-11-17 15:06 Marcello Stanisci Assigned To => Marcello Stanisci
2017-02-10 18:03 Marcello Stanisci Priority normal => high
2017-02-28 17:19 Marcello Stanisci Priority high => normal
2017-03-06 00:22 Christian Grothoff Note Added: 0011894
2017-03-06 14:34 Marcello Stanisci Note Added: 0011896
2017-03-06 15:42 Christian Grothoff Status assigned => resolved
2017-03-06 15:42 Christian Grothoff Resolution open => fixed
2017-03-06 15:42 Christian Grothoff Fixed in Version => 0.3
2017-03-06 15:42 Christian Grothoff Note Added: 0011897
2017-03-06 15:42 Christian Grothoff Product Version => git (master)
2017-03-06 15:42 Christian Grothoff Target Version => 0.3
2017-06-06 14:18 Christian Grothoff Status resolved => closed