how to get Original logged version of a RTC workitem - rtc

how to get Original logged version value of a RTC workitem.
not the current version but the original version against which RTC item is logged.
Suppose current version is 2.0 but the original RTC item is logged against 1.0 . I need the last value of version which is 1.0.
Note: verison is a workItem Attribute.
Any help will be appreciated.

You can get the information by browsing the history of the work item.
As an example, on the web interface, once you have opened the work item, you have a "history" tab where you should see all the changes made. By searching the keyword "version" on the page, you should be able to spot any change in the value of this attribute
I would also invite to read the discussion about how to get the history of a work item

There is straight forward solution to manage attribute original value programmatically through deploying participant which would be responsible to store original value to some custom attribute before updating new one (you can check it by comparing workitem new & old state's attribute value), So that custom attribute will always pointing to the original value of Version Number attribute that will ease your effort than finding it from history
Hope it will help you

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.

Lookback API Displaying Old field name for the Custom Feild

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.

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 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.

Sharepoint 2013 - Fetch only last approved version through REST api

Before I ask my question I want to give you a quick overview about the topic.
I got a sharepoint list (SP 2013) which has content approval feature enabled. For this list you can choose who should see the draft versions of an item. Most logic option here is to let the author and all approvers see the draft. Now imagine that an item has been approved and now again edited. There is a version that is draft (because it needs to be approved again) and a version that had been approved before.
Here comes the tricky part :-). I fetch the items of that list via REST api. My query includes "_ModerationStatus eq 0" which means that I only fetch approved items. Users who are not allowed to see drafts automatically get the last-approved version of the item, although there is a draft version waiting to be approved. Users who are allowed to see draft versions see (I would expect something different here) NOTHING! So instead of fetching the last-approved item, the query has no result for users which are able to see drafts. Now if I perform the query without "_ModerationStatus eq 0" these users see the draft version while others (not allowed to see drafts) still see the last-approved version.
So finally my question is: Is there any chance to change this beaviour? I want SP to return the last approved version for ALL users via REST api. If these users open the SP-list itself they sure should see the draft. So it is only about the rest api.
I donĀ“t think that this is possible (did not find anything to change this) and I thik the REST api just mirrors the behaviour of the native view behaviour of the SP-list-view itself.
Thank you in advance!
regards
Ben
Here are two possible solutions for this problem:
Create a second list and let a workflow create or update items on this list whenever a new or updated item has been approved on the main list.
A: Worklist -> New or changed Item -> Workflow -> Create or update item on List B: Productionlist
Use the unique ID of items to check if an item does already exist on list B.
You can read about the second possible solution here: https://sharepoint.stackexchange.com/questions/116921/distinguish-between-approved-and-not-approved-items-rest-api
With OData__ModerationStatus it is possible to get the approval status for each item that your request fetched via REST. So you could probably place a flag DRAFT to any not approved draft versions to let the author and all approvers know that this is not an approved version.
Of course it is possible to get the last approved versions for each item but that will cause a need for additional requests and validation etc.
Hope this helps :)
Just use the following,
http://WebAppUrl/_api/web/getfilebyserverrelativeurl('/RelativePathToFile')/MajorVersion
Example:
http://contoso.com/_api/web/getfilebyserverrelativeurl('/_catalogs/masterpage/css/main.css')/MajorVersion
That returns the recent major version published