View Issue Details

IDProjectCategoryView StatusLast Update
05374Development Survey takingpublic2019-09-23 12:20
Reportermdekker Assigned To 
PrioritynormalSeverityminor 
Status confirmedResolutionopen 
Target Version2.00 
Summary05374: Tokentable sent and completed fields are too small to hold a date/time field
Description

The definition of the fields sent and completed in the token table is set to C(17), which cuts off the seconds.

Additional Information

Maybe change to a real timestamp or ake it a little wider.

TagsNo tags attached.

Activities

c_schmitz

c_schmitz

2013-03-06 09:09

administrator   ~24562

Last edited: 2013-03-06 09:10

View 2 revisions

I suggest the following changes:

  • Rename sent to invitation_sent and make it a datetime field - if NULL no invitations was sent
  • Rename remindersent to last_reminder_sent and make it a datetime field - if NULL no reminder was sent yet
  • Make completed to datetime field - will only be set it survey is not anonymized and completed_status !=N
  • Add a new field completed_status which specifies the completion: N (No), Y (Yes) or (Q) (ended by Quota)

What do you think?

mdekker

mdekker

2013-03-18 09:10

reporter   ~24749

It seems like a good plan to me, but it would mean that a lot of code needs to be touched. That would be a good moment to move all the calls and logic to the model.

We have developed code that reads the database directly and I can imagine other people have done the same in absence of the remote controle we have now. That should ofcourse not be a reason to hold back on the change. A clear message about this change in the changelog would be good I think.

sammousa

sammousa

2013-03-26 10:08

reporter   ~24867

@c_schmitz: I agree mostly.
The completion date should in my opinion not be part of the token since it is already part of the response... this is duplication of information that serves very little purpose: joining 2 tables isnt that heavy and we dont need to do it often anyway.

Also i'd prefer to have a status field instead of a completed_status field. Maybe instead of holding on to 1 letter codes we can just use descriptive strings instead?
Status:

  • 'not started',
  • 'in progress',
  • 'quota',
  • 'completed'
  • 'opted out'

This also makes integration easier in case you want to add more; for example: in the Netherlands commercial companies MUST check their emails against a company blacklist in case I told them I dont want to receive any further mail from them. (It's not excactly like that, but that doesnt matter).

In this case putting it to 'blacklist' would be more intuitive.

Although my specific example might be better for the email status field, undoubtedly there examples that apply to the status field of the token.

Issue History

Date Modified Username Field Change
2011-08-02 15:29 mdekker New Issue
2011-08-03 17:38 c_schmitz Assigned To => magiclko
2011-08-03 17:38 c_schmitz Status new => assigned
2011-09-11 10:11 c_schmitz Assigned To magiclko => c_schmitz
2011-10-18 17:33 c_schmitz Project Bug reports => Development
2013-03-06 09:09 c_schmitz Note Added: 24562
2013-03-06 09:10 c_schmitz Note Edited: 24562 View Revisions
2013-03-18 00:05 c_schmitz Assigned To c_schmitz =>
2013-03-18 00:05 c_schmitz Status assigned => acknowledged
2013-03-18 09:10 mdekker Note Added: 24749
2013-03-26 10:08 sammousa Note Added: 24867
2019-09-23 12:20 c_schmitz Status acknowledged => confirmed