This information is missing from the story endpoint documentation here: https://asana.com/developers/api-reference/stories
Do you know what are the possible values for type field?
There are currently only two types: system and comment - comments being text entered by a user, and system being all the other stories, such as tasks being completed, moved, re-assigned, etc.
Related
Just to give you a brief, I'm working on a Chatbot, that will suggest the user some things, based on the answers of a few quetions. Now, most of the questions that the agent asks the user are in Yes/No and with a very little variation.
So here's the usercase:
The agent asks the user these two questions:
Did you have your meal(s) on time?
Did you work out today?
The answers to both these questions can be in a YES/NO.
In that case, if the user is asked the meal question and the user responds with a NO, the agent updates the parameter values for both the meal question as well as the workout question.
But that's something that I don't want.
I'm using the slot-filling technique here. Is there a way around this problem.
Here's my User Info Intent and the parameters that I have:
PS - I don't really want to create multiple intents for all these parameters and want to handle all these answers with just one intent
If the agent updates the parameter values for both the meal question as well as the workout question that means you're using the same parameter to host both answers, you need to use different parameters.
If would be very helpful if you shared how you have handled the dialog so far. And can I ask why do you want to use only one intent?
You can try creating a generic intent and setting both parameters as required, defining your questions as prompts for each parameter. That way the answers will be hosted in two different parameters.
I'm using the JIRA Agile plugin.
I've created a task with a few subtasks inside it and I want to assign multiple users to one subtask.
Any idea how this is possible without rebuilding JIRA from source then tinkering the code?
There is an Atlassian page that covers this topic.
The options they discuss may not match your requirements though. They seem to be focused on the situation where the users you assign to an issue are consistent and part of a group.
One option is to create a custom field of type 'group picker'. Another option is to have a user defined on JIRA that actually represents a group of users and has a mailing list email.
I'm wondering how to assign two users to one task in JIRA. I took over a project that was set up by someone else. The problem is we are doing pair programming and we would like to keep track of time.
I dont think you can not actually assign two users to field assignee as it is built-in field.
You can create new required field e.g. pair-assignee and have pair tracked there. Here is a doc about how to setup a custom field.
By design, this is not possible as such - it's a single value field.
But there are ways around this limitation.
Since a number of people had this question, Atlassian has set up a page for the possible solutions/workarounds.
I looked through the questions and found a question somewhat related but it wasn't the same.
If you use the event_list_attendees api call you get back a list of attendees. Those attendees have a modified field. One of the possible parameters in the api call is modified_after.
My question is regarding what triggers the modified field to update? Is this a user profile related field or is it related to this particular event ticket purchase? The api describes these two as the following:
modified_after Return only attendees whose “modified” value is equal
to or after this date/time (e.g., “2013-01-28 00:00:00″)
modified The date and time the event was last modified, in ISO 8601
format (e.g., “2007-12-31 23:59:59″).
Perhaps to explain why I am wondering what triggers modified to update. The goal is to create a small, one day use, mobile website that will allow users to see who has shown up so far for a local event I am working with. I know the api does not directly support this functionality. In my case however "close enough" is "good enough". If someone's ticket being scanned at the door triggers the modified field that would be sufficient.
So, does it?
Great question!
The modified attribute relates only to the individual attendee in the order. So, it won't be triggered by the account wide profile changes for that respective user. However, if a user logs in to Eventbrite and changes the information that specifically relates to this event (example: they change the spelling on their last name for this specific order).
Alternatively, you can actually use /event_list_attendees and set "display_full_barcodes" to "true" to see the status of the barcodes. When the barcode is used, you'll know that someone has been scanned in.
If you come up with a cool hack, then we'd love to check it out!
Hope that helps!
I am trying to add stories to my product backlog.
Am I right in saying that, within the PBI in TFS(2012), for a story that sounds like:
As a user, I want to login to the system so that I have access to the features my login allows.
Is that a valid story? And then, within TFS, there's a 'Name' and a 'Description'. Wouldn't the description be what I wrote above, and the name be 'Login'? I'm battling to work out what best practice would be for entering my product backlog items.
When I have used TFS, I have tried to keep the "Title" (or "Name") to be a shortened value that can be easily searched and sorted. That value is used when displayed in queries and on the board, so I find it handy to have a different format than the standard user story description.
I would then recommend the user story text you have be in the description. Something like this:
Title: Authentication: Login
Description: As a user, I want to login to the system so that I have access to the features my login allows.
In earlier versions of TFS, I wasn't able to tag stories (which is now possible) so we used a Theme in the title of our stories to quickly identify in the Title what investment theme the story belong to (in my example, Authentication).
You may want to consider that the story may get broken down into multiple stories, and your Title should be able to be used to represent that. For example, you may have a story about an SSO requirement, a Logout requirement, a loading of personal details upon login, a "Remember Me" story, etc. Using your Title in such a way as to allow for the grouping of all these stories will help you down the road.
My version of the Scrum Process Template doesn't have a name field, I'm not sure where that is coming from (it might be a customization in your TFS instance).
Your story seems like a proper Title.
The Description would probably expand on the title adding because, why, value proposition. May possibly elaborate a bit more or give context to the story.
Be careful that the story you add has proper value. I as a user don't want to login to a system, I want it to recognize me in the easiest and secure way possible. I want it to ensure I am the only person who can see my personal data. A logon screen is an implemetation of these desires, but it's usually just one of them and possibly not the best one to match my demands as a user.