LimeSurvey Manual - User contributions [en]

Project ideas for GSOC 2011

2011-03-01T21:26:16Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/en/forum forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at [http://www.limesurvey.org/en/support/live-chat #limesurvey on irc.freenode.net]. Then submit your proposal. Good Luck (:biggrin:)

----

=Project ideas=

==Central participants database (User panel)==

Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow
* adding/removing of users along with flexible data to store related information for users
* simple copying of user-information to individual survey token tables
* ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)
* ability for survey participants to register in the panel
* ability to update the flexible user data from collected results
* a 'do not email' blacklist to allow people to automatically unsubscribe
* data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants

'''Skills'''

Database and PHP coding

'''Difficulty'''

Moderate to high - the coding would be relatively simple, but will entail complex relationships

'''Probable mentors'''

Jason Cleeland

----

==Port the LimeSurvey front-end to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However proting the whole application is too much for one students. That is why we will split the task into smaller ones. This particular task deals with porting the front-end of LimeSurvey to CodeIgniter - this means all the parts that can be seen by the average survey participant:
*Survey taking
*Public statistics
*Central landing page

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and other students will port the back-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other students.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you fulfill the requirements above the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new fundaments while the fance walls can be built later. So we lay the fundament first and make it stable, then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmap]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Port the LimeSurvey back-end (administration) to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However porting the whole application is too much for one student. That is why we will split the task into smaller ones. This particular task deals with porting the backend of LimeSurvey to CodeIgniter - this means all the parts that can be seen by an administration user.

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and another student will port the front-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other student.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you are a very good PHP coder (and fit the demanded skills above) then the main difficulty in this task is the sheer size of it. The administration consists of a great number of different screens and functions which need to be ported. If you don't manage to port all of it then at least the unported parts still have to be working - still best would be if you manage to do the whole administration.

Also the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new foundation while the fancy walls can be built later. So we lay the foundation first and make it stable (your task in the administration), then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmap]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Implement a modular authentication framework==

The idea is to design and implement a modular authentication "framework" for LimeSurvey as well as some authentication modules. The Authentication framework will define the API each authentication plugin must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, how to display a form using the survey template). A plugin will be responsible to implement, for each particular authentication backend, specific methods (some mandatory, some optionnal) such as: user authentication, user provisionning, user rights, ...

Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or interaction-pages between the server and the end-user or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey // alternatively the general-purpose cross-survey participants-database as described in the above GSoC idea.

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

== Rewrite and extend the conditions in LimeSurvey==

[[File:addNewCondition1.png]]

Rewrite the conditions engine that will let survey administrators design, store and evaluate conditions. Conditions must be implemented in such a way that they can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* The evaluation of conditions for the question branching feature.

'''Skills'''

PHP, CodeIgniter, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

Carsten Schmitz

'''Want to know more'''

Discussion about the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine LS2 conditions engine] is an interresting start. Note however that the task will be easier this year because of the existing conditions engine and the stable database layout of LS1.

----

==Idea template==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

----

=More information=

==Getting started==

[[GSoC getting started|Check out our 'Get started' page]] for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==

Check out [[GSoC FAQ|our GSoC FAQ page.]]

Project ideas for GSOC 2011

2011-03-01T21:13:41Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/en/forum forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at [http://www.limesurvey.org/en/support/live-chat #limesurvey on irc.freenode.net]. Then submit your proposal. Good Luck (:biggrin:)

----

=Project ideas=

==Central participants database (User panel)==

Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow
* adding/removing of users along with flexible data to store related information for users
* simple copying of user-information to individual survey token tables
* ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)
* ability for survey participants to register in the panel
* ability to update the flexible user data from collected results
* a 'do not email' blacklist to allow people to automatically unsubscribe
* data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants

'''Skills'''

Database and PHP coding

'''Difficulty'''

Moderate to high - the coding would be relatively simple, but will entail complex relationships

'''Probable mentors'''

Jason Cleeland

----

==Port the LimeSurvey front-end to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However proting the whole application is too much for one students. That is why we will split the task into smaller ones. This particular task deals with porting the front-end of LimeSurvey to CodeIgniter - this means all the parts that can be seen by the average survey participant:
*Survey taking
*Public statistics
*Central landing page

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and other students will port the back-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other students.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you fulfill the requirements above the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new fundaments while the fance walls can be built later. So we lay the fundament first and make it stable, then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmap]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Port the LimeSurvey back-end (administration) to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However porting the whole application is too much for one student. That is why we will split the task into smaller ones. This particular task deals with porting the backend of LimeSurvey to CodeIgniter - this means all the parts that can be seen by an administration user.

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and another student will port the front-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other student.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you are a very good PHP coder (and fit the demanded skills above) then the main difficulty in this task is the sheer size of it. The administration consists of a great number of different screens and functions which need to be ported. If you don't manage to port all of it then at least the unported parts still have to be working - still best would be if you manage to do the whole administration.

Also the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new foundation while the fancy walls can be built later. So we lay the foundation first and make it stable (your task in the administration), then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmap]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Implement a modular authentication framework==

The idea is to design and implement a modular authentication "framework" for LimeSurvey as well as some authentication modules. The Authentication framework will define the API each authentication plugin must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, how to display a form using the survey template). A plugin will be responsible to implement, for each particular authentication backend, specific methods (some mandatory, some optionnal) such as: user authentication, user provisionning, user rights, ...

Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or interaction-pages between the server and the end-user or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey // alternatively the general-purpose cross-survey participants-database as described in the above GSoC idea.

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

== Rewrite and extend the conditions in LimeSurvey==

[[File:addNewCondition1.png]]

Rewrite the conditions engine that will let survey administrators design, store and evaluate conditions. Conditions must be implemented in such a way that they can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* The evaluation of conditions for the question branching feature.

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

Carsten Schmitz

'''Want to know more'''

Discussion about [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine LS2 FAQ on the conditions engine]

[http://docs.limesurvey.org/tiki-index.php?page=Conditions+Engine The conditions Engine revisited]

----

==Idea template==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

----

=More information=

==Getting started==

[[GSoC getting started|Check out our 'Get started' page]] for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==

Check out [[GSoC FAQ|our GSoC FAQ page.]]

Project ideas for GSOC 2011

2011-03-01T21:06:05Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/en/forum forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at [http://www.limesurvey.org/en/support/live-chat #limesurvey on irc.freenode.net]. Then submit your proposal. Good Luck (:biggrin:)

----

=Project ideas=

==Central participants database (User panel)==

Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow
* adding/removing of users along with flexible data to store related information for users
* simple copying of user-information to individual survey token tables
* ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)
* ability for survey participants to register in the panel
* ability to update the flexible user data from collected results
* a 'do not email' blacklist to allow people to automatically unsubscribe
* data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants

'''Skills'''

Database and PHP coding

'''Difficulty'''

Moderate to high - the coding would be relatively simple, but will entail complex relationships

'''Probable mentors'''

Jason Cleeland

----

==Port the LimeSurvey front-end to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However proting the whole application is too much for one students. That is why we will split the task into smaller ones. This particular task deals with porting the front-end of LimeSurvey to CodeIgniter - this means all the parts that can be seen by the average survey participant:
*Survey taking
*Public statistics
*Central landing page

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and other students will port the back-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other students.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you fulfill the requirements above the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new fundaments while the fance walls can be built later. So we lay the fundament first and make it stable, then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmp]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Port the LimeSurvey back-end (administration) to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However porting the whole application is too much for one student. That is why we will split the task into smaller ones. This particular task deals with porting the backend of LimeSurvey to CodeIgniter - this means all the parts that can be seen by an administration user.

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and another student will port the front-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other student.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you are a very good PHP coder (and fit the demanded skills above) then the main difficulty in this task is the sheer size of it. The administration consists of a great number of different screens and functions which need to be ported. If you don't manage to port all of it then at least the unported parts still have to be working - still best would be if you manage to do the whole administration.

Also the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new foundation while the fancy walls can be built later. So we lay the foundation first and make it stable (your task in the administration), then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmp]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Implement a modular authentication framework==

The idea is to design and implement a modular authentication "framework" for LimeSurvey as well as some authentication modules. The Authentication framework will define the API each authentication plugin must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, how to display a form using the survey template). A plugin will be responsible to implement, for each particular authentication backend, specific methods (some mandatory, some optionnal) such as: user authentication, user provisionning, user rights, ...

Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or interaction-pages between the server and the end-user or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey // alternatively the general-purpose cross-survey participants-database as described in the above GSoC idea.

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

== Rewrite and extend the conditions in LimeSurvey==

[[File:addNewCondition1.png]]

Rewrite the conditions engine that will let survey administrators design, store and evaluate conditions. Conditions must be implemented in such a way that they can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* The evaluation of conditions for the question branching feature.

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

Carsten Schmitz

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]

----

==Idea template==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

----

=More information=

==Getting started==

[[GSoC getting started|Check out our 'Get started' page]] for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==

Check out [[GSoC FAQ|our GSoC FAQ page.]]

Project ideas for GSOC 2011

2011-03-01T20:41:56Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/en/forum forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at [http://www.limesurvey.org/en/support/live-chat #limesurvey on irc.freenode.net]. Then submit your proposal. Good Luck (:biggrin:)

----

=Project ideas=

==Central participants database (User panel)==

Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow
* adding/removing of users along with flexible data to store related information for users
* simple copying of user-information to individual survey token tables
* ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)
* ability for survey participants to register in the panel
* ability to update the flexible user data from collected results
* a 'do not email' blacklist to allow people to automatically unsubscribe
* data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants

'''Skills'''

Database and PHP coding

'''Difficulty'''

Moderate to high - the coding would be relatively simple, but will entail complex relationships

'''Probable mentors'''

Jason Cleeland

----

==Port the LimeSurvey front-end to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However proting the whole application is too much for one students. That is why we will split the task into smaller ones. This particular task deals with porting the front-end of LimeSurvey to CodeIgniter - this means all the parts that can be seen by the average survey participant:
*Survey taking
*Public statistics
*Central landing page

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and other students will port the back-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other students.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you fulfill the requirements above the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new fundaments while the fance walls can be built later. So we lay the fundament first and make it stable, then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmp]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Port the LimeSurvey back-end (administration) to CodeIgniter==

LimeSurvey is still written using old procedural code. We want to take the next step into the future and use a MVC-framework name CodeIgniter and port the whole application to this new framework. However porting the whole application is too much for one student. That is why we will split the task into smaller ones. This particular task deals with porting the backend of LimeSurvey to CodeIgniter - this means all the parts that can be seen by an administration user.

During the rewrite you will be prompted also to encapsulate certain functions to objects where easily doable and it makes sense - we do not want you to rewrite everything. Since you are only working on a certain part of LimeSurvey and another student will port the front-end (=administration) of LimeSurvey you will be required to coordinate your coding with the other student.

'''Skills'''

OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter are definately a must. You should get busy with LimeSurvey as early as possible. Students can raise their chance to get accepted by showing off according knowledge about LimeSurvey inner workings.

'''Difficulty'''

If you are a very good PHP coder (and fit the demanded skills above) then the main difficulty in this task is the sheer size of it. The administration consists of a great number of different screens and functions which need to be ported. If you don't manage to port all of it then at least the unported parts still have to be working - still best would be if you manage to do the whole administration.

Also the difficulty in this task is to gradually modernize an application with a modern coding approach while resisting the natural urge to rewrite everything at once. Our mantra to modernizing the application is that the framework is just laying the new foundation while the fancy walls can be built later. So we lay the foundation first and make it stable (your task in the administration), then we build new walls (See also [[LimeSurvey roadmap|the LimeSurvey roadmp]] )

'''Probable mentors'''

Carsten Schmitz (c_schmitz)

Thibault le Meur (tlemeur)

----

==Implement a modular authentication framework==

The idea is to design and implement a modular authentication "framework" for LimeSurvey as well as some authentication modules. The Authentication framework will define the API each authentication plugin must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, how to display a form using the survey template). A plugin will be responsible to implement, for each particular authentication backend, specific methods (some mandatory, some optionnal) such as: user authentication, user provisionning, user rights, ...

Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or interaction-pages between the server and the end-user or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey // alternatively the general-purpose cross-survey participants-database as described in the above GSoC idea.

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

----

==Idea template==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

----

=More information=

==Getting started==

[[GSoC getting started|Check out our 'Get started' page]] for setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==

Check out [[GSoC FAQ|our GSoC FAQ page.]]

Statistics

2010-12-13T12:56:21Z

Lemeur:

__TOC__

 The statistics feature is available from the menu of the browse screen, which - of course - is only available once a survey has been activated.

This is a short [http://www.screencast.com/users/healthinformatics/folders/Jing/media/0a3c9a66-fb41-4a84-b7dc-c8af363c391f video tutorial], showing how to get to the statistics screen.

=What is the statistics feature?=

Lets say you've got a survey running, or it is finished, and you want to start analyzing the results. LimeSurvey can dump all the results into an Excel spreadsheet (or CSV file, or Microsoft Word file). You can do whatever takes your fancy with the data then. Alternatively you can use the statistics feature to have a look at your data, and start getting some useful information from it.

The statistics feature allows you to 'filter' your data and retrieve numbers, and summaries of different fields from it. The statistics script doesn't attempt to do highly complex filtering - but you'd be surprised at the sort of information that can be easily obtained.

=Viewing Results and Field Summaries=

When you click the "Get statistics" button you will be presented with a list of all available questions. For each question there is a checkbox that can be selected in order to show a summary of this table, and an icon that when clicked (or if the mouse hovers over it) will give you the full text of the question. To view the results for a question or questions, check the checkbox(es) at the top of the question(s) and then click "View stats". Alternatively to view the results for all available questions, check the "View summary of all available fields" box at the very top and then click "View stats".

You will then be given a "Results" table which will indicate the number of cases and a "Field Summary" table for each question selected which will summarize all possible answers in the question(s), their totals and their percentage.

=Filtering data=

As of 1.85+, data can be filtered in several ways:
#By survey completion - use the dropdown at the top to select Completed, Incomplete or All records. For a discussion on incomplete responses see [[Browsing survey results]].
#By ID - use the inputs to filter by ID number
#By response - click on one or more responses in the list under each question to filter the data by those responses (use CTRL/click to select multiple responses in the same question). Note that if you choose to view summary of all available fields (checkbox at top) you will need to select your response filters before checking that box.

Selecting "View stats" will then give you the "Results" table, indicating the number of responses matching your criteria, and a "Field Summary" table for each question selected which will summarize all possible answers in the question(s), their totals and their percentage. It is important to note that these results are a subset of your total responses. So, for example, if your criteria display 146 records out of a total 180, the summary will show the breakdown of just those 146 records for that table.

The images below indicate that I have elected to view the stats for "Employment status" of '''''completed records/female/age 18-25'''''. This gives me the results for 6 out of 14 records.

[[File:stats_1_823x525.gif]]

[[File:stats_2_823x504.gif]]

Things to be cautious of
*If you set criteria on the same question that you ask for a summary, then that question will only present answers matching your criteria. So it is good practice not to set any criteria on the same question you are getting a summary of.
*To select multiple entries for a question hold down the CTRL button when clicking. To 'unselect' the last criteria (if you want to clear all criteria from a question) click on the last highlighted answer with the CTRL button.

=Browsing / Exporting filtered results=

If you want to export the responses that match your criteria, click on the "export" button at the bottom of the 'Results' table. This will bring up the usual export screen, however when you export the results you will only receive the responses that match your criteria. Similarly, click on browse to view the matching responses in the browse screen.

=Graphs=

For charting the library pChart is used which is completely included and usually doesn't have to be configured.

However for some languages (like Chinese) the usual font used (Vera) does not cover the needed character set. In that case you can use the setting $chartfontfile to set a new TTF font file in config.php (Check out config-defaults.php for the right setting). For Chinese (Simplified and Traditional) we recommend to use the FireFlySung font which can be downloaded from [http://cle.linux.org.tw/fonts/FireFly/].

After the graphs have been generated you can export these graphs easily. Use a right-mouse-click over the image and choose "Save image as" and save the graph as a .png-file to your chosen location. Normally all results are displayed as pie charts - only for question type "Multiple Options" bar graphs are used.

<center>[[File:Kreisdiagramm.png]]</center>

<center>[[File:Balkendiagramm.png]]</center>

="incomplete responses", "no answers" and not "completed/not displayed" counts=

"'''incomplete responses'''" counts: when the participant wasn't able to go till the end of the survey and thus haven't clicked the "Submit" button.

Technically speaking, this is when there is no SubmitDate in the response table for this entry.

A question with "'''no answer'''" counts: when the question was displayed, but the participant hasn't given an answer.

Technically speaking, this is when the question is not mandatory, was displayed, received no answer and the user clicked Next or Submit: the consequence is that the database field for this answer is set to "" (empty string). This "no answer" status cannot be really computed for Date or pure Numerical questions where the database field cannot record a string.

A question with "'''not completed/not displayed'''" counts: when the page containing the question was not displayed. This can be because of conditions, or just because the participant left the survey before this page was displayed (or just while this page is displayed, but without clicking the Next button).

Technically speaking, the database field for this question is filled with a NULL value.

=Public Statistics=

The new feature to show statistics to the user at the end of a survey was introduced in version 1.80RC3. Using this feature the user is presented a link at the end of the survey which takes him to the public statistics.

There are '''two important settings'''. At first you have to [http://docs.limesurvey.org/tiki-index.php?page=Creating+a+new+survey#Presentation_amp_Navigation enable public statistics for your current survey] at survey settings -> presentation & navigation -> Public statistics.

Because often you only want to show statistics for certain questions there is an [http://docs.limesurvey.org/tiki-index.php?page=Question+attributes#public_statistics additional question attribute "public_statistics"]. This question attribute has to be applied to all questions which should be shown to the user. Note that the use of this question attribute is limited to [http://docs.limesurvey.org/tiki-index.php?page=Question+attributes#public_statistics certain question types].

GSOC 2010 Authentication framework

2010-04-07T15:51:06Z

Lemeur:

This page is dedicated to the "Authentication framework" project for GSOC2010

=FAQ=
* What is the difficult part of the project ?

The difficult part will not be to implement openId or CAS or any

authentication scheme as we usually are able to find opensource

libraries to connect to these authentication backends. I think the most

difficult part will be to design an interface in LS1 that will make it

possible to implement _any_kind_ of authentication backends.
* Is there a list of authentication protocol you want to support ?

There is no such list because we want a framework that can be extended even with user-specific authentication systems.

For instance, you can consider the following different cases:

1- Case study 1:

LS1 authentication is based on a simple User/Password form, and the

password (or password hash) is read from the internal (usual) DB or on

another Database (such as LDAP when using Ldap as a database and not

using ldap-bind).

2- Case study 2:

LS1 authentication is based on a simple User/Password form, but the

authentication is delegated to a server able to check the password

validity: for instance LDAP (when using Ldap-bind authentication), or

Radius.

3- Case study 3:

LS1 is integrated into another web application which does implement

authentication.

LS1 authentication is then done simply by checking a value in a given

SESSION parameter, or in a GET parameter.

4- Case study 4:

LS1 uses the web server Authentication (equivalent of current Web

Server Authentication Delegation mode)

5-Case study 5:

LS1 authentication uses an external authentication protocol which

requires several messages to be exchanged between the authentication

server and the client (maybe several forms to be filled). For instance:

first screen asks for username, the server replies with a challenge,

then the second form ask for the passwords corresponding to the proposed

challenge.

6-Case study 6:

Authentication is done on a remote web service which generates a

service-token for LS1. The user is then redirected to LS1 and provides

(either in a cookie or in a GET or POST parameter) the token. LS1 has to

check that the token is valid and then grants access to the user.

Example of such authentication protocoles are CAS and openId.
* Do I have to implemenet a framework for each of the above test case ?

Of course not.

Let's say that the Generic Authentication Framework is implemented as a PHP Class, then it will define an API made up of his public methods. Then each True authentication module will inherit from this Class.

For instance, the Generic framework may define:

- An API that will return the capability of the module (is it able to do authentication, user-provisionning, ...)

- A set of methods to handle authentication, user provisionning (maybe noop if not implemented), ...

- A set of facility methods used by modules in order to display messages, errors, login forms, setup-forms

- A set of methods to record/read/modify the module parameters in DB

Then in LS1 core code, an instance of an Auth module is instanciated (depending on the setup parameters), and only the methods defined in the Generic Authentication Framework are used (never specific methods form the Authentication module). This makes it easy to implement a new Autnentication module without having to modify LS1 core code.
* Is this project just about authentication ?

No it isn't restricted to authentication but extends as well to user-provisionning (which I sometimes call authorization).

Indeed, authentication only checks that the user is

really who he pretends to be, but it doesn't cope with the user rights

issue. So once authentication is performed, LS1 needs to know the user

rights for this user: the global rights, as well as specific rights on

each survey. The current approach when delegating authentication to the

Web server, is to let the authentication module create the new user if

it is not already in the LS1 database. it is event possible to assign

him user-specific global rights by a "hook" function. The Authentication

interface will have to specify this aspect as well so that any

authentication module will be able to populate the LS1 permissions system.
* What other sources of information should I read/use, ... ?

I really encourage you to carefully read and understand the following page:

http://docs.limesurvey.org/tiki-index.php?page=Optional+settings&structure;=English+Instructions+for+LimeSurvey#Authentication

Morover a look at the following file in LS1 will help you:

usercontrol.php

This project could bebefit from ideas developped for the Horde project, especially the [http://git.horde.org/framework/Auth/lib/Horde/?onb=master Auth] class and library

Some user-proposed patches:

http://bugs.limesurvey.org/view.php?id=4035

http://bugs.limesurvey.org/view.php?id=3020

GSOC 2010 Condition engine

2010-03-30T21:01:29Z

Lemeur:

This page is dedicated to the GSOC2010 Condition Engine Project

=FAQ=
* Will I have to implement an RPN parser?

In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details (or check [[Expression engine for conditions]] to see how it works

Anyway here is an interresting link with algorithms for Infix to Postfix conversions and Postfix to infix conversions.

http://scriptasylum.com/tutorials/infix_postfix/infix_postfix.html

Also note that we'll not only need a way to do Infox to Postfix conversion (RPN) while defining a condition, but also Postfix to infox conversion in order to display a previously recorded condition and to build the PHP and/or Javascript evaluation code.
* Why is this a difficult project ?

We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...). This also means we need to define a specific "grammar" to describe conditions operands.

We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.

Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.
* What is this "grammar" you're talking about to describe operands ?

Since we have several operands types and since we want to record conditions as a simple RPN string, we need a grammar (a syntax) to "type" the different kinds of operands:
* a constant
* an answer from a previous question
* a value from the participant's profile (equivalent from the token attribute in LS1)
* another context specific variable (such as an assessment variable, or the result of a predefined function such as the sum of previous numerical answers).

This is not a proposal for a syntax, but just a stupid example of a condition in RPN using a syntax to type operands:

{ANSWER: Q0001} {ANSWER: Q0002} >= {ANSWER: Q1234} {CONST: Yes} = AND
* Do I have to understand how LS1 implements conditions ?

Understanding LS1 conditions is important because it will show you what is currently possible to do.

However you don't have to understand how everything is implemented.

Please carefully read [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey The conditions documentation for LS1]

I would highly recommend setting several surveys with conditions and see how it works:

- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side

- also try several kind of conditions:

- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),

- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)

- think about a strategy for LS2 to better handle the "Chained conditions" issue and other [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey#Things_to_watch_out_for gotchas from LS1 conditions]
* How does the condition engine relates to other parts of the LS2 core ?

Conditions will be used in a variety of ways: question branching, assessments, ...

What this means is that a condition will be mapped to an action.

For instance:

- in a question branching context: map the conditions to the "Display question XXX" action

- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."

For the question branching action, the condition engine, must:

- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)

- understand how to access participant's specific data

- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden

- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).

- understand how to mark a question as "Not displayed"
* I want to jump into LS2 code, what should I check ?

The following is a first answer I (lemeur) gave to the #limesurvey channel

<lemeur> First you must be aware of the fact that I implemented part of LS1 conditions and am a LS1 core developper so I'm very familiar with LS1.

However I'm not very familiar with the LS2 codebase yet

So I have several questions regarding LS2 for you, my future GSOC participant, regarding how questions are implemented in LS2.

- are "mandatory" questions implemented and how

==> mandatory questions: questions that you can't skip (you can't proceed untill you've answered)

==> This is important to understand this, because when a mandatory question is hidden by conditions, you have to alter the mandatory property

- Is there a "No answer was given" code recorded to DB

==> I mean, is there a way to know if teh question was displayed but no answer given

==> this must be different from "no answer recorded because the question was not displayed"

[22:31] <lemeur> this is the kind of questions I'm longing to know about LS2 because it will have so much implications for the Conditions engine project

[22:32] <lemeur> Another question regarding participants

<lemeur> Now regarding participants, in LS2 they are managed in a complete different way than what was done for LS1

and since conditions can be based on information from the participant's profile, we need to understand how to reach participant's data from within the conditions engine we also need to understand if accessing the participants data is possible for all kind of surveys.

- For instance is it possible for Anonymous surveys ? (should not)

<lemeur> You may now understand why I think the conditions engine has so much implications and dependances on the rest of the LS2 core

GSOC 2010 Condition engine

2010-03-30T13:36:29Z

Lemeur:

GSOC 2010 Condition engine

2010-03-30T11:51:06Z

Lemeur:

GSOC 2010 Condition engine

2010-03-30T09:13:46Z

Lemeur:

This page is dedicated to the GSOC2010 Condition Engine Project

=FAQ=
* Will I have to implement an RPN parser?

In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details.

Anyway here is an interresting link with algorithms for Infix to Postfix conversions and Postfix to infix conversions.

http://scriptasylum.com/tutorials/infix_postfix/infix_postfix.html
* Why is this a difficult project ?

We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...).

We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.

Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.
* Do I have to understand how LS1 implements conditions ?

Understanding LS1 conditions is important because it will show you what is currently possible to do.

However you don't have to understand how everything is implemented.

Please carefully read [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey The conditions documentation for LS1]

I would highly recommend setting several surveys with conditions and see how it works:

- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side

- also try several kind of conditions:

- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),

- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)

- think about a strategy for LS2 to better handle the "Chained conditions" issue and other [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey#Things_to_watch_out_for gotchas from LS1 conditions]
* How does the condition engine relates to other parts of the LS2 core ?

Conditions will be used in a variety of ways: question branching, assessments, ...

What this means is that a condition will be mapped to an action.

For instance:

- in a question branching context: map the conditions to the "Display question XXX" action

- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."

For the question branching action, the condition engine, must:

- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)

- understand how to access participant's specific data

- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden

- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).

- understand how to mark a question as "Not displayed"

GSOC 2010 Authentication framework

2010-03-29T14:50:51Z

Lemeur:

This page is dedicated to the "Authentication framework" project for GSOC2010

=FAQ=
* What is the difficult part of the project ?

The difficult part will not be to implement openId or CAS or any

authentication scheme as we usually are able to find opensource

libraries to connect to these authentication backends. I think the most

difficult part will be to design an interface in LS1 that will make it

possible to implement _any_kind_ of authentication backends.
* Is there a list of authentication protocol you want to support ?

There is no such list because we want a framework that can be extended even with user-specific authentication systems.

For instance, you can consider the following different cases:

1- Case study 1:

LS1 authentication is based on a simple User/Password form, and the

password (or password hash) is read from the internal (usual) DB or on

another Database (such as LDAP when using Ldap as a database and not

using ldap-bind).

2- Case study 2:

LS1 authentication is based on a simple User/Password form, but the

authentication is delegated to a server able to check the password

validity: for instance LDAP (when using Ldap-bind authentication), or

Radius.

3- Case study 3:

LS1 is integrated into another web application which does implement

authentication.

LS1 authentication is then done simply by checking a value in a given

SESSION parameter, or in a GET parameter.

4- Case study 4:

LS1 uses the web serveur Authentication (equivalent of current Web

Server Authentication Delegation mode)

5-Case study 5:

LS1 authentication uses an external authentication protocol which

requires several messages to be exchanged between the authentication

server and the client (maybe several forms to be filled). For instance:

first screen asks for username, the server replies with a challenge,

then the second form ask for the passwords corresponding to the proposed

challenge.

6-Case study 6:

Authentication is done on a remote web service which generates a

service-token for LS1. The user is then redirected to LS1 and provides

(either in a cookie or in a GET or POST parameter) the token. LS1 has to

check that the token is valid and then grants access to the user.

Example of such authentication protocoles are CAS and openId.
* Is this project just about authentication ?

No it isn't restricted to authentication but extends as well to user-provisionning (which I sometimes call authorization).

Indeed, authentication only checks that the user is

really who he pretends to be, but it doesn't cope with the user rights

issue. So once authentication is performed, LS1 needs to know the user

rights for this user: the global rights, as well as specific rights on

each surveys. The current approach when delegating authentication to the

Web server, is to let the authentication module create the new user if

it is not already in the LS1 database. it is event possible to assign

him user-specific global rights by a "hook" function. The Authentication

interface will have to specify this aspect as well so that any

authentication module will be able to populate the LS1 permissions system.
* What other sources of information should I read/use, ... ?

I really encourage you to carefully read and understand the following page:

http://docs.limesurvey.org/tiki-index.php?page=Optional+settings&structure;=English+Instructions+for+LimeSurvey#Authentication

Morover a look at the following file in LS1 will help you:

usercontrol.php

This project could bebefit from ideas developped for the Horde project, especially the [http://git.horde.org/framework/Auth/lib/Horde/?onb=master Auth] class and library

Some user-proposed patches:

http://bugs.limesurvey.org/view.php?id=4035

http://bugs.limesurvey.org/view.php?id=3020

GSOC 2010 Authentication framework

2010-03-29T14:50:07Z

Lemeur:

This page is dedicated to the "Authentication framework" poject for GSOC2010

=FAQ=
* What is the difficult part of the project ?

The difficult part will not be to implement openId or CAS or any

authentication scheme as we usually are able to find opensource

libraries to connect to these authentication backends. I think the most

difficult part will be to design an interface in LS1 that will make it

possible to implement _any_kind_ of authentication backends.
* Is there a list of authentication protocol you want to support ?

There is no such list because we want a framework that can be extended even with user-specific authentication systems.

For instance, you can consider the following different cases:

1- Case study 1:

LS1 authentication is based on a simple User/Password form, and the

password (or password hash) is read from the internal (usual) DB or on

another Database (such as LDAP when using Ldap as a database and not

using ldap-bind).

2- Case study 2:

LS1 authentication is based on a simple User/Password form, but the

authentication is delegated to a server able to check the password

validity: for instance LDAP (when using Ldap-bind authentication), or

Radius.

3- Case study 3:

LS1 is integrated into another web application which does implement

authentication.

LS1 authentication is then done simply by checking a value in a given

SESSION parameter, or in a GET parameter.

4- Case study 4:

LS1 uses the web serveur Authentication (equivalent of current Web

Server Authentication Delegation mode)

5-Case study 5:

LS1 authentication uses an external authentication protocol which

requires several messages to be exchanged between the authentication

server and the client (maybe several forms to be filled). For instance:

first screen asks for username, the server replies with a challenge,

then the second form ask for the passwords corresponding to the proposed

challenge.

6-Case study 6:

Authentication is done on a remote web service which generates a

service-token for LS1. The user is then redirected to LS1 and provides

(either in a cookie or in a GET or POST parameter) the token. LS1 has to

check that the token is valid and then grants access to the user.

Example of such authentication protocoles are CAS and openId.
* Is this project just about authentication ?

No it isn't restricted to authentication but extends as well to user-provisionning (which I sometimes call authorization).

Indeed, authentication only checks that the user is

really who he pretends to be, but it doesn't cope with the user rights

issue. So once authentication is performed, LS1 needs to know the user

rights for this user: the global rights, as well as specific rights on

each surveys. The current approach when delegating authentication to the

Web server, is to let the authentication module create the new user if

it is not already in the LS1 database. it is event possible to assign

him user-specific global rights by a "hook" function. The Authentication

interface will have to specify this aspect as well so that any

authentication module will be able to populate the LS1 permissions system.
* What other sources of information should I read/use, ... ?

I really encourage you to carefully read and understand the following page:

http://docs.limesurvey.org/tiki-index.php?page=Optional+settings&structure;=English+Instructions+for+LimeSurvey#Authentication

Morover a look at the following file in LS1 will help you:

usercontrol.php

This project could bebefit from ideas developped for the Horde project, especially the [http://git.horde.org/framework/Auth/lib/Horde/?onb=master Auth] class and library

Some user-proposed patches:

http://bugs.limesurvey.org/view.php?id=4035

http://bugs.limesurvey.org/view.php?id=3020

Project ideas for GSOC 2010

2010-03-29T14:46:57Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)

=Project ideas=

==Example Format...==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

==LimeSurvey 1: Email bounce tracking & handling of international email addresses==

Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:

- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.

- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)

Skills

PHP, knowledge of email handling and RFCs, some HTML & JS

Difficulty

Medium

Probable Mentors

Carsten Schmitz (c_schmitz)

Thibault LeMeur (lemeur)

==LimeSurvey 1: File Upload question type==

The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)
*Extensive configuration options for the question type like
**How many files are required, minimum and maxim number of files,
**maximum/minimum upload size,
**Allowed file types
*Safe!! storage in the file system, checks for file contents
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses
*Provide possible hooks for third party processing tools

'''Skills'''

PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage

'''Difficulty'''

Medium

'''Probable Mentors'''

c_schmitz (Carsten Schmitz)

==LimeSurvey 1: Authentication framework==

The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

==LimeSurvey 2: Db Storage Engine==

Develop an extensible plugin survey storage engine for LimeSurvey 2.

Description

Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.

For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.

Rationale

Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey’s functions we will the ease with which LimeSurvey can be developed in the long term.

Implementation

This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.

The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.

Requirements & Considerations

The DB Engine must be able to do the following
* ease development of additional '''question types, which will be developed as plugins'''
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.
* support survey resuming (where applicable)

 Use Cases 

Think of these when writing your proposal
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)

 Your proposal 

Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).

Field Naming and Database Extensibility Methodologies

An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to ‘freeze’ the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn’t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations – sometimes running up against database limitations regarding the number of fields per table.

An alternative is a ‘normalised’ database topology where a single table is created to store all survey responses – one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.

In a perfect world LimeSurvey would allow users to choose either methodology – either at an installation level or even on a per-survey level.

Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.

'''Skills'''

PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures

'''Difficulty'''

High

'''Probable Mentors'''

jasebo (Jason Cleeland)

macduy (Mac Duy Hai)

==LimeSurvey 2: Template Editor==

Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.

'''Skills'''

One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.

'''Difficulty'''

You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.

'''Probable Mentors'''

Mazi

==LimeSurvey 2: Mini-projects==

Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality
**'''Batch import:''' import users through CSV, XML, etc...
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once

'''Skills'''

PHP, CakePHP, JavaScript & jQuery

'''Difficulty'''

Moderate

'''Probable Mentors'''

Mac Duy Hai (macduy)

==LimeSurvey 2: Template/Theme Editor==

The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.

The overview of the modules can be seen here:

[[File:theme_roller.png]]

It’ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)

The following mock-up will give us a better view:

Moderate[[File:theme_editor_small.png]]

'''Skills'''

PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.

'''Difficulty'''

Moderate

==LimeSurvey 2: Lime Survey Social - Facebook Application==

The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.

The facebook has the following modules (we can add more. This is primary draft.)
*All Survey related core features. (Create, Edit, Delete, Administer etc)
*Gain reward points.
*Use reward points to create more surveys.
*Spread the surveys ...... and more

The idea can be extended to other social networks

[[File:fb_overview.png]]

The mock-ups :

[[File:facebook app.png]]

[[File:canvas.png]]

'''Skills'''

PHP, CakePHP, Facebook API.

'''Difficulty'''

Moderate

==LimeSurvey 2: Integration of Poll Questions==

Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.

The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback “about the survey” at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.

A simple mock-up for this:

[[File:chat.png]]
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.

We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.

'''Skills'''

PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.

'''Difficulty'''

Moderate

==LimeSurvey 2: Survey Community Project==

Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.

For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.

'''Skills'''

PHP, CakePHP, Web and User Interface Design Skills

'''Difficulty'''

Moderate

'''Probable Mentors'''

Jason Cleeland (jasebo)

==LimeSurvey 2: Condition Engine==

[[File:addNewCondition1.png]]

Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]

=We want your ideas!=

What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.

=More Information=

==LimeSurvey Google's Summer of Code 2010==
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]

An introduction to LimeSurvey and our application for this years Google Summer of Code

==Getting Started==
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

Project ideas for GSOC 2010

2010-03-29T14:46:36Z

Lemeur:

GSOC 2010 Authentication framework

2010-03-29T14:44:51Z

Lemeur:

GSOC 2010 Authentication framework

2010-03-29T14:44:20Z

Lemeur:

This page is dedicated to the "Authentication framework" poject for GSOC2010

=FAQ=
* What is the difficult part of the project ?

The difficult part will not be to implement openId or CAS or any

authentication scheme as we usually are able to find opensource

libraries to connect to these authentication backends. I think the most

difficult part will be to design an interface in LS1 that will make it

possible to implement _any_kind_ of authentication backends.
* Is there a list of authentication protocol you want to support ?

There is no such list because we want a framework that can be extended even with user-specific authentication systems.

For instance, you can consider the following different cases:

1- Case study 1:

LS1 authentication is based on a simple User/Password form, and the

password (or password hash) is read from the internal (usual) DB or on

another Database (such as LDAP when using Ldap as a database and not

using ldap-bind).

2- Case study 2:

LS1 authentication is based on a simple User/Password form, but the

authentication is delegated to a server able to check the password

validity: for instance LDAP (when using Ldap-bind authentication), or

Radius.

3- Case study 3:

LS1 is integrated into another web application which does implement

authentication.

LS1 authentication is then done simply by checking a value in a given

SESSION parameter, or in a GET parameter.

4- Case study 4:

LS1 uses the web serveur Authentication (equivalent of current Web

Server Authentication Delegation mode)

5-Case study 5:

LS1 authentication uses an external authentication protocol which

requires several messages to be exchanged between the authentication

server and the client (maybe several forms to be filled). For instance:

first screen asks for username, the server replies with a challenge,

then the second form ask for the passwords corresponding to the proposed

challenge.

6-Case study 6:

Authentication is done on a remote web service which generates a

service-token for LS1. The user is then redirected to LS1 and provides

(either in a cookie or in a GET or POST parameter) the token. LS1 has to

check that the token is valid and then grants access to the user.

Example of such authentication protocoles are CAS and openId.
* Is this project just about authentication ?

No it isn't restricted to authentication but extends as well to user-provisionning (which I sometimes call authorization).

Indeed, authentication only checks that the user is

really who he pretends to be, but it doesn't cope with the user rights

issue. So once authentication is performed, LS1 needs to know the user

rights for this user: the global rights, as well as specific rights on

each surveys. The current approach when delegating authentication to the

Web server, is to let the authentication module create the new user if

it is not already in the LS1 database. it is event possible to assign

him user-specific global rights by a "hook" function. The Authentication

interface will have to specify this aspect as well so that any

authentication module will be able to populate the LS1 permissions system.
* What other sources of information should I read/use, ... ?

I really encourage you to carefully read and understand the following page:

http://docs.limesurvey.org/tiki-index.php?page=Optional+settings&structure;=English+Instructions+for+LimeSurvey#Authentication

Morover a look at the following file in LS1 will help you:

usercontrol.php

This project could bebefit from ides developped for the Horde project, especially the [http://git.horde.org/framework/Auth/lib/Horde/?onb=master Auth] class and library

GSOC 2010 Condition engine

2010-03-29T10:40:02Z

Lemeur:

This page is dedicated to the GSOC2010 Condition Engine Project

=FAQ=
* Will I have to implement an RPN parser?

In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details.
* Why is this a difficult project ?

We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...).

We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.

Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.
* Do I have to understand how LS1 implements conditions ?

Understanding LS1 conditions is important because it will show you what is currently possible to do.

However you don't have to understand how everything is implemented.

Please carefully read [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey The conditions documentation for LS1]

I would highly recommend setting several surveys with conditions and see how it works:

- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side

- also try several kind of conditions:

- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),

- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)

- think about a strategy for LS2 to better handle the "Chained conditions" issue and other [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey#Things_to_watch_out_for gotchas from LS1 conditions]
* How does the condition engine relates to other parts of the LS2 core ?

Conditions will be used in a variety of ways: question branching, assessments, ...

What this means is that a condition will be mapped to an action.

For instance:

- in a question branching context: map the conditions to the "Display question XXX" action

- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."

For the question branching action, the condition engine, must:

- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)

- understand how to access participant's specific data

- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden

- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).

- understand how to mark a question as "Not displayed"

GSOC 2010 Condition engine

2010-03-29T10:38:20Z

Lemeur:

This page is dedicated to the GSOC2010 Condition Engine Project

=FAQ=
* Will I have to implement an RPN parser?

In fact a first version of an RPN parser has already been integrated to LS2, ask macduy for more details.
* Why is this a difficult project ?

We want a generic condition engine, able to support multiple kind of conditions. The conditions can be based on static values (predefined string or number) or variable values (context dependant values such as a previous answer, or a user-specific value, ...).

We also want to make the GUI as user friendly as possible so that even if we can design complex conditions, simple conditions design doesn't become a hassle.

Moreover, conditions may have several usage in LS2, not only helping design question branching but also helping design assessments and so on. This means that implementing conditions may require a lot of communication between the "condition engine" team and the other LS2 developpers.
* Do I have to understand how LS1 implements conditions ?

Understanding LS1 conditions is important because it will show you what is currently possible to do.

However you don't have to understand how everything is implemented.

Please carefully read [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey The conditions documentation for LS1]

I would highly recommend setting several surveys with conditions and see how it works:

- for question per page surveys, for group by group surveys, for all-in-one surveys: note how condition evaluation is either done on the server side, or on the client side

- also try several kind of conditions:

- conditions on previous answer compared to a static value or to another previous answer, conditions on token (user-dependant value),

- understand the difference between a condition using "not answer" and "not displayed" (the latest is not supported in LS1)

- think about a strategy for LS2 to better handle the "Chained conditions" issue and other [http://docs.limesurvey.org/tiki-index.php?page=Setting+conditions&structure;=English+Instructions+for+LimeSurvey#Things_to_watch_out_for gotchas from LS1 conditions]
* How does the condition engine relates to other parts of the LS2 core ?

Conditions will be used in a variety of ways: question branching, assessments, ...

What this means is that a condition will be mapped to an action.

For instance:

- in a question branching context: map the conditions to the "Display question XXX" action

- in an assessment context: map condition to the "update assessment score YYY by exectuing the following arithmetic operation ..."

For the question branching action, the condition engine, must:

- understand how answers are stored (either in SESSION, in DB or even in the HTML page if the evaluation is done by Javascript)

- understand how to access participant's specific data

- understand how LS2 handles mandatory questions and how to alter this behaviour if the question is hidden

- be able to reset an answer to "No answer" if a previously answered question becomes hidden because the participant changed his mind and modified a previous answer (see the deletenonvalue parameter).

Project ideas for GSOC 2010

2010-03-29T10:01:31Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#student_eligibility eligible candidate] for the GSoC program.

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)

=Project ideas=

==Example Format...==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

==LimeSurvey 1: Email bounce tracking & handling of international email addresses==

Currently there is no way to process email bounces of invitation or reminders in an automated way. If a bounce is received the administrator has to manually process every bounce - either by finding out a correct email address or removing the participant completely. Additionally it would be great if LimeSurvey could handle International email addressing - although the RFC for this kind of features are still experimental it would be great if we can be ahead of time. Primary goals of this task:

- Create a facility to handle email bounces using various methods. Easier to install methods which run without CRON jobs and with a single email account - more advanced and safer methods which require certain email server setups. Make it quick and easy to configure and handle. Create followup actions in case an email is bounced. Differentiate between bounces and other 'away-messages'.

- Extend the PHPmailer library and LimeSurvey so it can handle international email addressing (including configuration)

Skills

PHP, knowledge of email handling and RFCs, some HTML & JS

Difficulty

Medium

Probable Mentors

Carsten Schmitz (c_schmitz)

Thibault LeMeur (lemeur)

==LimeSurvey 1: File Upload question type==

The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)
*Extensive configuration options for the question type like
**How many files are required, minimum and maxim number of files,
**maximum/minimum upload size,
**Allowed file types
*Safe!! storage in the file system, checks for file contents
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses
*Provide possible hooks for third party processing tools

'''Skills'''

PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage

'''Difficulty'''

Medium

'''Probable Mentors'''

c_schmitz (Carsten Schmitz)

==LimeSurvey 1: Authentication framework==

The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

'''Want to know more'''

Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]

==LimeSurvey 2: Db Storage Engine==

Develop an extensible plugin survey storage engine for LimeSurvey 2.

Description

Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.

For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.

Rationale

Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey’s functions we will the ease with which LimeSurvey can be developed in the long term.

Implementation

This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.

The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.

Requirements & Considerations

The DB Engine must be able to do the following
* ease development of additional '''question types, which will be developed as plugins'''
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.
* support survey resuming (where applicable)

 Use Cases 

Think of these when writing your proposal
# Questionnaire which has a special section displayed only if a user answers a chosen question in a specific way (i.e. branching)
# Question on your favourite ice-cream, with an option "Other", upon which the user will be asked to enter his own choice (i.e. multi-datatype question types)
# Questionnaire, which asks how many children you have and then loops a set of predefined questions that many times. (i.e. looping)

 Your proposal 

Your proposal needs to be fairly detailed and must dig deep down to the implementation level, with good analysis of the performance. "Read the data from the user and store it in the database" is no good! How are you going to store it? What is the schema going to be? Does it satisfy the requirements, for branching, conditions, pluggable question types? Does it scale well? Is it efficient - what is the time complexity? Can I get summaries out of it in a reasonable time? All this needs to be addressed. Early submissions are accepted by both mentors and suggestions and comments will be given (:wink:).

Field Naming and Database Extensibility Methodologies

An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to ‘freeze’ the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn’t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations – sometimes running up against database limitations regarding the number of fields per table.

An alternative is a ‘normalised’ database topology where a single table is created to store all survey responses – one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.

In a perfect world LimeSurvey would allow users to choose either methodology – either at an installation level or even on a per-survey level.

Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.

'''Skills'''

PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures

'''Difficulty'''

High

'''Probable Mentors'''

jasebo (Jason Cleeland)

macduy (Mac Duy Hai)

==LimeSurvey 2: Template Editor==

Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.

'''Skills'''

One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.

'''Difficulty'''

You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.

'''Probable Mentors'''

Mazi

==LimeSurvey 2: Mini-projects==

Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality
**'''Batch import:''' import users through CSV, XML, etc...
**'''Batch processing:''' Add an interface to manipulate (add & modify) several users at once

'''Skills'''

PHP, CakePHP, JavaScript & jQuery

'''Difficulty'''

Moderate

'''Probable Mentors'''

Mac Duy Hai (macduy)

==LimeSurvey 2: Template/Theme Editor==

The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.

The overview of the modules can be seen here:

[[File:theme_roller.png]]

It’ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)

The following mock-up will give us a better view:

Moderate[[File:theme_editor_small.png]]

'''Skills'''

PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.

'''Difficulty'''

Moderate

==LimeSurvey 2: Lime Survey Social - Facebook Application==

The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.

The facebook has the following modules (we can add more. This is primary draft.)
*All Survey related core features. (Create, Edit, Delete, Administer etc)
*Gain reward points.
*Use reward points to create more surveys.
*Spread the surveys ...... and more

The idea can be extended to other social networks

[[File:fb_overview.png]]

The mock-ups :

[[File:facebook app.png]]

[[File:canvas.png]]

'''Skills'''

PHP, CakePHP, Facebook API.

'''Difficulty'''

Moderate

==LimeSurvey 2: Integration of Poll Questions==

Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.

The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback “about the survey” at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.

A simple mock-up for this:

[[File:chat.png]]
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.

We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.

'''Skills'''

PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.

'''Difficulty'''

Moderate

==LimeSurvey 2: Survey Community Project==

Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.

For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.

'''Skills'''

PHP, CakePHP, Web and User Interface Design Skills

'''Difficulty'''

Moderate

'''Probable Mentors'''

Jason Cleeland (jasebo)

==LimeSurvey 2: Condition Engine==

[[File:addNewCondition1.png]]

Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

=We want your ideas!=

What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.

=More Information=

==LimeSurvey Google's Summer of Code 2010==
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010 Limesurvey GSoC 2010]

An introduction to LimeSurvey and our application for this years Google Summer of Code

==Getting Started==
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

GSOC 2010 Authentication framework

2010-03-29T09:57:11Z

Lemeur:

GSOC 2010 Authentication framework

2010-03-29T09:56:54Z

Lemeur:

This page is dedicated to the "Authentication framework" poject for GSOC2010

=FAQ=
* What is the difficult part of the project

The difficult part will not be to implement openId or CAS or any

authentication scheme as we usually are able to find opensource

libraries to connect to these authentication backends. I think the most

difficult part will be to design an interface in LS1 that will make it

possible to implement _any_kind_ of authentication backends.
* Is there a list of authentication protocol you want to support ?

There is no such list because we want a framework that can be extended even with user-specific authentication systems.

For instance, you can consider the following different cases:

1- Case study 1:

LS1 authentication is based on a simple User/Password form, and the

password (or password hash) is read from the internal (usual) DB or on

another Database (such as LDAP when using Ldap as a database and not

using ldap-bind).

2- Case study 2:

LS1 authentication is based on a simple User/Password form, but the

authentication is delegated to a server able to check the password

validity: for instance LDAP (when using Ldap-bind authentication), or

Radius.

3- Case study 3:

LS1 is integrated into another web application which does implement

authentication.

LS1 authentication is then done simply by checking a value in a given

SESSION parameter, or in a GET parameter.

4- Case study 4:

LS1 uses the web serveur Authentication (equivalent of current Web

Server Authentication Delegation mode)

5-Case study 5:

LS1 authentication uses an external authentication protocol which

requires several messages to be exchanged between the authentication

server and the client (maybe several forms to be filled). For instance:

first screen asks for username, the server replies with a challenge,

then the second form ask for the passwords corresponding to the proposed

challenge.

6-Case study 6:

Authentication is done on a remote web service which generates a

service-token for LS1. The user is then redirected to LS1 and provides

(either in a cookie or in a GET or POST parameter) the token. LS1 has to

check that the token is valid and then grants access to the user.

Example of such authentication protocoles are CAS and openId.
* Is this project just about authentication ?

No it isn't restricted to authentication but extends as well to user-provisionning (which I sometimes call authorization).

Indeed, authentication only checks that the user is

really who he pretends to be, but it doesn't cope with the user rights

issue. So once authentication is performed, LS1 needs to know the user

rights for this user: the global rights, as well as specific rights on

each surveys. The current approach when delegating authentication to the

Web server, is to let the authentication module create the new user if

it is not already in the LS1 database. it is event possible to assign

him user-specific global rights by a "hook" function. The Authentication

interface will have to specify this aspect as well so that any

authentication module will be able to populate the LS1 permissions system.
* What other sources of information should I read/use, ... ?

I really encourage you to carefully read and understand the following page:

http://docs.limesurvey.org/tiki-index.php?page=Optional+settings&structure;=English+Instructions+for+LimeSurvey#Authentication

Morover a look at the following file in LS1 will help you:

usercontrol.php

Project ideas for GSOC 2010

2010-03-16T21:45:38Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#eligibility eligible candidate] for the GSoC program.

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)

=Project ideas=

==Example Format...==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

==LimeSurvey 1: File Upload question type==

The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)
*Extensive configuration options for the question type like
**How many files are required, minimum and maxim number of files,
**maximum/minimum upload size,
**Allowed file types
*Safe!! storage in the file system, checks for file contents
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses
*Provide possible hooks for third party processing tools

'''Skills'''

PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage

'''Difficulty'''

Medium

'''Probable Mentors'''

c_schmitz (Carsten Schmitz)

==LimeSurvey 1: Authentication framework==

The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this interface must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provision the token table of the correspoding survey (only if the token for this user has not been already added).

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

==LimeSurvey 2: Db Storage Engine==

Develop an extensible plugin survey storage engine for LimeSurvey 2.

Description

Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.

For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.

Rationale

Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey’s functions we will the ease with which LimeSurvey can be developed in the long term.

Implementation

This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.

The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.

Requirements & Considerations

The DB Engine must be able to do the following
* ease development of additional '''question types, which will be developed as plugins'''
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.
* support survey resuming (where applicable)

Field Naming and Database Extensibility Methodologies

An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to ‘freeze’ the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn’t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations – sometimes running up against database limitations regarding the number of fields per table.

An alternative is a ‘normalised’ database topology where a single table is created to store all survey responses – one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.

In a perfect world LimeSurvey would allow users to choose either methodology – either at an installation level or even on a per-survey level.

Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.

'''Skills'''

PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures

'''Difficulty'''

High

'''Probable Mentors'''

jasebo (Jason Cleeland)

macduy (Mac Duy Hai)

==LimeSurvey 2: Template Editor==

Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.

'''Skills'''

One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.

'''Difficulty'''

You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.

'''Probable Mentors'''

Mazi

==LimeSurvey 2: Mini-projects==

Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality

'''Skills'''

PHP, CakePHP, JavaScript & jQuery

'''Difficulty'''

Moderate

'''Probable Mentors'''

Mac Duy Hai (macduy)

==LimeSurvey 2: Template/Theme Editor==

The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.

The overview of the modules can be seen here:

[[File:theme_roller.png]]

It’ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)

The following mock-up will give us a better view:

Moderate[[File:theme_editor_small.png]]

'''Skills'''

PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.

'''Difficulty'''

Moderate

==LimeSurvey 2: Lime Survey Social - Facebook Application==

The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.

The facebook has the following modules (we can add more. This is primary draft.)
*All Survey related core features. (Create, Edit, Delete, Administer etc)
*Gain reward points.
*Use reward points to create more surveys.
*Spread the surveys ...... and more

The idea can be extended to other social networks

[[File:fb_overview.png]]

The mock-ups :

[[File:facebook app.png]]

[[File:canvas.png]]

'''Skills'''

PHP, CakePHP, Facebook API.

'''Difficulty'''

Moderate

==LimeSurvey 2: Integration of Poll Questions==

Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.

The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback “about the survey” at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.

A simple mock-up for this:

[[File:chat.png]]
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.

We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.

'''Skills'''

PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.

'''Difficulty'''

Moderate

==LimeSurvey 2: Survey Community Project==

Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.

For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.

'''Skills'''

PHP, CakePHP, Web and User Interface Design Skills

'''Difficulty'''

Moderate

'''Probable Mentors'''

Jason Cleeland (jasebo)

==LimeSurvey 2: Condition Engine==

[[File:addNewCondition1.png]]

Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

=We want your ideas!=

What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.

=More Information=

==LimeSurvey Google's Summer of Code 2009==
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2009 Limesurvey GSoC 2009]

An introduction to LimeSurvey and our application for this years Google Summer of Code

==Getting Started==
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC 2009]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

Project ideas for GSOC 2010

2010-03-16T21:37:49Z

Lemeur:

Project ideas for GSOC 2010

2010-03-16T21:24:43Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#eligibility eligible candidate] for the GSoC program.

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)

=Project ideas=

==Example Format...==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

==LimeSurvey 1: File Upload question type==

The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)
*Extensive configuration options for the question type like
**How many files are required, minimum and maxim number of files,
**maximum/minimum upload size,
**Allowed file types
*Safe!! storage in the file system, checks for file contents
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses
*Provide possible hooks for third party processing tools

'''Skills'''

PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage

'''Difficulty'''

Medium

'''Probable Mentors'''

c_schmitz (Carsten Schmitz)

==LimeSurvey 1: Authentication framework==

The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes. Currently authentication is only used for the survey-administration GUI and not the participants interface (tokens are used for this). With the new authentication framework it will be possible to define several authentication backends and use some of them for participants-authentication.

The generic authentication framework must define the following services:
* User authentication: this API must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...
* User provisionning:
** when activated on the survey administration interface, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform). The newly created user can be assigned a default profile or a per-user profile (queried from an external database).
** when activated on the participants interface, the authentication module will provisionned the token table for the survey (if not already done).

The already existing authentication schemes will be ported to the new framework (internal-DB and Web server authentication delegation) and at least a new one will be implemented (openID, CAS, Shibboleth).

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

==LimeSurvey 2: Db Storage Engine==

Develop an extensible plugin survey storage engine for LimeSurvey 2.

Description

Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.

For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.

Rationale

Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey’s functions we will the ease with which LimeSurvey can be developed in the long term.

Implementation

This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.

The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.

Requirements & Considerations

The DB Engine must be able to do the following
* ease development of additional '''question types, which will be developed as plugins'''
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.
* support survey resuming (where applicable)

Field Naming and Database Extensibility Methodologies

An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to ‘freeze’ the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn’t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations – sometimes running up against database limitations regarding the number of fields per table.

An alternative is a ‘normalised’ database topology where a single table is created to store all survey responses – one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.

In a perfect world LimeSurvey would allow users to choose either methodology – either at an installation level or even on a per-survey level.

Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.

'''Skills'''

PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures

'''Difficulty'''

High

'''Probable Mentors'''

jasebo (Jason Cleeland)

macduy (Mac Duy Hai)

==LimeSurvey 2: Template Editor==

Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.

'''Skills'''

One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.

'''Difficulty'''

You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.

'''Probable Mentors'''

Mazi

==LimeSurvey 2: Mini-projects==

Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality

'''Skills'''

PHP, CakePHP, JavaScript & jQuery

'''Difficulty'''

Moderate

'''Probable Mentors'''

Mac Duy Hai (macduy)

==LimeSurvey 2: Template/Theme Editor==

The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.

The overview of the modules can be seen here:

[[File:theme_roller.png]]

It’ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)

The following mock-up will give us a better view:

Moderate[[File:theme_editor_small.png]]

'''Skills'''

PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.

'''Difficulty'''

Moderate

==LimeSurvey 2: Lime Survey Social - Facebook Application==

The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.

The facebook has the following modules (we can add more. This is primary draft.)
*All Survey related core features. (Create, Edit, Delete, Administer etc)
*Gain reward points.
*Use reward points to create more surveys.
*Spread the surveys ...... and more

The idea can be extended to other social networks

[[File:fb_overview.png]]

The mock-ups :

[[File:facebook app.png]]

[[File:canvas.png]]

'''Skills'''

PHP, CakePHP, Facebook API.

'''Difficulty'''

Moderate

==LimeSurvey 2: Integration of Poll Questions==

Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.

The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback “about the survey” at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.

A simple mock-up for this:

[[File:chat.png]]
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.

We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.

'''Skills'''

PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.

'''Difficulty'''

Moderate

==LimeSurvey 2: Survey Community Project==

Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.

For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.

'''Skills'''

PHP, CakePHP, Web and User Interface Design Skills

'''Difficulty'''

Moderate

'''Probable Mentors'''

Jason Cleeland (jasebo)

==LimeSurvey 2: Condition Engine==

[[File:addNewCondition1.png]]

Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

=We want your ideas!=

What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.

=More Information=

==LimeSurvey Google's Summer of Code 2009==
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2009 Limesurvey GSoC 2009]

An introduction to LimeSurvey and our application for this years Google Summer of Code

==Getting Started==
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC 2009]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

Project ideas for GSOC 2010

2010-03-16T21:09:28Z

Lemeur:

__TOC__

=Welcome=

Welcome Google Summer of Code Student aspirants (:razz:)!! Please check if you are an [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs#eligibility eligible candidate] for the GSoC program.

This page lists project ideas developed by the LimeSurvey Community. These tend to be areas that will get the most support as projects since they have been developed by people who know the project and what it needs the most. '''However''', if you have your own idea for a project discuss your awesome idea with us in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing list] or at #limesurvey on irc.freenode.net. Then submit '''your''' proposal. Good Luck (:biggrin:)

=Project ideas=

==Example Format...==

Describe the idea here in general terms

'''Skills'''

Explain what sort of coding skills would be needed for a student to implement this project

'''Difficulty'''

Explain the level of difficulty involved

'''Probable Mentors'''

Put your name (and tag) here if you are willing to mentor a student for this idea

==LimeSurvey 1: File Upload question type==

The idea is to have a question type in LimeSurvey1 where survey participants can upload one (or more) files. Often in surveys the participant is asked to create some content (pictures, movies, documents, etc.) to upload as an answer to a question. The following goals are primary in this task:
*Easy handling for the participant (uploading one or more files should be a piece of cake - also removing files if accidentally the wrong file was uploaded)
*Extensive configuration options for the question type like
**How many files are required, minimum and maxim number of files,
**maximum/minimum upload size,
**Allowed file types
*Safe!! storage in the file system, checks for file contents
*Implementation in statistics / data entry / printable survey / response browsing / response editing & RemoteControl
*Administrator can download one or more files (zip-packaging files for download) from one response and across responses
*Provide possible hooks for third party processing tools

'''Skills'''

PHP, jQuery, AJAX - existing knowledge on the general idea and related security would be of big advantage

'''Difficulty'''

Medium

'''Probable Mentors'''

c_schmitz (Carsten Schmitz)

==LimeSurvey 1: Authentication framework==

The idea is to design and implement a generic authentication framework for LimeSurvey 1 as well as some authentication modules. The Authentication framework will make it possible to implement any kind of authentication backend apart from the already existing internal-DB and Web server delegation schemes.

The generic authentication framework must define the following services:
* User authentication: this API must return the identity of the authenticated user if authentication is successful.
** Authentication may not always be based on a simple user/password form, so the proposed framework must be generic enough to enable authentication based on other schemes (using any numbers or GET/POST parameters or any other contextual parameter such as Referrer, session variable...
* User provisionning: when activated on the LimeSurvey installation, an authentication module might be able to create a newly authenticated user into the LimeSurvey internal DB (which is required for setting the user rights on the platform).
** if the authentication module provides a user-provisionnong facillity, the profile used for the enwly created user (for instance his rights), might depend on the user name and an external database

'''Skills'''

PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)

'''Difficulty'''

Medium

'''Probable Mentors'''

lemeur (Thibault Le Meur)

==LimeSurvey 2: Db Storage Engine==

Develop an extensible plugin survey storage engine for LimeSurvey 2.

Description

Other than survey design, everything that happens in LimeSurvey centres around the ability to save responses to questions to a database, and retrieve the responses again when required. Historically these functions have been incorporated within the various functions of LimeSurvey and this has locked LimeSurvey to a single methodology for data storage and retrieval and made future modifications and improvements difficult if not possible.

For this project we are looking for students to write a 'middleware' that exposes abstract high-level functions to LimeSurvey 2 (e.g.: storing these answers related to this question, running statistical analysis etc.) but is built in top of Cake's 'low-level' operations (such as find, save etc). The aim is to abstract away from a specific DB implementation and provide an intuitive and rich API for LS2.

Rationale

Because the interface with the data storage system is so critical to practically every other function in LimeSurvey we want to develop a stand-alone module that is transportable and extensible for the future. And by keeping the logic of data and survey storage separate from the rest of LimeSurvey’s functions we will the ease with which LimeSurvey can be developed in the long term.

Implementation

This is such an important project that we would consider multiple students undertaking the task. In conjunction with a strong understanding of data structures, php coding and api principles the students would also have to display a capacity to work in a team and with the broader community.

The implementation would focus on becoming a plugin/addon module under CakePHP which uses the default CakePHP database systems to the absolute minimum. In a well implemented version of this proposal only simple SQL inserts, queries and updates would be required. All other logic would be managed by the engine.

Requirements & Considerations

The DB Engine must be able to do the following
* ease development of additional '''question types, which will be developed as plugins'''
* '''efficient data retrieval''', especially summaries (e.g. display 100 last responses)
* support '''generic''' data storage and retrieval - aside surveys, imagine running online admission tests, polls, sign-up forms, volunteer campaign etc. etc.
* easily support conditions, looped question, or generally, '''non-linear data'''. Think of a survey that asks how many children you have and then asks information about each of them.
* support questions that have multiple '''answers and multiple types of answers'''. Think of a question asking "What is your favourite ice cream?", offering 3 fixed options and last one allowing user to enter a custom answer.
* support survey resuming (where applicable)

Field Naming and Database Extensibility Methodologies

An ongoing debate in the LimeSurvey community has been the method in which the database stores survey results. In LimeSurvey 1 a flat database schema was used whereby once the survey designer had finished setting up the survey a database table was created with a field for every individual question/answer combination. The advantages of this database schema were speed of retrieval for reporting and exporting and searching. The disadvantages were that the survey system had to ‘freeze’ the structure in place once the table was created (therefore the activate/de-activate rules in LimeSurvey 1). The single table method doesn’t allow easy storage of metadata for individual question/answer combinations (such as timestamps). Nor does it lend itself to surveys with enormous quantities of question/answer combinations – sometimes running up against database limitations regarding the number of fields per table.

An alternative is a ‘normalised’ database topology where a single table is created to store all survey responses – one database row per question/answer combination. A related table would store metadata that is directly related to the survey sitting/session rather than the answer (e.g.: username, ip address, geographical location, user demographic). The advantage to this methodology is the increased flexibility (extensible) which would allow modification of surveys at any stage even after data has been collected (see requirements). The disadvantages are that searching and compilation of data is complicated and resource intensive.

In a perfect world LimeSurvey would allow users to choose either methodology – either at an installation level or even on a per-survey level.

Having a database storage engine effectively acting as an API would allow this functionality to be built, but the choice of database topology would be invisible to the related LimeSurvey functions that require data.

'''Skills'''

PHP, CakePHP, Database Schema Design, Sound knowledge of Algorithms and Data Structures

'''Difficulty'''

High

'''Probable Mentors'''

jasebo (Jason Cleeland)

macduy (Mac Duy Hai)

==LimeSurvey 2: Template Editor==

Limesurvey 2 needs a nice and powerful template editor so everyone can create a template which matches their requirements.

'''Skills'''

One needs to know about the details of the [http://dwoo.org/ dwoo template engine] which is used at LS2. There is some cakePHP coding needed to create an interface and write changes to the template files as well as some HTML/CSS to create a nice interface.

'''Difficulty'''

You don't have to create difficult algorithms for this task. It's useful if you have worked with templates for another web-application or take a detailled look at [http://docs.limesurvey.org/tiki-index.php?page=Themes%3A+Templates+and+Styles&structure;=English+Instructions+for+LimeSurvey how templates work in Limesurvey]. Some design/usability background would be nice but is not a must.

'''Probable Mentors'''

Mazi

==LimeSurvey 2: Mini-projects==

Mini-projects is a collection of small-to-medium sized projects, which you mix-and-match according to your tastes. Heck, you can even roll your own idea and once reviewed and approved, you can code away. Some recommended/important mini-projects and their brief descriptions:
*'''Smarter installer:''' LS2.0 comes with its own installer, though it may not be the friendliest to use. Your task is to make it juicier to use:
** Resume installation - if the user aborts the installation mid-way, make it easy for him to resume it
** Better error handling - meaningful error reports, suggestions how to fix them: e.g. "Database does not exist" is better than "Database error"
** Customization - invite the user to customize his installation of LimeSurvey - from security settings such as salt, to interface such as the header title.
*'''User management:''' When the number of users grow, it becomes increasingly harder to manage them. Implement functionality and provide interface for features that would make this task easier. Inspire yourself by the big players, such as the infamous you-know-which-one social website.
**'''Groups within groups:''' LS2 users can belong to a group, but groups cannot belong to other groups.
**'''Contact lists:''' There is already something called AssignmentGroups. Study this concept carefully and generalize to a Contact List
**'''GUI:''' Design a GUI which allows you easily manage users, groups and contact lists.
**'''Searching:''' Provide an efficient but simple-to-use search interface and functionality

'''Skills'''

PHP, CakePHP, JavaScript & jQuery

'''Difficulty'''

Moderate

'''Probable Mentors'''

Mac Duy Hai (macduy)

==LimeSurvey 2: Template/Theme Editor==

The idea is to develop a theme / template framework similar to one in jquery [http://jqueryui.com/themeroller/ | Jquery Theme Roller] and thus making the UI design of the surveys easier.The current template editor is based on dwoo template engine which actually loads the files exposing the css etc for us to edit, which of course require some skill set to proceed. Using this template editor we can make everything UI based and thus requiring no developer skills to edit the templates.

The overview of the modules can be seen here:

[[File:theme_roller.png]]

It’ll be implemented using Jquery to use the more advanced UI experiences.(:biggrin:)

The following mock-up will give us a better view:

Moderate[[File:theme_editor_small.png]]

'''Skills'''

PHP, CakePHP, CSS, AJAX, JavaScript & jQuery.

'''Difficulty'''

Moderate

==LimeSurvey 2: Lime Survey Social - Facebook Application==

The idea aims at developing a Facebook app which gives a social touch to LS 2.0. The application will be integrated in several Facebook integration points like News Feed, Applications boxes, Wall etc so that the user participation will be more. Adding a social touch can drive us more user participation and increase the popularity. The ability to control the Facebook app can be provided in the LS2.0 Admin Dashboard and also in the FB user application window with varied options.

The facebook has the following modules (we can add more. This is primary draft.)
*All Survey related core features. (Create, Edit, Delete, Administer etc)
*Gain reward points.
*Use reward points to create more surveys.
*Spread the surveys ...... and more

The idea can be extended to other social networks

[[File:fb_overview.png]]

The mock-ups :

[[File:facebook app.png]]

[[File:canvas.png]]

'''Skills'''

PHP, CakePHP, Facebook API.

'''Difficulty'''

Moderate

==LimeSurvey 2: Integration of Poll Questions==

Polls are one of the most popular and quick response getting tools once can use. Implementing polls in LS 2.0 will be an added advantage. Since every one of us know what polls are about, this idea focuses on the implementation part.

The idea is to integrate the ability to create a POLL Module in Admin dashboard, where he can administer (Create | Edit | Delete | View Responses etc) the Polls.We can even get feedback “about the survey” at the end on how the user feels by creating a custom poll (we can even redirect the user to this poll).
*Chat Bots and Polls: An another idea is to create chat bots so that whenever we create a poll, all the friends (who added the bot) of that bot will be pinged by the question followed by options. Getting an answer is very easy (Bot friends just need to type a single letter stating the answer) and its a push model which ensures the delivery to everyone (even offline).We can even extend this to deliver certain type of surveys question by question through the bot.

A simple mock-up for this:

[[File:chat.png]]
*Alternate Solution: An alternate solution provided by Mazi is clubbing this idea with the Facebook app idea. Instead of porting parts of the admin backend to facebook or other social networks we'll have options in Admin panel to "publish as: common survey |mobile device survey | facebook poll | homepage poll | ... etc " Everything will be put together at the usualm admin backend but you can choose which way(s) you want publish your survey.

We can further extend this idea by giving additional options to publish as widgets for websites and blogs etc.

'''Skills'''

PHP, CakePHP, XMPP Protocol (Knowledge of developing bots), Knowledge of Polls.

'''Difficulty'''

Moderate

==LimeSurvey 2: Survey Community Project==

Build a system for LS2 that connects to a central repository of survey resources, such as demographic questions, answer styles and templates. Integrating with a login system, allow LimeSurvey users to easily publish their work to a community resource or use other published works from the same location.

For many finding already written question texts, or standardised demographic questions would really simplify their use of a survey tool. LimeSurvey could leverage on the community spirit of an open source product and encourage users to share their own work. By integrating a "Publish to the LimeSurvey Library" button in the administration system with questions, or templates, or anything else that can be shared, LimeSurvey could develop a library of tools that simplifies Survey Creation even further.

'''Skills'''

PHP, CakePHP, Web and User Interface Design Skills

'''Difficulty'''

Moderate

'''Probable Mentors'''

Jason Cleeland (jasebo)

==LimeSurvey 2: Condition Engine==

[[File:addNewCondition1.png]]

Build a system for LS2 that will let survey administrators design, store and evaluate conditions. Conditions can be used in several features such as question branching (survey logic), assessments, quotas, ...

This projects will at least end up with:
* A working GUI to design complex conditions:
** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses
** an atomic condition representation can be

<syntaxhighlight lang="php" enclose="div"><left operand> <operator> <right operand></syntaxhighlight>
** an atomic condition editor will implement
*** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...
*** meta operators surch as 'Not displayed'
** left and right operands can be answers from previous questions, or a static values. It should be extensible so that we are able in the future to use more complex operand such as the result of a specific function (for instance the sum of some previous integer questions)
* A working DB storage backend using a string in [http://en.wikipedia.org/wiki/Reverse_Polish_Notation RPN] (Reverse Polish Notation) to describe each condition
* A first version of the evaluation of conditions for the question branching feature. This part will require interaction with other parts of the projects (Survey Engine, and DB engine).

'''Skills'''

PHP, CakePHP, JQuery and User Interface Design Skills

'''Difficulty'''

High

'''Probable Mentors'''

Thibault Le Meur (lemeur)

=We want your ideas!=

What floats your boat? Do you have another idea that gets you excited? Discuss your ideas in our [http://www.limesurvey.org/component/option,com_fireboard/Itemid,105/func,view/catid,11/id,24710/lang,en/ forums], [https://lists.sourceforge.net/lists/listinfo/limesurvey-developers mailing lists] or at #limesurvey on irc.freenode.net.

=More Information=

==LimeSurvey Google's Summer of Code 2009==
*[http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2009 Limesurvey GSoC 2009]

An introduction to LimeSurvey and our application for this years Google Summer of Code

==Getting Started==
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started How to get started with LimeSurvey's GSoC 2009]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

==Frequently Asked Questions==
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google's Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

LimeSurvey GSoC 2010

2010-03-10T21:16:20Z

Lemeur:

__TOC__

=Google Summer of Code 2010=

LimeSurvey is applying to be involved in the Google Summer of Code for 2010

=General Information=

Google has been continuously supporting Open Source Projects and students coming together since 2005 through its ''Google Summer of Code Programs''. GSoC 2010 has been announced and is On!

LimeSurvey was accepted as a mentoring organisation for the first time in 2009, and is hopeful and excited about he opportunity to participate again in 2010. We plan to give students an excellent environment and platform to '''learn''' and most importantly to have '''fun''' (:lol:)!

The LimeSurvey community, at the same time, will benefit by students' participation and fresh eyes and ideas.

Find out more about our program in 2010 at [http://docs.limesurvey.org/tiki-index.php?page=Limesurvey+GSoC+2010&structure;=LimeSurvey+Development LimeSurvey GSoC 2010]

==Google Summer of Code Program Information==

Google Summer of Code is a great program both for Open Source organizations like LimeSurvey as well as students because it gives a platform where several tasks on Open Source Projects are done by students and students in return get a stipend from Google.

There's a lot more information available in Google's Summer of Code [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs FAQ] and [http://code.google.com/p/google-summer-of-code/ Knowledge Base]. You can also join #gsoc on irc.freenode.net to get feedback or ask questions about Google Summer of Code in real time.

The timelineline can be found [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline here].

==LimeSurvey Specific Information==

Welcome to the LimeSurvey Community (:biggrin:). LimeSurvey is an open source survey engine that allows people to create and deploy surveys (from marketing to academic to engineering applications). LimeSurvey is written in PHP and used by many high profile organizations including [https://wiki.ubuntu.com/ServerTeam '''Ubuntu Server Team'''], [http://foundation.gnome.org/ '''GNOME Foundation'''] and [http://www.vorarlberg.at/ '''Office of the Austrian Vorarlberg State Government''']

Limesurvey is loved and used by many Universities, Students, Medical Institutes, non-profit organisations, marketing companies and more around the world. In the 2004 '''U.S. presidential election''', the [http://www.verifiedvoting.org/article.php?id=5207 '''Verified Voting Foundation'''] used PHPSurveyor (as LimeSurvey was then known) to gather data about voting irregularities. Sourceforge provide LimeSurvey as a free application for open source projects. LimeSurvey keeps turning up in new places.

It's loved because it is free, flexible and constantly improving. It's constantly improving because it has a dedicated and committed team of developers who love the challenge and satisfaction of using and building such a tool.

LimeSurvey is widely used. It has been directly downloaded from Sourceforge over '''130,000 times''' in the last 12 months alone, and is also distributed as a package in the '''Ubuntu Linux Distribution''', and included as a pre-installed application in many standard Web Hosting packages (such as '''Fantastico''').

LimeSurvey is recognised as a leader in its field. On November 29, 2007 LimeSurvey won the '''1st prize award''' at the [http://www.trophees-du-libre.org/index.php?lang=en '''Les Trophées du Libre'''] contest in the category Corporate Management. In 2008 LimeSurvey was nominated in the category Best Project for the Enterprise in the SourceForge.net '''Community Choice Awards 2008'''. LimeSurvey was succesful in being selected as a mentoring organisation for the Google Summer of Code in 2009.

LimeSurvey is the biggest, most active and most exciting open source online survey project, and we're building on our success by creating a whole new version of the tool.

LimeSurvey Version 2 is a whole new - built from the ground-up - version that will revolutionise online survey design and use.

More importantly, it's a perfect opportunity for a GSoC student like yourself to get involved early in a project that has a strong history and an even stronger future. Our community is welcoming and fun. One of our students from 2009 has now become the project lead for LimeSurvey 2. It's a classic case of the student becoming a master!

==GSoC Student Aspirants==

Please visit our [http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 ideas page] and see if any idea interests you. If you have an idea of your own, then develop it. If any idea excites you, and you want to implement that feature during the summer of 2010, see how you can [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started get started] on it. Come and join us on the IRC channel on freenode (#limesurvey) and talk about what you want to do.

==LimeSurvey Mentors==

The following mentors are willing to Mentor students during Google Summer of Code 2010 program.

Others who are willing to mentor can write their name and details below along with the Idea they are willing to mentor. '''Potential Mentors, please do not forget to put your ideas on the [http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 ideas page] and contact [mailto:jason@cleeland.org| program administrator]'''

{|
|<center>'''Mentor Name'''</center>||<center>'''Nick'''</center>||<center>'''Idea'''</center>
|-
|<center>Jason Cleeland</center>||<center>jasebo</center>||<center>Currently Thinking About It</center>
|-
|<center>Carsten Schmitz</center>||<center>c_schmitz</center>||<center>File upload question type in LimeSurvey 1</center>
|-
|<center>Marcel Minke</center> <center>[http://docs.limesurvey.org/tiki-index.php?page=UserPage Mazi||Mazi]</center>||<center>Template editor?</center>
|-
|<center>Mac Duy Hai</center>||<center>[[UserPage macduy||macduy]]</center>||<center>Database Storage Engine, Mini-projects</center>
|-
|<center>Thibault Le Meur</center>||<center>lemeur</center>||<center>Condition Engine</center>
|-
|
|}

==More Information==

===Getting Started===
*[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started GSoC Getting Started]

How to Get Started With LimeSurvey:

- setting up the development environment, coding standards, and all the other important stuff that you need to know before the real fun begins!

===Project Ideas Page===
*[http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+2+Project+Ideas+for+GSOC+2010 GSoC Ideas Page]

The LimeSurvey Community Ideas Page:

- ideas that the community have come up with and would love to help you create

===Frequently Asked Questions===
* [http://socghop.appspot.com/document/show/program/google/gsoc2009/faqs Google Summer of Code Faqs]
* [http://docs.limesurvey.org/tiki-index.php?page=GSoC_Faqs LimeSurvey's GSoC Faqs]

Survey security settings

2009-11-02T14:00:51Z

Lemeur:

From this screen you can add other users/groups who may have access to your survey. After adding a group/user you can assign the following special rights:

=Edit survey properties=
*Edit Current Survey
*Set Assessment rules
*Initialize and Manage Tokens

=Define questions=
*Add/Edit/Remove Groups
*Add/Edit/Remove Questions
*Add/Edit/Remove Answers
*Add/Remove Conditions
*Copy Question
*Preview Question

=Browse responses=
*Browse Responses / Responses Management ( No Delete )
*View saved but not submitted responses
*View Tokens
*Data Entry

=Export=
*Export Survey Structure
*Export Groups
*Export Questions
*Export Tokens
*Export Survey Results

=Delete survey=
*Delete Survey
*Delete Responses

=Activate Survey=
*Activate Survey
*Initialize and Manage Tokens

Standard for Git commit messages

2009-05-25T08:57:45Z

Lemeur:

__TOC__

=General overview=

This page describes the standard format of commit messages. Indeed, standard commit messages will ease the automatic generation of releases change logs.

=Rules=

==Syntax==
* Each commit message is made up of one or more commit blocks
* A commit block:
** The first line is the 'Commit Summary' and describes the committed patch in a user friendly way
** the following lines begin with the Keyword '''Dev''' and are intended to the developpers team

<pre>

<Commit type> <commit description> <NEWLINE>

[ Dev <development details> <NEWLINE> ]

[ Dev <development details> <NEWLINE> ]

<Commit type> <commit description> <NEWLINE>

[ Dev <development details> <NEWLINE> ]

[ Dev <development details> <NEWLINE> ]

</pre>

==The commit type==

The first word in the commit message gives the commit type:
* If the commit is about a fix, the commit message must begin with the keyword ''''Fix'''' or ''''Fixed issue''''
* If the commit is about a change in LS feature, the commit message must begin with the keyword ''''Update feature'''' or ''''Updated feature''''
* If the commit is about a change in LS language, the commit message must begin with the keyword ''''Update language'''' or ''''Updated language''''
* If the commit is about a new feature, the commit message must begin with the keyword ''''New feature''''
* If the commit is about a new language, the commit message must begin with the keyword ''''New language''''

==The commit description==

Following the commit type is the commit description.

This must be a single line (no newline character), and is intended to be used in the generated changelog.

Ideally it is a text readable by end-users: for instance if you're resolving a bug ticket which has a very technical description, please use a "end-user friendly description".

==The development details==

Develoment details are added in extra optionnal lines, each one beginning with the keyword ''''Dev''''.

==Patches which require multiple commits==

When multiple commits are linked to the same topic (same new feature, same fix, ...), the 'Commit Summary' line of subsequent commits must be the same as the one provided for the first commit.

Of course the development details can differ.

== Examples:==

Example of a simple Language File Update

<pre>

Updated language: German.

</pre>

Example of a single bug which is fixed in several commits:

<pre>

Fixed issue 02565: Can't access survey more than once on the same browser window

Dev this fixes this bug for survey with tokens.

Dev When showing a new token (different from the one in session), the previous session is destroyed.

Fixed issue 02565: Can't access survey more than once on the same browser window

Dev this fixes this bug for survey without tokens and without answer preview.

Dev Session is destroyed at submit time.

Fixed issue 02565: Can't access survey more than once on the same browser window

Dev this fixes this bug for survey without tokens and with answer preview.

Dev Session is destroyed when closing the answer preview window or closing the Submit confirmation page.

</pre>

Example of a single commit containing several fixes each with a Dev comment:

<pre>

Fixed issue 01234: fixed some untranslated strings

Dev missing call to clang-gT in admin.php

Fixed issue 02345: fixed a small layout issue in condition editor

Dev fixed div HTML elements

</pre>

=Automatic version info=

To have Information about Fileversion, author and commitdate automatically generated on commit. You must do three Things.
* Put the GPL Info and the Id tag into your new or unversionized file. It always looks like this:

<pre>

/*
* LimeSurvey
* Copyright (C) 2007 The LimeSurvey Project Team / Carsten Schmitz
* All rights reserved.
* License: GNU/GPL License v2 or later, see LICENSE.php
* LimeSurvey is free software. This version may have been modified pursuant
* to the GNU General Public License, and as distributed it includes or
* is derivative of works licensed under the GNU General Public License or
* other free or open source software licenses.
* See COPYRIGHT.php for copyright notices and details.
*
* $Id$
*
*/

</pre>

The important Tag is the $Id$, which will be replaced with the version info.
* Assuming you use TortoiseSVN, go to the folder with you newly created or unversioned file and right-click on the file.
** Under the Context-Menu "TortoiseSVN" you will find the Option "Properties". Go to the Properties.
** Now you see an empty list with Options New and Import(others are not clickable).
** Choose "new".
** Choose "svn:keyword" from the Property-Name-Dropdown-Menu and
** type "Id" as value.
** Click OK.
* Now commit the file... and voila! The new file is versionized.