View Issue Details

IDProjectCategoryView StatusLast Update
0000870Main CAcert Websiteweb of trustpublic2013-01-18 00:11
ReporteredgarwahnAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionduplicate 
Product Version 
Target VersionFixed in Version2013 Q1 
Summary0000870: My Details - My Points show bugus time stamp
DescriptionWhen 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 InformationThe 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.
TagsNo tags attached.
Reviewed by
Test Instructions

Relationships

related to 0000801 closed Date of assurance should be in user's timezone 
related to 0001014 closedINOPIAE Remove the system of automatically adding a timestamp 
related to 0001023 needs workEva Consolidate changes into the Assure Someone page 
related to 0001137 closedBenBE 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 

Activities

Andreas Baess

2010-10-05 12:09

developer   ~0001728

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

edgarwahn

2010-10-06 10:50

developer   ~0001733

Last edited: 2010-10-06 10:51

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, ...).

INOPIAE

2013-01-18 00:11

updater   ~0003700

the date check is included in bug https://bugs.cacert.org/view.php?id=1137.
Old data will not be fixed.

Issue History

Date Modified Username Field Change
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