• Add own endpoint for t5connect
• Add API-test for that Endpoint that tests all possible variants (pretranslation, visual, user-assignments, ...)
• Add seperate field "foreignState"  to task-entity to handle the state a synced task is in
• [optional: Stephan please decide] Add endpoint to set those states in a bulk {Remark Stephan: axelbecher for me its OK and enough to set this state for a single task. Bulk is not needed.}

The new endpoint currently is editor/connect/?foreignName=T5Connect&lastDays=365 (+ &foreignState=? )

additional "wish(es)":
Sometimes customers want/need to transfer a certain task again to Translate5. therefore the following points would be really helpful to solve service requests

• make task columns "foreignName" and "foreignId" selectable in the GUI to be shown.
• make "foreignState" set-able by cli t5 command.

new endpoints

Either each of the following function is reachable over a separate API-endpoint or its don by submitting a parameter.

Sample:
/editor/t5connect/getFailedTasks
vs.
/editor/t5connect?action=getFailedTasks

getFailedTasks

current behaviour:

// task is not failed if:
// - foreignName is not self::FOREIGN_NAME (that means only tasks which are created by t5Connect are relevant)
// - OR state is not 'error'

getImportedTasks

current behaviour:

// task is no 'T5Connect' task if:
// - foreignName is not self::FOREIGN_NAME (that means only tasks which are created by t5Connect are relevant)
// - OR state in ['error', 'import'(, 'end')]  // if 'end' is in here depends on $includeEndedTasks
// - OR task is locked)

getConfirmedTasks

current behaviour:

// Get all confirmed tasks. "Confirmed" tasks are:
// tasks that are "T5Connect" tasks (see function getT5ConnectTasks())
// tasks where all assigned users of the relevant workflowSteps (reviewing, translatorCheck) do NOT have state 'waiting' or 'unconfirmed'

getFinishedTasks

current bahaviour:

// Get all finished tasks, that means: tasks that can be exported from T5 for re-import into Across.
// "Finished" tasks are:
// tasks that are "T5Connect" tasks (see function getT5ConnectTasks())
// tasks where all (relevant) associated users has 'finished' their work.

in addition to this, there is a separat attribute "isAutofinished". This should/could also be moved to logic in new API endpoint
current logic is:

foreach ($tempTasks as $task) {
	// attribut to check if task is autofinished
	$task->isAutofinished = true;
	
	foreach ($task->users as $user) {
		// a task was "auto-finish" if "the last wokflow-job in Translate5 has state 'auto-finish'"
		// this means: if there is at least one user with another state than "auto-finish", the job was NOT autofinished.
		if ($user->state != self::STATE_AUTO_FINISH) {
			$task->isAutofinished = false;
		}
	}
	
	$tempReturn[] = $task;
}

getAllTasks

returns ALL t5connect tasks. Should only be needed while migration from old to new behaviour. And maybe for some "non-regular" used function. Anyway good to have something like that

getTaskByForeignId

Get a single task by its unique foreignId

needed data for "task"

Summary of needed task-data

$t5Task->id
$t5Task->taskGuid
$t5Task->taskName

$t5Task->foreignId
$t5Task->foreignName

$t5Task->state
$t5Task->locked


$t5Task->users
	$t5User-id
	$t5User->workflowStepName
	$t5User->login
	$t5User->state

changes in T5Connect

API endpoint config

while we can not switch from currently used API endpoints to the new ones for all installations at the same time, we will add a new config "TRANSLATE5_API_ENDPOINT". With this config you can decide which API endpoint(s) will be used.
The existing ones will not be replaced, because they are standard Translate5 API endpoint.

Btw. many API calls will stay as they are (e.g. createUser). Only the "expensive" calls of getting lists of tasks (e.g. "getFailedTasks()") will be moved to the no API endpoint(s).

Update "foreignState" for existing task

For all task that ere already succesfully re-imported into Across, the "foreignState"should be updated in Translate5.
It's not clear yet how this should be done exactly. Maybe a "one-time call" could be enough. Or maybe some thing similar to the "garbage-collector", but then it will be called each time the scheduler is running, and needs resources.
Or maybe a "once a day" call..