View Issue Details

IDProjectCategoryView StatusLast Update
0004797Talermerchant backendpublic2017-06-06 12:18
ReporterMarcello Stanisci Assigned ToMarcello Stanisci Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
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.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Christian Grothoff

2017-03-05 23:22

manager   ~0011894

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

Marcello Stanisci

2017-03-06 13:34

reporter   ~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 14:42

manager   ~0011897

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

Issue History

Date ModifiedUsernameFieldChange
2016-11-17 14:06Marcello StanisciNew Issue
2016-11-17 14:06Marcello StanisciStatusnew => assigned
2016-11-17 14:06Marcello StanisciAssigned To => Marcello Stanisci
2017-02-10 17:03Marcello StanisciPrioritynormal => high
2017-02-28 16:19Marcello StanisciPriorityhigh => normal
2017-03-05 23:22Christian GrothoffNote Added: 0011894
2017-03-06 13:34Marcello StanisciNote Added: 0011896
2017-03-06 14:42Christian GrothoffStatusassigned => informing
2017-03-06 14:42Christian GrothoffResolutionopen => fixed
2017-03-06 14:42Christian GrothoffFixed in Version => 0.3
2017-03-06 14:42Christian GrothoffNote Added: 0011897
2017-03-06 14:42Christian GrothoffProduct Version => git (master)
2017-03-06 14:42Christian GrothoffTarget Version => 0.3
2017-06-06 12:18Christian GrothoffStatusinforming => closed
2025-03-22 13:09Christian GrothoffCategorymechant backend => merchant backend