This page contains information for developers. The documentation for common Limesurvey users can be found at Central participants database.
The first table is the actual central table where all the participants’ entries are stored. The table is as follows
|en||1||2007-11-04 01:00:01||2007-11-04 01:00:01||0|
|en||2||2007-11-04 01:00:01||2007-11-04 01:00:01||2|
|en||1||2007-11-04 01:00:01||2007-11-04 01:00:01||1|
The fields in the table are explained below:
The combination of email and owner_uid will be the composite key for this table.
In the lock feature there is one tables,lime_survey_info.The lime_participant_info table will contain the information regarding to which survey the participant is added.
The schema of the table is
This table will be used for two purposes as far as I can see for now,
1) It will give the clear cut info as to which survey a particular participant is added to.
2) When a user will try to share a participant, but in the settings it is set that he can't be added to more than two surveys, then a SQL COUNT query will be run for that participant and if that number is equal to the max_locks field an error message will sprung up saying, these participants can't be added to the survey.
|0||2011-03-08 12:32||0||23.03.2011 00:00||26.03.2011 00:00||N||2|
Some minor changes have been done to this table to make it work with the other Central Database System.One of then is that the user information will not be stored in this table, but in the Central Table and will be linked using the participant_id.Also, a blacklisted field is also added that will contain the survey and participant specific blacklist settings.
The Fields in table are explained below:
This feature will be using three tables namely :
1) lime_participant_attributes - Store the actual attribute information
2) lime_participant_attribute_info - Store the UI information related to the attribute
3) lime_participant_attribute_values - Store the possible values of the attribute
This is the table that will hold the actual values
The fields of the table are explained below
This is the table that will hold the UI related information for attribute control
This is the table that will hold all the possible values for the particular attribute. The scehma of this table is
The above example will make it more clear, but keep in mind that in case of a text box and date-picker, this field will be empty because any value can be entered in the system. For multi-line text input we will use a different value_id for each text box, for example address.
The relationship between the tables explained above is shown below.
In the user interface aspect, the entire participant control that we used to have` in the token menu will now be available globally, but the token will be generated in the survey specific table only. The link for adding participants to the limesurvey installation will be on the front screen.
When clicked on the Add Participants the following screen will come up
Explanation of the above screenshot is given below:
The CSV file upload feature is similar to what we used to do under tokens, however with some differences, the differences are mentioned below:
Again this screen is only for editing/deleting the participant entries. It is global, and hence nothing survey specific will be found here. If the user clicks on the edit button, then the screen similar to add participant screen will show up, showing the details of the participant, which can be edited there.
All the settings under this page will be stored under the settings_global table. Each of setting is
This is the user control, by user I mean the administrator. The three options under this field will be stored in the global table. The options are explained below.
This is a new feature I am planning to implement, in this feature I will be allowing the administrator to add a new attribute with a proper UI, rather than just a textbox. The value related to this feature will be stored in attribute_info_table. These are the UI components that I am planning to add for additional attribute
In case of Drop Down,Check Box, Radio the "Add More" will allow the administrator to add more possible values. More advanced UI's can be added once the basic feature is ready.
The UI is explained below:
This feature will allow the participant to just go on to the home screen, and sign him up. He will be verified against his e-mail. On the front screen there will be a sign up button, that when clicked will open a pop-up asking for the e-mail id. When entered an invitation mail will be sent to him asking for the rest of details. This way we will be sure that we have a valid participant. Once those details are entered, automatically a token will be generated for that user, and he will be redirected to the survey. Alternatively, if the administrator wants, he/she can disable this feature completey, or allow the participating to only participate only when he/she sends the invitation.
The mock - up of the sign up control is as shown :
This feature again will have a survey specific settings, which will be stored in the survey's table. The local settings if set ,will override the global settings.
Since we are porting LimeSurvey to codeIgniter and any new projects have to be developed according to the CodeIgniter framework. I will try and give the basic outline of the approach I will be following.
I as of now, will be adding a single controller for the whole project, and it will be named 'centralDB'. The functions under this controller will be of the form
All the controller's listed above will be used for only showing of the view, retrieving previous settings and storing new settings, and for import and displayparticipant functions, it will have major functionality as display participant will also be used for adding the participants to the database, and import will also be providing functionality and not just storing data.
For Storing data we have functions such as
These methods will get the post variables from the view and storing it in the database using appropriate model. For displayParticipant and all, there will other functions such as addtosurvey.
For the models we have
I think it's best to compress the three attributes table to one model. Rest of the models are pretty much simple, get and store records.This is the basic structure, what we need to concentrate on is what to do when we are joining tables and getting data from multiple tables.
For the view, I have decided to use the following views. These are
The main purpose of making this proposal on the wiki page is to get the review of the community and suggest us some scenario's where you can see the system failing, so that we can make the changes before it's too late. If you see any shortcomings or any other feedback, please leave a comment and please try and answer these questions
1) What do you want to do?
2) Where will the system fail?
3) Feature Suggestion?
I received my date-sheet and I have exams from 24th of May to 11th of June, So I will be tweaking the action plan a bit in order to get things right :).
Plan for June
|Date||What to do ?|
|4-7th||Talk to Shubham and Diogo during this period, as I think by that time they will be officially clear as to how they will be doing the porting, also, I will decide as to how I should go about it.If everything goes as planned I should be able to complete the add participant UI and the addition of data to the central database(without any features) along with the required validations.|
|12-15th||Will add the user_id info(based on the logged in user), along with the datestamp in the central database. Also will be creating the owner control as mentioned in the original proposal along with the required functionality with it. Like automatically adding participants to the token table or not, or editable owner's field or not .|
|16-22th June||Addition and attribute control|
|23-28th June||CSV and LDAP upload with attribute support|
|29-10th July||Add to token table and vice versa with editing logic and max surveys feature|
|11-15th July||Sending email with blacklist control and the required logic|
|(12 July - 16 July)||(Midterm Break)|
|16-31th July||sign up addition for participants along with the multiligual attribute support for token system|
|1-15th August||features from if we have time list|
|16-22th August||cleaning up code, video tutorials, testing and bug fixing|
|23-31th August||worst case scenario or else party time ;)|
This is the action plan for the first milestone according to my original proposal, I will create the further action plan once I am done with this target. I will also be updating a weekly progress report here as well as a mail to the administration team of LimeSurvey, about the discussions we have during the week. The actual coding and progress report will start from 12th of June.
This will contain the logs of the weekly meetings we have:
12th May 2011 -> http://docs.limesurvey.org/CPDB+Meeting+Log+12-05-2011
Logs of meeting from the 19th of May will be available at the link below
Use the following section to describe (as succinctly and clearly as possible) various different scenarios in which the Central Participants Database may be used. These scenarios can assist in clarifying User Interface issues and in initial database design
Single Company Installation
In this scenario, LimeSurvey is installed by a single company for use by that company's staff. The right to view and access data relating to participants is shared by all staff and there is no need to fence data off between users.
Multi User Installation
LimeSurvey is installed at a University and different students or academics are using it to run surveys. Their ethics rules require that they keep their participant data to themselves, so other users cannot see it.
Pre-existing List, Add it to Participants Database
A user has a list of 500 people in their personal spreadsheet/database that they want to invite to participate in their survey. They create a survey, create a tokens table for it and then import the list (as per existing system). They want to make sure that their list is on the participants database for future use, and that they will be able to select these 500 people easily later on for future surveys.
Pre-existing List, Don't add it to the participants database
A user has a list of 300 people in their personal spreadsheet/database that they want to invite to participate in a survey. They create a survey, create a tokens table table for it and then import the list (as per exising system). They don't want their list to be added to the central participants database.
Generate attributes for the participants database from answers to a survey
A user has run a survey which asked whether participants live in a capitol city, a major regional centre or a minor regional centre. He wants to transfer the answers from that survey to the participants attributes in the central participants table. He also wants to transfer the annual income results from a question. He already has this information for some of the participants, but wants to update it with the information collected in this survey.
Generate tokens from participants list based on earlier survey
A user creates a new survey and wants to invite all the participants from an earlier survey to this new survey. He needs to be able to select all those who participated in the earlier survey, preferably just those who actually completed it. He might want to add those who didn't complete the earlier survey later on.
Generate tokens from participants list based on their survey history
A user creates a new survey and wants to invite only participants that have not taken part in a survey for the last 2 months. He might also want to exclude all that have participated in a survey with a similar topic in the last 6 months. User will need to view a search form where he can:
1) Select search criteria from values such as "survey name", "survey completed date"
2) Fill out matching values (ie: text string for survey name, dates for completion dates)
3) Make the system search through all participants for matches to the search criteria
4) See a list of all the matching participants (and the relevant information)
5) Be able to do something with the resulting list (most likely copy them to a token table)
Generate tokens from participants list based on other attribute
A user creates a new survey and wants to invite all the participants he owns who have an income greater than $50,000 per annum and live in a capital city. User will need to be able to fill out a search form where he is able to:
1) Select the attribute or attributes to use in his search
2) Enter a search value/criteria for the search
3) Make the system search through all the participants he has rights to view, for matches to his search criteria
4) See a list of all the matching participants (and probably the relevant attribute data)
5) Do stuff with the list (most likely, copy those participants to a token table for a survey)
Taking care of the panel health
The manager of the central participant list wants to check on the panel health. He wants to know if all participants have been invited to surveys in a certain period of time, how often they have been invited, the ration between invitation and participation, etc. Ideally there would be a system to attribute "points" to each survey and those points would be added to each participant (something like the total km count for a car). Ideally there would also be another field with points that can be reset (e.g. like the day km in a car). This would help to remunerate participants for their participations, without having to "pay" them for every single survey.
After running the survey for 5 days he realises he needs more, so he then wants to add people who live in major regional centres.