Bug 712281 – REST interface should accept TextFlowTargets in any order

Bug 712281 - REST interface should accept TextFlowTargets in any order

Summary:	REST interface should accept TextFlowTargets in any order

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Zanata
Classification:	Community
Component:	Component-Logic (Show other bugs)
Sub Component:
Version:	1.3
Hardware:	Unspecified Unspecified

Priority	unspecified Severity unspecified
Target Milestone:	---
Target Release:	---
Assigned To:	zanata-dev-internal
QA Contact:	Ding-Yi Chen
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2011-06-10 02:05 EDT by Sean Flanigan
Modified:	2012-01-26 20:44 EST (History)
CC List:	1 user (show)

See Also:	https://bugzilla.redhat.com/show_bug.cgi?id=711249
Fixed In Version:	1.4
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2012-01-26 20:44:14 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: 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.