View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
11577 | Bug reports | Other | public | 2016-08-23 19:46 | 2016-09-21 15:15 |
Reporter | gkuchyt | Assigned To | c_schmitz | ||
Priority | none | Severity | minor | ||
Status | closed | Resolution | unable to reproduce | ||
Product Version | 2.50.x | ||||
Summary | 11577: $bCheckIntegrity logic in getSurveyList() - common_helper.php | ||||
Description | We have installed 2.50+ in our development environment and upon login to the admin index page we get a warning "One or more surveys seem to be broken - please use the data integrity check tool to fix this." which links to the check integrity tool. When we run the check integrity tool it reports that there are no consistency issues and that not action is required. Tracing this down to the code that generates the warning in application/helpers/common_helper.php I see that $bCheckIntegrity controls the display of this warning. It looks like $bCheckIntegrity is declared as false and then is never actually updated as a result of any action against the database. This ensures that it will evaluate to true in the elseif(!($bCheckIntegrity)) conditional that displays the warning message. Am I missing where $bCheckIntegrity is updated? I see the Survey model has a validate method, should that be used to validate the defined rules and the results used to update $bCheckIntegrity? | ||||
Tags | No tags attached. | ||||
Bug heat | 4 | ||||
Complete LimeSurvey version number (& build) | 2.50_plus_160817 | ||||
I will donate to the project if issue is resolved | No | ||||
Browser | |||||
Database type & version | MariaDB 5.6.30-76.3 | ||||
Server OS (if known) | RHEL 7 | ||||
Webserver software & version (if known) | Apacee httpd 2.4.6-40 | ||||
PHP Version | PHP 5.4.16 | ||||
This imho happens only if there is a survey that does not have language settings. |
|
It looks like we have 7 surveys with NULL language fields. Would you consider these to be integrity issues or is it an edge case that shouldn't really happen? The user experience is a perpetual warning message that links to a screen that says that everything is ok. I understand why, but it is confusing to a user that can't dig into the code and figure out why. If it's not really a case that should happen then it makes sense to not account for it, and we'll just fix our data. |
|
It is really strange why the integrity check does not fix it for. It does fix it here on just opening the integrity check page here. Would it be possible to create a copy of the database, remove all survey except for the faulty one and provide this database dump to us? |
|
I'm not sure if we can get a database export because some of our surveys have protected information in them. We'll have to review and get managerial approval to release them. That will take a little bit of time. An export may not be necessary though, I sat down and looked closer at the database after looking at the surveys with NULL language values. Those surveys have an entry in the lime_surveys table but don't have the corresponding limesurvey#### table. So something is clearly broken with our data. We're not really sure how this could have happened. Should the database integrity check be expanded to find survey entries that have no backing table or is this a state that shouldn't normally be able to happen? |
|
As said, here the integrity check fixes such entries so I am wondering why it doesn't do it for you. |
|
Closed due to missing feedback. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2016-08-23 19:46 | gkuchyt | New Issue | |
2016-08-24 10:03 | c_schmitz | Note Added: 40410 | |
2016-08-24 10:03 | c_schmitz | Assigned To | => c_schmitz |
2016-08-24 10:03 | c_schmitz | Status | new => feedback |
2016-08-24 14:40 | gkuchyt | Note Added: 40448 | |
2016-08-24 14:40 | gkuchyt | Status | feedback => assigned |
2016-08-24 14:44 | c_schmitz | Note Added: 40450 | |
2016-08-24 14:44 | c_schmitz | Status | assigned => feedback |
2016-08-24 16:50 | gkuchyt | Note Added: 40467 | |
2016-08-24 16:50 | gkuchyt | Status | feedback => assigned |
2016-08-25 09:19 | c_schmitz | Note Added: 40475 | |
2016-08-25 09:20 | c_schmitz | Status | assigned => feedback |
2016-09-21 15:15 | c_schmitz | Status | feedback => closed |
2016-09-21 15:15 | c_schmitz | Resolution | open => unable to reproduce |
2016-09-21 15:15 | c_schmitz | Note Added: 40888 |