View Issue Details

This bug affects 1 person(s).
IDProjectCategoryView StatusLast Update
03741Bug reportsSurvey takingpublic2009-12-11 12:16
Reporteruser659Assigned Toc_schmitz  
Status closedResolutionfixed 
Product Version1.86 
Fixed in Version1.87RC5 
Summary03741: Survey active but admin icon has start date

Some bugs with the start date seem to have been dealt with recently (03352, 03580) but the admin interface's icon for an active survey hasn't caught up: I set today as the start date. The icon shows that "this survey is active but has a start date" as if it is not accessible yet. According to the documentation ( it would be waiting for midnight of today, which would be horribly counter-intuitive. Actually, however, the survey is active AND accessible today already, the way it makes sense.

It seems that just the admin icon is still adhering to the counter-intuitive documented rule, but the actual activation is taking place ?just after midnight? so that today's start date means that one can complete the survey today.

TagsNo tags attached.
Bug heat8
Complete LimeSurvey version number (& build)7697
I will donate to the project if issue is resolved
Database type & version4.1.12
Server OS (if known)Win2k3
Webserver software & version (if known)IIS 6
PHP Version5.2.6

Users monitoring this issue

There are no users monitoring this issue.



2009-10-07 23:15


I couldn't reproduce the issue on the v1.87 dev branch.
@ ITEd: can you have a look at this branch too and tell us, if you can reproduce the issue?


2009-10-08 11:48


@ ElMatador69: It'll be a while before I can try 1.87, I'm afraid - maybe late next week.

FWIW, the problem seems to have come and gone a couple of times. Using the sample survey, it is
there in Version 1.85+ (7593),
gone in Version 1.85+ (7670),
back in Version 1.86 (7697).

I'll let you know about 1.87 as soon as I can.


2009-10-27 22:37


@ ITEd: did you find time to test the latest version from SVN?


2009-10-29 14:42


I tested with build 7789 (db v 140), downloaded today with Tortoise: The icon with today set as start date shows 'active but with start date' as before. BUT, now the survey also cannot be accessed yet: "This survey is not yet started." So it's consistent now, but a day late.

(BTW, the version showing in the admin footer is 186RC.)

Sorry it took so long.


2009-10-30 08:06


If you did a check out of the correct branch the version in the footer is at the moment: Version 1.87beta

Correct branch/directory (=latest development version) for checkout at the moment:

AND NOT (this branch is inactive at the moment):


2009-10-30 08:39


Sorry, I checked out the wrong branch then; thanks for the correction. I'll test is ASAP.


2009-10-30 09:36


Tested with 187beta build 7790: Start date set to today. Icon shows 'active but with start date' as before; the survey cannot be accessed yet: "This survey is not yet started." In other words, the survey will become active the day AFTER the specified date.


2009-11-09 21:40


@ ITEd:
1) is the date of your server the same as on your local machine?
2) did you set the parameter "$timeadjust" ==>


2009-11-11 13:23


Last edited: 2009-11-11 13:24

  1. Yes, date, timezone, and time are identical on server and client PC (except for some seconds, maybe).
  2. no, $timeadjust is untouched at '0' in config-default.php.

Can it not be reproduced? Am I doing something daft or odd?


2009-11-18 00:23


I still CAN'T reproduce the issue - tested now with v1.87RC2 and a MySQL-DB.

@ Lemeur: do you have an idea?



2009-11-22 09:53

developer   ~10188

I can't reproduce this either.

Carsten is our specialist on this.



2009-11-22 23:12

administrator   ~10211

I can't reproduce either. ITEd, can you give it another try on the 1.87RC2 version?


2009-11-24 15:28


I'll check - probably before end of week.


2009-11-30 18:17


Ok, tested and sort-of solved with limesurvey187rc3-build8004-20091130 (which, incidentally, displays RC4! in the admin footer):
Database.surveys.startdate was type=datetime & size = 19
and Database.surveys.expires was type=date & size = 10 (although the size wasn't creating any discernible problem).

I changed the startdate type manually to "date" as per create-mysql.sql (without any size specified), and now the conditions evaluate correctly.

I think the problem arises from an omission in the database updates. I've been using & upgrading this test installation since just before version 171+ build 5147.

upgrade-mysql.php has "ADD startdate DATETIME" in two places, ± line 220 & 353, but I cannot find any place where it updates the type to date only. The 'expires' field is modified to allow null on ± line 310, but I don't see anywhere where the historical size = 10 is reset either. Therefore I expect that all installations which have been updated since a particular point will have this bug.

(I see I forgot to mention that I use MySQL when I reported the bug. Apologies.)

I hope that helps.


2009-11-30 18:17


PS: Sorry to take so long. Busy busy busy!



2009-12-01 00:32

administrator   ~10385

Thank you for the thorough analysis. I will have a look at this and hopefully solve this for good.



2009-12-08 02:12

administrator   ~10512

I solved this for good by adding time options to the start and expiry date.

Issue History

Date Modified Username Field Change
2009-10-06 12:20 user659 New Issue
2009-10-06 12:20 user659 Status new => assigned
2009-10-06 12:20 user659 Assigned To => user372
2009-10-06 12:20 user659 LimeSurvey build number => 7697
2009-10-06 12:20 user659 Browser => any
2009-10-06 12:20 user659 Database & DB-Version => 4.1.12
2009-10-06 12:20 user659 Operating System (Server) => Win2k3
2009-10-06 12:20 user659 Webserver => IIS 6
2009-10-06 12:20 user659 PHP Version => 5.2.6
2009-10-07 23:15 user372 Note Added: 09737
2009-10-07 23:15 user372 Status assigned => feedback
2009-10-08 11:48 user659 Note Added: 09754
2009-10-27 22:37 user372 Note Added: 09880
2009-10-29 14:42 user659 Note Added: 09914
2009-10-30 08:06 user372 Note Added: 09920
2009-10-30 08:39 user659 Note Added: 09921
2009-10-30 09:36 user659 Note Added: 09922
2009-10-31 00:21 Mazi Status feedback => assigned
2009-11-09 21:40 user372 Note Added: 10037
2009-11-09 21:45 user372 Status assigned => feedback
2009-11-11 13:23 user659 Note Added: 10062
2009-11-11 13:24 user659 Note Edited: 10062
2009-11-18 00:23 user372 Note Added: 10131
2009-11-18 00:23 user372 Status feedback => assigned
2009-11-18 00:23 user372 Assigned To user372 => lemeur
2009-11-22 09:53 lemeur Note Added: 10188
2009-11-22 09:53 lemeur Assigned To lemeur => user372
2009-11-22 10:46 user372 Assigned To user372 => c_schmitz
2009-11-22 23:12 c_schmitz Note Added: 10211
2009-11-24 15:28 user659 Note Added: 10236
2009-11-30 01:25 c_schmitz Status assigned => feedback
2009-11-30 18:17 user659 Note Added: 10375
2009-11-30 18:17 user659 Note Added: 10376
2009-12-01 00:32 c_schmitz Note Added: 10385
2009-12-01 00:32 c_schmitz Status feedback => assigned
2009-12-08 02:12 c_schmitz Note Added: 10512
2009-12-08 02:12 c_schmitz Status assigned => resolved
2009-12-08 02:12 c_schmitz Fixed in Version => 1.87RC5
2009-12-08 02:12 c_schmitz Resolution open => fixed
2009-12-11 12:16 c_schmitz Status resolved => closed
2010-10-25 00:18 c_schmitz Category Survey at Runtime => Survey taking