We're migrating some data from page assets with metadata to the more appropriate news item assets. This is mostly fine, but we've not found a way of preserving the original publishing date and creator information. Is there a way to do this? This data doesn't appear to be treated as an asset attribute, so can't be set with setAttribute, but it is possible to set it through the back end, so it seems reasonable that there would be a programmatic method to set it as well.
Edit: There is a trigger to set the date fields based on a metadata field, but whilst it works for created date, it doesn't appear to behave for published or updated dates, and it seems less than optimal to set a metadata value in JS, then once that's done, change the actual dates.
Those dates info are recorded in sq_ast DB table.
When you import those assets to new system, they are created as new assets, so all these dates will be reset. The export script also doesn't export those dates anyway.
I assume you are using xml import/export script. It would require development to allow it to export those dates in a special action, and import those dates and override system default dates after import of assets.
If you really want to those dates to be set on new imported asset, you will have to come up with your own script solution, to copy the dates from the original DB table, and set it on new assets.
Actually, we're bouncing the records off a JS API based page, since it allows for easier modification of fields that require adjustments. This means that the dates are extracted with a getGeneral call, which works as expected, fiddling round with some of the other fields which require adjustment, then making a batchRequest call with a load of setAttribute and setMetadata calls. As I mentioned in my edit, I've now got a method for the created date which works, by putting the desired date in a metadata field and using a trigger to write this value to the date field, but it doesn't work for publishing dates, which are the ones we really could use, and I've not found a method to preserve the creator details.
We've previously tried using XML export and import, but the documentation for that is abysmal, especially if you want to do anything more than exactly clone content. The documentation for the JS API isn't great either, but it at least gives a list of input parameters, even if it does ignore what return values are produced for the most part.
This seems an odd omission from the API, since there is a function in the system to do it (as used by the trigger), and it limits the potential of the JS API to be a full replacement for the Java based backend systems.
[quote]
This seems an odd omission from the API, since there is a function in the system to do it (as used by the trigger), and it limits the potential of the JS API to be a full replacement for the Java based backend systems.
[/quote]
I don't think this was ever the intention of the JS API. To replace the entire backend functionality would be crazy. 
[quote]
I don't think this was ever the intention of the JS API. To replace the entire backend functionality would be crazy.
[/quote]
Not really. The Java applet requirement is a massive limitation of the system, and getting rid of that would solve a lot of common issues (at least, of the ones we see regularly). It also limits the potential for administration of Squiz Matrix from systems in high security environments, where it's increasingly common for Java to be disabled due to the huge numbers of security issues it causes, and from tablet computers (the iPad, the Surface and all Android based tablets don't support Java, but we have users where they are their main method of accessing systems - even the Easy Edit suite needs Java for some functions, such as inserting images). An app is helpful (although as far as I'm aware, it's only for Apple devices, which limits it somewhat), but not as good as a system where the core functionality is fully accessible to these users by default. I'm not even talking about complex admin tasks here - we want users to be able to edit pages, upload images, and link to other pages from whatever device they use on a daily basis. If that requires software they can't even get for that device, it's a serious problem.
[quote]
An app is helpful (although as far as I'm aware, it's only for Apple devices, which limits it somewhat), but not as good as a system where the core functionality is fully accessible to these users by default.
[/quote]
Yes, the app that I am working on is only for iOS.