Task Updated in Rest API Changes Created Date Property

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?

Looking around the documentation and forums, I couldn’t find the XML tag for that property. Source, Download Size, Category, Sources Release Date, etc are all in the documentation here:

Are there any ideas or reasons that you can think of why this might be happening. Or a solution of how to fix it?

Thanks in Advance!

That time looks like you are in PST and that you somehow got a time of “0” which is actually Jan 1, 1970 but its being adjusted by your time zone.

It suggests the date string might be incorrectly formatted or an impossible date?

1 Like

Hi Alan -

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:

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?

Thanks again!

1 Like

I think we can figure this one out…

cdh, do you mind maybe posting the xml of what you’re trying to post?

And your use case is that you’re trying to update a fixlet or just to create a new one?

Hi Dex,

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">
        <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>
        <DefaultAction ID="Action1">
                <PreLink>Click </PreLink>
                <Link>here </Link>
                <PostLink>to initiate the deployment process.</PostLink>
            <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"
            <SuccessCriteria Option="RunToCompletion"></SuccessCriteria>

Dex -

Sorry, for to include the other relevant info.

This is a task to upgrade Thunderbird. The use case is that we are trying to update a current existing fixlet on our server.

We’re testing this through Powershell and the Invoke-RestMethod cmdlet. Here’s the command that is run:

Invoke-RestMethod -uri "server.com" -method "Put" -Body $XMLFile -Credential $OperatorCredentials -ContentType "text/xml"

So you’re use case is to test updating fixlets, but you’re seeing behavior for updating fixlets and creating new fixlets too ya?

Hi DexDexDex,

Yes, the use case is to test updating fixlets. I didn’t try nor test this in creating a fixlet/task so I spent some time testing this morning.

Using the XML submitted above for the Thunderbird Upgrade task, here are the results:

To Create a Fixlet, called “https://$server/api/fixlets/custom/$CustomSite” and the proper timestamp showed up for the “Created” field

To Create a Task, called “https://$server/api/tasks/custom/$CustomSite” and the proper timestamp showed up for the “Created” field

However, when updating a Fixlet by calling “https://$server/api/fixlet/custom/$CustomSite/$FixletID” and a Task by calling “https://$server/api/task/custom/$CustomSite/$TaskID” – the same incorrect date as reported above is being changed in the “Created” field with a value of "12/31/1969 4:00:00 PM ". The good news, though, is the “Last Modified Date” field is showing the correct value.

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.

hey cdh-

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:

curl -X PUT --data-binary @SampleAction.xml --user bigfix:bigfix --insecure

But obviously, POST commands had the right creation date:

curl -X POST --data @SampleAction.xml --user bigfix:bigfix --insecure

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!

The temporary workaround for using source release date/modification time will suffice for now. Thank you for looking into this!