15 November 2016 This a significant update containing a small number of important UI visible fixes in addition to some internal improvements that caused recurring support issues.
P305 Unique names used for Script workflow output
The Script workflow now creates a unique document name on output in the same way the Clone workflow does. This fixes some odd user generated issues and is more consistent with the rest of the workflows.
P308 Login name matching was case sensitive
The owner email address was case sensitive. This was a minor but sometimes annoying issue that is now fixed. Your login email address is now case insensitive.
P315 Venues copied by Persona copy were not posting correctly
Where a copy of a Persona was made, some Venue properties were not getting copied, and the Venue was not posting properly. This is now fixed. If you have Venue folders in RF where there are documents that did not get posted to the corresponding external venue, please contact support for instructions to fix this. It’s simple, and we have video training covering this.
P318 Venue with incorrect Credentials checked enabled
This is related to P315 and appeared in copied Personas. It is now fixed.
P134 Filter workflow did not allow more than 2 filters
There was a UI defect introduced in some recent release that made saving a Filter rule with more than two filter selections fail. This is now fixed. The limit on filters in each Filter rule is 10.
P256 – Change the internal name of copied HIT definitions
When duplicating a HIT definition, but internal name on the copy is derived from the internal name of the original. This was not the case before, the external name was used.
P316 – Completed MTurk assignments not getting returned to ResultFlow
This was an undiagnosed, but long standing, timing bug that was exacerbated by server performance improvements about 3 weeks ago. It resulted in loss of completed HITs. Only a few apps were significantly impacted and if that’s you, we’ve already been in contact. This defect is now fixed.
P282 – MTurk workflows started without sufficient funds never complete
This also was a timing related issue but it impacted all apps. Where a HIT was submitted without sufficient MTurk balance, the workflow transitioned to an invalid state and had to be manually killed. The symptom of this was “stuck” workflows, i.e., workflows that were far too old to be valid. For example, if the HIT lifetime is 5 days, but a document with an MTurk workflow is dated 8 days ago, it is not a valid workflow and should be manually terminated.
This issue is now fixed. Starting an MTurk workflow without the required funds will transition directly to a (valid) error state and put a task on the owner’s task list. Once those tasks are completed manually (select “Done” on the task) the documents can be resubmitted to MTurk using the “Run Workflows” button.
P310 – MTurk per account rate limiting via API
Some apps were seeing HIT submissions occasionally refused by MTurk because of what appears to be an undocumented per-account rate limit in Amazon’s API. We now queue and submit HITs to eliminate this issue.
Leave a Reply