Retrieve Defect Data per iteration - rally

I want to have a drop down menu that can let me choose a particular iteration from the list of all iterations and can display the defect data for that chosen iteration. I am very new to Rally API so might be a very simple question but your response would be really helpful. Thanks

See Filterable Tree Grid example that uses an iteration combobox to filter artifacts, including defects. See also a Filterable Grid example that filters defects by State.
Here is an app example that builds a grid of stories filtered by iteration combobox and grouped by "parent" initiatives. You may easily change it to build a grid of defects grouped by associated requirements.

Related

How to Collect dijit/form/combobox Selected Values in Repeat Control

An XPage is used to display the number of points a person has collected, and the number of points remaining (see below).
I have a repeat control which gets a collection of documents meeting a specific criteria. The last column in the control contains 5 digit/form/comboboxes, which are displayed or hidden, according to the number of fields on each document that contain data.
The layout contains gift cards worth a certain amount of points, and the person can select how many of each gift card they want. eg.
Company Available in Values of Points Required Quantity Requested
The Quantity Requested column contains the digit/form/comboboxes. As the person selects values in the checkbox, I want the number of points remaining to be recalculated.
The onChange event of the digit/form/comboboxes calls a function in an Output Script which calls an RPC, which in turn calls an SSJS function. The SSJS function cycles through the documents displayed in the repeat control, gathering the points required information. I then wanted it to also grab the Quantity Requested. I understand from a previous posting that because of the way the digit/form/combox is rendered, I can only get the value using CSJS with dijit.byId and perhaps putting the value in a hidden field and retrieving it from there.
I can't seem to wrap my head around how I will do this when the repeat control will make it possible for there to be many combobox1 and combobox2, etc.
The XPage is not bound to a form, because all the items are just calculated on the fly and then discarded.
What is the best way to do this?
The JSON RPC service can't interact with any changes made in the browser, see https://www.intec.co.uk/json-rpc-service-component-tree-manipulation-openlog/. This could be the cause of your problems.
You may be able to get around it by triggering a partial refresh (POST) before calling the JSON RPC. In theory that might work, because the component tree (server-side map of the XPage) would get updated by the partialRefreshPost and the updates picked up by the JSON RPC. It's possible though that the Restore View picks up a version of the XPage other than the one for the browser, I don't know. I've never investigated that.
It's been a while since I've worked with server java script, I have been doing it the managed bean way with ActionListeners. If you have the data in the UI, then can you avoid server side processing and do it client side?
You can also use the DOM XSP Object like XSP.setSubmittedValue to have a key value pair sent with your post request to the server side, you can only have one... it can be JSON or any other value you set it to from the client side javascript.
I figured out how to do this. If anyone wants the code, let me know and I'll provide it.

How to add two models in single store or single grid based on -ref and date range in customize rally app?

I am a beginner for the development of customized rally app. I have a portfolio item and revisions for every Marketable feature. I have two models PortfolioItem/MarketableFeature and Revision, using this two models I want to make a grid.
I facing issue for combining two models or two stores, for customized rally app models config is not work for any grid. I am confused on how to get revision description and PortfolioItem/MarketableFeature in one grid based on date range and according to MF Id.
i used
Rally.ui.grid.Grid
for creating a grid,
Rally.data.wsapi.Store
for creating store and
Rally.ui.combobox.FieldValueComboBox
for date range(start-date and end-date).
You'll want to create your grid with the MarketableFeature model. Is there another way to get the data you need other than loading all the revisions? This will be very expensive and slow since you'll be making 1 request per grid row in addition to the initial request to populate the portfolio items.
If you do need to do that then you'll probably want to do a combination of these two examples:
Fetching subcollections:
https://help.rallydev.com/apps/2.1/doc/#!/guide/collections_in_v2-section-collection-fetching
Custom renderer, you can use this to render the Revisions data:
https://help.rallydev.com/apps/2.1/doc/#!/example/custom-data-grid

Asserting on data that is derived from a previous step

When a piece of data that I want to assert on in a later test is derived from an earlier step, is there an accepted method of storing and recalling that data later on in the scenario?
For example:
Scenario: Recently viewed product
Given I am on a product category page
And I click on the first product
When I am on a product category page
Then the recently viewed products should list the product I just viewed
On the step And I click on the first product can I somehow persist the product name so that I can assert that I am actually seeing that product in the last step? The reason I can't specify an actual product name in the feature file is that this could and will become out of sync with live product data.
Thanks!
It's entirely up to you how you implement this. The simplest way is in your "I click on the first product" step definition store the clicked product information in a static variable (or as a global variable) and then use it in "the recently viewed products should list the product I just viewed" step to verify it's present.
Store the values you need to persist between steps as FeatureContext class properties.
Don't forget to clear them when the Scenario ends, or before each new Scenario.

Possible to fetch full hierarchical requirements in single portfolio item web service call?

I'm trying to aggregate some information about the kanban states of my user stories. If query a PifTeam item, I get a summarized collection of UserStories associated with it.
Example query:
https://rally1.rallydev.com/slm/webservice/1.40/portfolioitem/pifteam/99999999999.js
However I then have to run a loop on the UserStories collection, individually querying each one to get at the information I need. This potentially results in a lot of web service calls.
Is there a way to return the full hierarchical requirement information in the original pifteam query so that there is only one webservice call which returns all sub-objects? I read the webservice api and was trying to play with the fetch parameter but had no success.
This functionality will be disabled in WSAPI 2.0 but will continue to be available in the 1.x versions. That said, you should be able to use a fetch the fields on story that you need like this:
/pifteam/9999.js?fetch=UserStories,FormattedID,Name,PlanEstimate,KanbanState
Fetch will hydrate the fields specified on sub objects even if the root object type doesn't have those fields. So by fetching UserStories the returned collection will populated with stories, each having the FormattedID, Name, PlanEstimate and KanbanState fields included.
There is no way to do it from Rally's standard Web Services API (WSAPI) but you can from the new Lookback API (LBAPI). The query would look something like this:
https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/<ObjectID_for_Workspace>/artifact/snapshot/query.js?find={__At:"current",_TypeHierarchy:"HierarchicalRequirement",Children:null,_ItemHierarchy:<ObjectID_for_PortfolioItem>}&fields=["Name"]
Fill in the ObjectIDs for your Workspace and PortfolioItem. The _ItemHierarchy field will cross work item type boundaries and goes all the way from PortfolioItems down through the Story hierarchy down to Defects and even Tasks, so I added _TypeHierarchy:"HierarchicalRequirement" to limit it to Stories. I have specified Children:null which means you'll only get back leaf Stories. The __At:"current" clause get's the current tree and values. Remember, it's the "Lookback" API, so you can retrieve the state of the object at any moment in history. __At:"current" says to get the current values and tree.
Note, the LBAPI is delayed from current values in the system by anywhere from seconds to minutes. Typically it's about 30 seconds behind. You can see how far behind it is by checking the ETLDate field in the response.
Details about the LBAPI can be found here. Note, that the LBAPI is available in preview now for almost all Rally customers. There are still a number of customers where it is not yet turned on. The best way to tell if it's working for your subscription is to try the query.

Getting asana "now" tasks and "today" tasks under project and user via API

From within Asana, we can see how the tasks are split into "Now", "Next" and "later" in project view as well as "Today", "Upcoming" and "later" in user. I can't seem to find the API required to identify the tasks in each category. Is this functionality available for developers?
(I work at Asana)
In the reference for Tasks at https://asana.com/developers/api-reference/tasks, the docs describe the assignee_status field. This will give you the today/upcoming/later status for a task assigned to a user.
In project view, these statuses don't exist so I assume that by now/next/later you are referring to "priority headings", or arbitrary labels that you are able to create inside any list by ending the name of a task with a colon (:). There is not currently a way to find out which priority heading a task is under via the API.
If knowing the priority heading containing a task is important, you could iterate over the results (which by default show up in the same order they do in the UI), keeping track of which priority heading you saw last. This is inelegant and prone to problems if you filter the task list in some way (and possibly don't get all the priority headings as a result), but it might help you get the job done until a better solution is provided.
If you are querying for a list of tasks, make sure you add the opt_fields=assignee_status parameter and that field will be provided in each of your results.