Bug 712281 - REST interface should accept TextFlowTargets in any order
REST interface should accept TextFlowTargets in any order
Product: Zanata
Classification: Community
Component: Component-Logic (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: zanata-dev-internal
Ding-Yi Chen
Depends On:
  Show dependency treegraph
Reported: 2011-06-10 02:05 EDT by Sean Flanigan
Modified: 2012-01-26 20:44 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-01-26 20:44:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sean Flanigan 2011-06-10 02:05:22 EDT
TranslationResourcesService currently responds with "400 (Bad Request): Unexpected target: {resId}" when a TextFlowTarget is received after all TextFlows have been visited in order.  It requires all TFTs to be listed in the same order as their TFs, with no extras.  We should remove this undocumented requirement/assumption, and allow REST clients to provide TFTs in any order.
Comment 1 Ding-Yi Chen 2011-07-27 21:29:13 EDT
Can you shed any light on how to reproduce it and verify it?
Comment 2 Sean Flanigan 2011-07-28 00:10:32 EDT
It's an API change, so coding against the API is the only way to test it directly.  But I think the problem could probably be reproduced by running the python client to push PO files to an old version of Zanata server, if you hand-edit the PO files so that the messages are out of order compared to the POT.  We normally avoid this by running msgmerge, which puts the PO messages into the POT order.
Comment 3 Sean Flanigan 2012-01-26 20:44:14 EST
Fixed in 1.4

Note You need to log in before you can comment on or make changes to this bug.