Open for edit a ISO19139-mcp1.4 record resets start/end date to 1970-01-01

[awalsh]

Using GN trunk v2.8.0 SVN9195 + ANZMEST branch. I file imported an valid sample ISO19139-MCP record from our production GN and tested the validation function. In order to validate the record needs to be opened for edit Action of opening for edit and then close (no save) actually altered the start and end date fields i.e this:

<gml:TimePeriod gml:id="d1e1"><gml:beginPosition>2011-12-05T02:12:00Z</gml:beginPosition><gml:endPosition>2011-12-08T03:46:00Z</gml:endPosition></gml:TimePeriod>

became

<gml:TimePeriod gml:id="d1e1"> <gml:beginPosition>1970-01-01T00:00:00</gml:beginPosition> <gml:endPosition>1970-01-01T00:00:00</gml:endPosition> </gml:TimePeriod>

This looks like the same issue as reported in:

​http://trac.osgeo.org/geonetwork/ticket/661

[ianwallen]

Potential patch

[ianwallen]

I applied a potential patch.

The approach taken is that if the date/time supplied does not match the supported format then it places the full text in the date field and leaves the time field blank. This way nothing is changed.

Also updated code so that it does not fire trigger when loosing focus which was causing the data to be changed.

The DateTime.js file that was modified seems to be related to a supplied package. So not sure if we really want to modify this file or it would be better to use another approach.

Looking for someone to review the patch to see if it makes sense...

[awalsh]

Ian,

Thanks I have applied and tested the patch. I works OK from respect of not altering a 'Z' date/time however I have not tested other use cases such as entering date/time and then changing it.

I notice there a 3 DateTime.js in different places perhaps some are used by the widgets? interface. Anyway I only patched the one in web/geonetwork/scripts/map/Ext.ux/form/DateTime.js

From a code point of view I can't review the quality, over to the developers.....

Andrew

[ianwallen]

I was having issues where dates containing only the year were getting modified by the interface. I have testing adding different type of data and it seems to work. Any data containing timezone information (or not following the date format) will not be able to use the date selector to update the content. It is not perfect however at least it is not changing existing data.

I had forgotten about the other 2 DateTime.js files. (thanks for pointing it out) I'm not sure where they are used.

I'm not 100% sure where the DateTime.js comes from - I found an updated version from the following site. ​http://www.sencha.com/forum/showthread.php?22661-new-version-DateTime-Field I also applied the updates to DateTime.js - it looks like they have fixed some bugs with IE. So if this is not an official package from extjs (as it seems to have come from a newsgroup posting) then it should be OK to apply changes to it.

I also found a bug - When using the simple date fields, it was not accepting simple years as a date. i.e. submitting 2000 was changing the value to null.

I have made some more corrections and I have submitted a pull request(#26) to have the changes implemented. (This includes the other 2 DateTime.js files)

[awalsh]

Ian,

Thanks, good work! looks like you have covered most of the bases.

Jesse,

Thanks for the commit to 2.8.x branch. Once this is all proven/OK will the change make it into the master branch.

Andrew

[jeichar]

Merged to master branch. Thanks for the notice. Can we close this ticket?

[awalsh]

Jesse,

Guess you can close in absence of any other testing/comments.

Cheers,

Andrew

[ianwallen]

Closing as changes are commited to the branch/master and it seems to work - if any one has any issues they can reopen the ticket.