Lookback API Displaying Old field name for the Custom Feild - rally

We are facing a strange issue with the Look-back API.
We have created a Custom field initially as xyz, back end name c_xyz for the features.
After few days we renamed the Custom attribute to abc which in-turn changed the back-end name to c_abc, which was an expected behavior.
However , the Lookback API still gives the old field name c_xyz in the result set of that object till we actually make an update via UI/API on the abc(c_abc) attribute. Is there any way we can workaround this, apart from updating the particular value.

Briefly, no. Responding to field name changes in this way would be a big performance hit.

Related

Find latest ScheduleState change in Lookback API

I want to display a list of US ScheduleState changes, but not all of them, only the latest change. And not only Accepted, but the current state.
I tried using ValidTo > Current, but this is not always the case, other changes might have occured, so that the ValidTo on the latest ScheduleState change is in the past.
So, is it possible to retrieve only the latest revision/ScheduleState change "automatically" via the loopback API - or do I need to do this "manually" after the load of all ScheduleState changes?
The LBAPI uses the date 9999-01-01 to indicate that the change is last one for the set of things you have asked about. So, if you ask for information on two fields, you will get two records with a date like that. You will then have to work out what you want to know next: the last change on each field, on the last change of either field on the artefact (by looking at the _ValidFrom field).
If you want to know the current state, that's done differently with the __At field in a 'find'. But then, that doesn't tell you what/when the last changes were.

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.

Google Place Autocomplete API returning wrong place id

Since today (or yesterday) the Google Place Autocomplete web service (https://developers.google.com/places/web-service/autocomplete) is returning a wrong place id (place_id). Does anyone know how to get the right place id from the Autocomplete API?
For example, the place id for New York City is ChIJOwg_06VPwokRYv534QaPC8g (according to the Place Details API), but the Autocomplete API returns ChIJOwg_06VPwokRYv534QaPC8iaBilOZXcgWW9yayBDaXR5LCBOZXcgWW9yaywgVmVyZW5pZ2RlIFN0YXRlbg as place_id. The beginning of the string is almost the same, except for the last character of the 'right' place id (g).
Is this a bug or is Google changing their place ids? Unfortunately I can't find anything related to this problem.
Some place ids from the Place Autocomplete API have been altered due to a recent issue: https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107. The longer place ids should be accepted by all Maps APIs (but see the caveat in https://code.google.com/p/gmaps-api-issues/issues/detail?id=11107#c30).
Unfortunately, this will be around for some time. A way to get the "short" place id corresponding to a long one is to issue a Place Details call with the long place id (the returned result will have a short place id).

how to create version one burned down chart using java REST client api

I am trying to get the data to create the burned down chart from version one.
I came to know there is no standard api's for that.
Here i found that by making multiple call's to fetch todo value for a scope of timebox it is possible.
Is there any better way to do it?
and also let me know any good open source libraries(javascrpt/java) to plot such graph
i tried the way shown here but i am not able to make out what value i am getting.
i tried a get request like
"base URL"/rest-1.v1/Data/Timebox?where=State.Code='ACTV'&asof"11-25-2015"&sel=Name,EndDate,State,Workitems.ToDo.#Sum
but could only get present value but not the past ones.
Thanks in advance
You are using the rest-1.v1/Data endpoint. From this endpoint you will get the current state of assets in your VersionOne instance however, there is an attribute "Prior" which contains the previous state of a VersionOne asset (Timebox). The most robust way to access historical data is though the rest-1.v1/Hist endpoint. You can find details about Hist queries here.
Using your query
"base URL"/rest-1.v1/Hist/Timebox?where=State.Code='ACTV'&asof"2015-11-25T17:30:00.00"&sel=Name,EndDate,State,Workitems.ToDo.#Sum
The asof keyword will return the state of that Timebox at that instance in time. Observe the proper format of the date.

Can you get the field base name instead of the translated name when using the JIRA rest api?

The JIRA rest api documentation suggests that you should use the field name when sending in a custom field for a create issue request, because they are not unique across instances.
However, the field names you receive from calling the meta-data on a project are translated based on the language settings of the user. That also means that the field names are subject to change, because translations are controlled by the client.
Is there any way to recover the field's base name (which is not changeable) rather than the field's translated name, when calling the createmeta function?
(Or another best practice for determining which custom field you need to set which data to?)
I think you Can Not.
In my recent plugin I had to add fields to the settings screen to map Epic Name and Epic Link:
- Epic Name custom field name:
- Epic Link custom field name: