I’m having an odd issue with the updating of a task in the Rest API where the meta data for the “Created” Property is changing to:
Created 12/31/1969 4:00:00 PM
When updating a fixlet/task in the Console, that Created Property stays consistent with the original creation date. In the API, that is not happening. Is that happening to anybody else?
The source release date is in the YYYY-MM-DD format per the documentation:
<SourceReleaseDate> NonNegativeDate </SourceReleaseDate> [0..1]
Must be of the form YYYY-MM-DD.
In the XML file that I am using, it is filled out as follow:
2014-12-15
So I don’t believe this is the issue. There are no other dates specified in the fields.
A few more observations: I created a new fixlet and tried updating it via PostMan in the Chrome Browser and the same behavior occurred. The “Created” time field changed to the 1970 date and the “Creator” field changed to the account making the modification as well. Normally, these values in the fields never change and keep the original creation timestamp of the fixlet and the original creator of it, but updating the fixlet via the Rest API using PUT changes/updates these values to the login that is updating the fixlet and the odd timestamp kicks in.
The original example was used with/modified via Powershell. I will try tomorrow with Curl and see if anything different happens.
Is there a time zone setting to specify on the main server that perhaps I missed?
Here’s the XML file from the script that runs, but with variables in place. I can post the xml with the variables filled out with values if needed:
<?xml version="1.0" encoding="UTF-8"?>
<BES xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="BES.xsd">
<Task>
<Title><![CDATA[<Custom Content>: Mozilla Thunderbird $Version Upgrade]]></Title>
<Description><![CDATA[<DIV class=subsection>This task will upgrade Thunderbird to the latest version on Windows Machines. </DIV>
<DIV class=subsection>Notes:</DIV>
<DIV class=subsection>$UpdatedDate - Upgraded to $Version</DIV>]]></Description>
<Relevance>name of operating system as lowercase starts with "win"</Relevance>
<Relevance>(if( name of operating system starts with "Win" ) then platform id of operating system != 3 else false) AND (if exists property "in proxy agent context" then ( not in proxy agent context ) else true )</Relevance>
<Relevance>exists key whose (name of it as lowercase starts with "mozilla" AND exists key whose (name of it = "Mozilla Thunderbird") of it) of key "HKLM\SOFTWARE\" of registry</Relevance>
<Relevance>not exists values "PROCESSOR_ARCHITECTURE" whose (it as string as lowercase = "ia64") of keys "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" of registry</Relevance>
<Relevance>exists value "CurrentVersion" whose (it as string contains "en-US") of keys "HKEY_LOCAL_MACHINE\Software\Mozilla\Mozilla Thunderbird" of registry</Relevance>
<Relevance><![CDATA[(exists regapp "thunderbird.exe" whose (product version of it < "$Version")) OR (exists value "CurrentVersion" whose ((preceding text of first " " of (it as string)) as version < "$Version") of keys "HKEY_LOCAL_MACHINE\Software\Mozilla\Mozilla Thunderbird" of registry)]]></Relevance>
<Category>Content Upgrades</Category>
<DownloadSize>$FileSize</DownloadSize>
<Source>CompanyName</Source>
<SourceReleaseDate>$UpdatedDate</SourceReleaseDate>
<Domain>BESC</Domain>
<DefaultAction ID="Action1">
<Description>
<PreLink>Click </PreLink>
<Link>here </Link>
<PostLink>to initiate the deployment process.</PostLink>
</Description>
<ActionScript MIMEType="application/x-Fixlet-Windows-Shell"><![CDATA[
prefetch Thunderbird_Setup.exe sha1:$Sha1Hash size:$FileSize $DownloadURL sha256:$Sha256Hash
continue if {NOT exists running application whose (name of it as lowercase = "thunderbird.exe")}
regset "[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\FilesToDelete]" "MozillaThunderbirdDesktopIcon"="{if (exists file ((value "Common Desktop" of key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" of registry as string)&"\Mozilla Thunderbird.lnk")) then "" else escape of (value "Common Desktop" of key "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders" of registry as string & "\Mozilla Thunderbird.lnk")}"
wait __Download\Thunderbird_Setup.exe -ms -ira -hideBanner -cleanUpOnUpgrade
delete {value "MozillaThunderbirdDesktopIcon" of key "HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\FilesToDelete" of registry as string}
regdelete "[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\FilesToDelete]" "MozillaThunderbirdDesktopIcon"
]]></ActionScript>
<SuccessCriteria Option="RunToCompletion"></SuccessCriteria>
</DefaultAction>
</Task>
</BES>
One last thing to throw your way - when creating a Task or Fixlet, the XML tag or needs to be properly specified depending on if you are creating a task of fixlet. If trying to create a Task and using XML tag or create a Fixlet using XML tag , then the API errors out as it should. But when trying to update a fixlet or a task, the API allows you to update by calling either “https://$server/api/task/custom/$CustomSite/$ID” and “https://$server/api/fixlet/custom/$CustomSite/$ID” - these 2 calls are interchangeable apparently from my testing.
I finally got a chance to play with this. I think you’re right, something fishy is going on. I was able to reproduce your weird creation time bug with the following command:
I’m playing with this on an experimental build of the TEM platform, but I think it’s probably happening in at least 9.1. In the meantime, I think you can use source release date or modification time of a fixlet to figure out when the actual “creation” time of a fixlet is.
I’ve filled a bug (#65821) internally to keep track of this one. Thanks for the report!