View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000870||Main CAcert Website||web of trust||public||2010-10-01 08:57||2013-01-18 00:11|
|Target Version||Fixed in Version||2013 Q1|
|Summary||0000870: My Details - My Points show bugus time stamp|
|Description||When you look at your own points, you will see that the date field is bogus, sometimes it shows date & time. Date format differs (us, de).|
|Additional Information||The notary table defines date as char(255) and an created + expire attribute (date or datetime). While the created and expire attribute are filled automatically, the date field is an free form field entered by the user.|
It would be better to add the system created date to the output to prevent ambiguities. I.e. if someone by mistake or by bad faith enters false information here.
Another solution could be to enforce an standardized date format.
|Tags||No tags attached.|
|related to||0000801||closed||Date of assurance should be in user's timezone|
|related to||0001014||closed||INOPIAE||Remove the system of automatically adding a timestamp|
|related to||0001023||needs work||Eva||Consolidate changes into the Assure Someone page|
|related to||0001137||closed||BenBE||Record the CCA acception for entering an assurance|
|related to||0000583||closed||"Assure Somebody" allows future assurance dates|
|related to||0000931||closed||Date of assurance in future don't throw any exception|
I support a standardized date format in this page because it looks more professional. I suggest a twofold approach:
1. change the software that it stores the information in the format YYYY-MM-DD without the time of day, as this is also not collected/required in the CAP forms
2. Write a query that selects assurances that have other contents in that field and make suggestions how to update these records in the database to be conformant with the above standard.
3. Code SQL updates that would change the content of those fields and provide the original databse content and update list to an arbitrator who will decide if he authorizes the updates
4. There may be database content that require support help to contact the assurers to lookup their forms if the date could not be identified
Then we would need a code change prior to the fix to prevent new fancy date entries. After closing that hole we can consider to fix the existing mess.
=> grab date in posted form, analyse date & convert to standard if possible, otherwise reject post and redisplay edit form to assurer.
Maybe we could include JQuery Datepicker or such modern, fancy stuff? But we still need to check input on the server side (JS turned off, manual override, ...).
the date check is included in bug https://bugs.cacert.org/view.php?id=1137.
Old data will not be fixed.
|2010-10-01 08:57||edgarwahn||New Issue|
|2010-10-05 12:09||Andreas Baess||Note Added: 0001728|
|2010-10-06 10:35||Uli60||Relationship added||related to 0000801|
|2010-10-06 10:50||edgarwahn||Note Added: 0001733|
|2010-10-06 10:51||edgarwahn||Note Edited: 0001733|
|2012-05-28 10:03||INOPIAE||Relationship added||related to 0001014|
|2012-05-28 10:03||INOPIAE||Relationship added||related to 0001023|
|2012-05-28 10:16||INOPIAE||Relationship added||related to 0000583|
|2012-12-27 05:39||Werner Dworak||Relationship added||related to 0000931|
|2013-01-18 00:10||INOPIAE||Relationship added||related to 0001137|
|2013-01-18 00:11||INOPIAE||Note Added: 0003700|
|2013-01-18 00:11||INOPIAE||Status||new => closed|
|2013-01-18 00:11||INOPIAE||Resolution||open => duplicate|
|2013-01-18 00:11||INOPIAE||Fixed in Version||=> 2013 Q1|