Aloha - i would like to create an Amazon Turk task to collect information on hotel companies in Hawaii.
One quesion (that i was unable to get ansewred through the MTurk FAQ/website)
I have a form on my host that will allow the turkers to complete the task - can i re-direct or include this link in the task description. I tried creating a sample task - and it requires me to use/modify their existing DHTML template - and does not allow to re-direct to my data entry form hosted on my website. I was planning on providing detailed instructions on how to enter data into my site form on the MTurk task description.
Any help would be appreciated. Mahalo!
If you need workers to fill out a form on your site you have two options:
Create your hits with an external question (requires use of the mturk API): http://docs.amazonwebservices.com/AWSMechTurk/2008-02-14/AWSMechanicalTurkRequester/ApiReference_ExternalQuestionArticle.html
Provide a link to workers to your form in the task description. When the worker has filled out your form, provide a verification code that they can enter into a field in your Mturk template. This way you can ensure the worker has completed your external form by checking that they entered a proper code.
Related
I want to integrate DocuSign with Power Automate. There are 2 things that needs to achieved in this integration
achieve completed documents to share point site ( which is completed )
if the flow fails due to any other factors, it should retrigger after 5sec, 10sec, 15 sec automatically.
And if the flow fails after these 3 attempts then it should mail the concerned team
Basically I designed a flow which is archiving Documents to a share point site. I am unable to add rest of the conditions.
My flow starts from When the envelope status changes -> Get envelope Documents -> Create a file in Sharepoint site (Try Block)
But I am unable to add a create a logic on 2nd and 3rd conditions .
I added delay and resubmit after last step (Create a file in sharepoint ) but the flow is continuously re-submitting after every failed attempt.
See the DocuSign Power Automate docs.
Then ask more questions here when you have a specific question. Include information on what you already tried (what isn't working).
If you just want to store completed documents to a SharePoint site, first check out DocuSign Agreement Actions. There is an action which stores to SharePoint.
Re: the flow is continuously re-submitting after every failed attempt
Sounds like you have a logic error in your flow. You can update (Edit) your question to include more information. Then we can better help you.
when a new client is added I want to verify if the newly added client's details are correct.
For example,
Create a new client, after creation search his name and check if the details are correct or not.
Should I include them both in the same feature, or should I create a different feature for both adding and searching clients
Feature: Creating a new Client
The user is
Able to add a new Client
Scenario: Valid client entry.The client has a username,address
Given User is on the client page
When When he clicks on the add new client
Then He should see a pop up
Then He will enter the client name,address,title,phone no and email
And Click on the save button
Feature: Search for our newly added user
The user will be able to search a client
Scenario: Search for our newly added client
Given User is on the client page
When He click on the client search
And Types the user name
Then He should be able to match the first result
When He clicks on the first matched result
Then It will take him to a page with users details
It would be better to keep them separate. The strategy that worked best for me in many projects are, you should map each feature to the requirement (i.e. the high level user story or the requirement that is given to you from which you derive BDD scenarios and steps). Keeping each high level requirements in a separate feature files increases readability and maintainability.
In this case, looks like "Creating a new client" and "Search for our newly added client" are two different requirements/user stories, it is better to manage them separately, as the scenarios in each of these cases would vary. For an example, "Creating a new client" might have following scenarios:
Scenario 1: Create a valid client entry.The client has a username,address
Scenario 2: Creating a valid client entry failed due to missing information
Scenario 3: Creating a valid client entry failed due to client already exists
And for "Search for our newly added client" you would have other scenarios like:
Scenario 1: Search for a newly added user using username and search result should show the user details
Scenario 2: Search for a user using username who is not in the database and empty search result should be shown
Scenario 3: Search for a newly added user using address details and search result should show the user details
Scenario 4: Search for a user using username using address details who is not in the database and empty search result should be shown
As you can see, each feature is now nicely segregated and have their own related scenarios. As the project grows these scenarios are likely to grow and it would be easier to manage by keeping each high level requirements in a separate feature file.
Also another practice that really worked well for me is to prefix the Jira ticket(or whichever tool you use to manage your user stories) to the feature file as it would be easy to search and manage. For an example, your feature should be like "TI1001 - Creating a new Client" and "TI1002 - Search for our newly added user"
There are lots of ways to do this
features
clients
add_new_client
search_for_clients
I'd favour this one if clients are a really significant part of the
project
features
client_add
client_search
but this one would work.
The important thing is to try and be consistent.
As for your scenarios try and make them simpler e.g.
Feature: Add new clients
Background:
Given I am allowed to add clients
Scenario: Add a client
Given there are no clients
When I add a client
Then there should be a client
You want your happy path scenarios to be this simple, so you can expand on them with sad paths. e.g.
Scenario: Add a new client without an address
Given there are no clients
When I add a client with no address
Then I should see that a client cannot be added without an address
As far as searching goes things can get quite complex so again start simple
Feature: Search for clients
Scenario: Search for client Fred
Given there is a client Fred
When I search clients for Fred
Then I should see client Fred
Scenario: Search for client Fred when Fred does not exist
Given there is a client Sue
And there is not a client Fred
When I search for Fred
Then I should see a not found result
Scenario: Search for clients by postcode
Scenario: ...
With searching you need to be careful not to spend all your time testing your search engine (it should already be well tested.
These sort of features and scenarios are declarative, rather than imperative. They state WHAT they are doing and WHY, but avoid describing HOW anything is done. Cuking is much more effective with a declarative approach.
We are using a read only Asana "Project" to manage our design work. Our design work is organized as Asana Tasks. Each Task represents a different design project. The reason for making it read only is to limit Asana users from accidentally making changes to the project details and to restrict Asana users from creating their own tasks that fall outside of the Task standard structure that we have decided on.
To create these tasks in Asana we are using a combination of Cognito forms and Zapier to create the tasks automatically. Our customer fills out the Cognito form and Zapier automatically populates Asana with the design Task that needs to be completed for that specific customer.
The issue with this setup is that to move the tasks around in Asana to provide the team with "updates", either an Asana user with write privileges needs to do it, or the Asana user needs to fill out a form to make the change, since they only have read privileges. We would prefer to keep it super simple and I have figured out a way to do it using Zapier webhooks.
Because we are using Zapier, I can format URL links in any sort of way I want. I can create a URL link that includes the Asana Task ID and the Asana section that the task needs to be moved to. Using webhooks, a user can click a "Change Section" URL. Clicking this URL will trigger a Zapier Zap action which then will change the Asana Task Section. Just by clicking the link a User can make updates to that task.
My question is fairly basic. Is there a way to stop the URL from opening a page but for the data in the URL to be still passed to Zapier? When a user clicks the link it opens a web page and I don't want that to happen. Or if it happens, could the web page immediately close after opening?
The short answers is "no, it's not possible to click on a zapier link and have the page not open or auto-close" out of the box.
The long answer is a little more involved. I'm assuming your url looks something like https://hooks.zapier.com/hooks/catch/1234/abcd?name=john&cool=true, allowing you to pass "name" and "cool" into Zapier.
To pass that into Zapier, you need to get the contents of that URL, either by loading it in a web browser or calling it with another tool (such as fetch or curl).
If you've got some engineering resources, you could host a very simple HTML page somewhere that could accept data and run some Javascript. It would do something like:
read Zapier webhook url from the querystring (probably worth encoding)
On pageload, run await fetch(thatUrl)
Instruct the user to close the page (which is better UX than the JSON or black response you get from Zapier). I thought JS could close any page, but it turns out window.close() only works if the script opened the page (docs).
So that's an ok workaround.
I need to have a button in custom Location app, upon clicking which will take me to workorder application list tab with all the workorders created on the assets of the particular location.
I am using launch in context.
I tried using WF, but the workorder is opening in main tab instead of List tab.
Work flow used
Interaction Node details
after routing, wotrack is opening like "http://hostname/maximo/ui/?event=loadapp&value=wotrack&additionalevent=changetab&additionaleventvalue=List&uniqueid=72&uisessionid=35&_tt=6e2h84jnc2qpnu9tohvo04qpdp"
how it is fetching workorder with unique id 72?
I think Launch in Context is the wrong tool. Launch in Context is used for launching the user from Maximo into some external website / application, using some data from Maximo to provide some context to that application.
Instead, it sounds to me like you should use a Workflow process with an Interaction Node. In the Interaction Node, you can specify the Application and tab to take the user to and the Relationship from the Main Object of the current app to use to find the record(s) that should be loaded in the destination app for the user.
I don't remember how to set up Launch in Context, but this web page on the URL parameters you can use should help on that part at least.
http://maximodev.blogspot.com/2012/04/maximo-urls.html
Specifically, the example using the SQL query is probably what you need, since you want to display the records (workorders) associated with the records (assets) associated with the record (location) you have. (The earlier outline of the article has the wrong URL values for the "Perform a query using a where clause" section, but the example near the bottom has the correct setup.)
http://localhost/maximo/ui/maximo.jsp?event=loadapp&value=wotrack&additionalevent=sqlwhere&additionaleventvalue=status%20in%20('WAPPR')
I think if you give the Launch in Context the part of that URL after the hostname, it will try to load it as a page at the current, which would end up taking you to exactly where you want to be, regardless of the public hostname of the server.
maximo/ui/maximo.jsp?event=loadapp&value=wotrack&additionalevent=sqlwhere&additionaleventvalue=status%20in%20('WAPPR')
I just had a quick question on making a survey on an external link as a HIT on Amazon Mechanical Turk. If a user completes the survey on the external webpage and submit the survey code on the MTurk interface, how do I, as the requester, guarantee that the user won't do the survey again? As in the user should only do the survey once. So is there a way to only allow the user to click on the survey link only once? Thank you!
Each worker is restricted to completing a HIT only once. Of course, if you setup your survey software to not log each worker's WorkerId, it is possible they might click the link multiple times before completing the HIT.
I recommend logging the WorkerId in your survey sytem. You can take a look at some instructions I've put together here for how to achieve this using JavaScript.
I usually ask each worker to submit their workerID on my hit interface. I use their ID along with some other information to generate their code. So, I can cross-check their amazon mturk responses with responses logged on my server.