Find latest ScheduleState change in Lookback API - rally

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.

Related

How to get a product modification log in Prestashop?

Is there a way to know what specific changes were made to a product in Prestashop 1.7?
In Advanced parameters> Logs I can see the employee who has made the modification, the severity, the message of the modification, the id of the object that has been modified and the date on which the modification was made, but it does not show me what the modification was. specific change that was made, if the name, price, description etc.
Is there a way to know that?
There is a way but it's a complex issue, you can hook into dynamic hooks like:
actionObjecProductUpdateBefore
and
actionObjectProductUpdateAfter
and compare two set of object data to see what has been changed.
Of course if you want to log more detailed informations like changes in Specific Prices etc. you also need to get informations about them before and after product change, it might be a time and resource consuming operation so be careful with it.

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 set Custom Fields Notifications in HP Project and Portfolio Management(PPM)?

I am using HP Project and Portfolio Management(PPM) tool and I am adding a custom field in my request type which has date as value. Now my requirement is to send the email notifications to the users once the date mentioned in the custom field crosses the system date.
I had tried to set the notification for field level from Notification tab but not getting the custom fields in the list. All the fields, which is available, are pre-configured fields.
So, can anyone suggest me how to implement this requirement? And also where the changes need to be done If any required to implement this?
Please answer in detail and also reply soon.
Thanks in advance!!
PPM notifications can be configured on pre-defined events, like a certain transition, or timeout etc...
One possible solution for this scenario is to have timeouts on your decision step. Time out goes to an execution step, which checks for the date condition. If the condition is met it fires the notification. Else it just returns to the original decision step.
The downside of this work around is that there will be transaction details added once daily. Also the last update date of the request keeps updating daily, which is not ideal if you want to track what was the last time an end user update the request.
It is a workaround cause of the restrictions around notification events.
And if you have a large workflow, I would not recommend this work around.

QuickBooks API - Retrieve only data that has changed

I am building an app that accesses the QuickBooks API v2.
I am looking for a way to retrieve only data that has changed.
For example, from time to time want to be able to check to see if there have been any changes to the chart of accounts in the QB data. Is there a quick way to do this without parsing a large response body? Maybe something like requesting and comparing just a checksum, and then requesting the whole chart of accounts to compare and update if there is a change? Or even just requesting the changes that occurred after a certain date?
This need is not just limited to the chart of accounts. For example, I may want to update historic transaction data, but only with the changes (e.g., a change to an old transaction), not the entire db which can be quite large.
Answer
In further reading the API docs, I should be able to filter the response using the created_at and updated_at metadata.
The filter is called Change Data Capture (CDC)
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v2/0500_quickbooks_windows/0100_calling_data_services/0015_retrieving_objects
<ItemReceiptQuery xmlns='http://www.intuit.com/sb/cdm/v2'>
<CDCAsOf>2010-12-04T09:30:47.0Z</CDCAsOf>
</ItemReceiptQuery>
thanks
Jarred

Example for when to use [NSCalendar autoupdatingCurrentCalendar]

I'm looking for an example where + autoupdatingCurrentCalendar would be used instead of + currentCalendar. More specifically where the values based on the calendar are automatically changed when the calendar changes. Do I need bindings for this or something like that?
The docs state:
Note that if you cache values based on
the calendar or related information
those caches will of course not be
automatically updated by the updating
of the calendar object.
Thanks in advance
currentCalendar returns cached version of current system calendar, while autoupdatingCurrentCalendar always returns most recent version of system calendar.
That is important, when you are presenting data based on the various parameters of a calendar like number of days in a month, number of a weeks in year or number of hours in a day.
To be honest, I don't know why Apple gives you an opportunity to get outdated value by using currentCalendar.
It looks like they have internal API that allows you to manipulate caches of NSCalendar, so you can achieve better performance. But since it is not public, there is no reason to use currentCalendar.
That is, always use autoupdatingCurrentCalendar.
Well, on OS X you can be running multiple processes simultaneous. One could be your process that uses the autoupdatingCurrentCalendar. The other could be System Preferences.
System Preferences allows you to customize your calendar settings. You can choose the first day of the week to be something other than the default (Sunday). Or you can choose a whole different calendar altogether. If you use the autoupdatingCurrentCalendar, these changes will be picked up automatically. If you don't use it, they won't.
I guess that it is only usefull if you store the calendar in memory for further use. Doing that way, if the calendar settings change, your stored calendar will take account of those changes if you used autoupdatingCurrentCalendar. If you only used currentCalendar, it wil stay at the state it was at your first call.