https://www.limesurvey.org/api.php?action=feedcontributions&feedformat=atom&user=Magiclko 2026-08-13T12:27:51Z User contributions MediaWiki 1.43.9 https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2492 2011-03-08T20:06:09Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter, jQuery. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Adding new questions/subquestions and groups dynamically==<br /> <br /> Currently in LimeSurvey once a survey is activate we can not<br /> *Add or delete groups<br /> *Add or delete questions<br /> *Add or delete subquestions or change their codes<br /> <br /> The idea is to cover these shortcomings. And in addition, all those participants who have already taken that survey must also be notified about the changes.<br /> <br /> '''Skills'''<br /> <br /> Experience with a PHP framework like CakePHP or CodeIgniter and knowledge of inner working of LimeSurvey is must!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2493 2011-03-03T13:09:01Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter, jQuery. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Adding new questions/subquestions and groups dynamically==<br /> <br /> Currently in LimeSurvey once a survey is activated we can not<br /> *Add or delete groups<br /> *Add or delete questions<br /> *Add or delete subquestions or change their codes<br /> <br /> The idea is to cover these shortcomings. And in addition, all those participants who have already taken that survey must also be notified about the changes.<br /> <br /> '''Skills'''<br /> <br /> Experience with a PHP framework like CakePHP or CodeIgniter and knowledge of inner working of LimeSurvey is must!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2494 2011-03-02T21:20:15Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter, jQuery. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2495 2011-03-02T20:33:39Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2496 2011-03-02T20:21:16Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2497 2011-03-02T20:20:05Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, CodeIgniter, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> ----<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CodeIgniter, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> 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.<br /> <br /> ----<br /> <br /> ==Custom Report Generation==<br /> <br /> The task is to make a module which will generate custom reports. Module should be able to do these things(at least) :-<br /> *Creating various types of reports i.e. using tables, pie charts, graphs and bar-charts to name few.<br /> *The resulting charts and other illustrations should be easy to read and understand, and should include the ability to export into standard office suites.<br /> *Reports can be general or survey specific.<br /> **General in the sense that it should show basic findings of a general survey graphically like number of users completing the survey, average time taken to complete the survey, average number of correct responses etc.<br /> **Survey specific results should also be addressed properly e.g. how many users choose first option as there answer of a particular question, how many users didn't answer a specific question etc.<br /> <br /> '''Skills'''<br /> <br /> OOP experience in PHP and experience with a PHP framework like CakePHP or CodeIgniter. Strong mathematical background will help!<br /> <br /> '''Difficulty'''<br /> <br /> Moderate<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2500 2011-03-01T21:08:50Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CakePHP, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Project_ideas_for_GSOC_2011&diff=2501 2011-03-01T21:07:56Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =Welcome=<br /> <br /> Welcome Google Summer of Code Student aspirants (:razz:)<br /> <br /> 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:)<br /> <br /> ----<br /> <br /> =Project ideas=<br /> <br /> ==Central participants database (User panel)==<br /> <br /> Develop a central 'participants' database for LimeSurvey that can be used as a central registry of participants between surveys. The database should allow<br /> * adding/removing of users along with flexible data to store related information for users<br /> * simple copying of user-information to individual survey token tables<br /> * ability to link user entries with survey responses if the linked survey was not unanimous (UUIDs?)<br /> * ability for survey participants to register in the panel<br /> * ability to update the flexible user data from collected results<br /> * a 'do not email' blacklist to allow people to automatically unsubscribe<br /> * data ownership features for multi-user systems - allow different LimeSurvey users to 'own' different participants<br /> <br /> '''Skills'''<br /> <br /> Database and PHP coding<br /> <br /> '''Difficulty'''<br /> <br /> Moderate to high - the coding would be relatively simple, but will entail complex relationships<br /> <br /> '''Probable mentors'''<br /> <br /> Jason Cleeland<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey front-end to CodeIgniter==<br /> <br /> 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:<br /> *Survey taking<br /> *Public statistics<br /> *Central landing page<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Port the LimeSurvey back-end (administration) to CodeIgniter==<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> '''Skills'''<br /> <br /> 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.<br /> <br /> '''Difficulty'''<br /> <br /> 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.<br /> <br /> 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]] )<br /> <br /> '''Probable mentors'''<br /> <br /> Carsten Schmitz (c_schmitz)<br /> <br /> Thibault le Meur (tlemeur)<br /> <br /> ----<br /> <br /> ==Implement a modular authentication framework==<br /> <br /> The idea is to design and implement a modular authentication &quot;framework&quot; 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, ...<br /> <br /> 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.<br /> <br /> The generic authentication framework must define the following services:<br /> * User authentication: this interface must return the identity of the authenticated user if authentication is successful.<br /> ** 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...<br /> * User provisionning:<br /> ** 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).<br /> ** 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.<br /> <br /> 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).<br /> <br /> '''Skills'''<br /> <br /> PHP, SQL, Authentication protocols (openID, CAS, LDAP-bind, ...)<br /> <br /> '''Difficulty'''<br /> <br /> Medium<br /> <br /> '''Probable Mentors'''<br /> <br /> lemeur (Thibault Le Meur)<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010++Authentication+framework#FAQ FAQ about this project]<br /> <br /> == Rewrite and extend the conditions in LimeSurvey==<br /> <br /> [[File:addNewCondition1.png]]<br /> <br /> 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, ...<br /> <br /> This projects will at least end up with:<br /> * A working GUI to design complex conditions:<br /> ** several atomic conditions can be combined by AND or OR logical operators and will support for grouping conditions with parentheses<br /> ** an atomic condition representation can be<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;&lt;left operand&gt; &lt;operator&gt; &lt;right operand&gt;&lt;/syntaxhighlight&gt;<br /> ** an atomic condition editor will implement<br /> *** several operators (equality, inequality, string-comparisons, numerical-comparisons, regexp),...<br /> *** meta operators surch as 'Not displayed'<br /> ** 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)<br /> * 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<br /> * The evaluation of conditions for the question branching feature.<br /> <br /> '''Skills'''<br /> <br /> PHP, CakePHP, JQuery and User Interface Design Skills<br /> <br /> '''Difficulty'''<br /> <br /> High<br /> <br /> '''Probable Mentors'''<br /> <br /> Thibault Le Meur (lemeur)<br /> <br /> Carsten Schmitz<br /> <br /> '''Want to know more'''<br /> <br /> Please read the [http://docs.limesurvey.org/tiki-index.php?page=GSOC+2010+Condition+engine FAQ about this project]<br /> <br /> ----<br /> <br /> ==Idea template==<br /> <br /> Describe the idea here in general terms<br /> <br /> '''Skills'''<br /> <br /> Explain what sort of coding skills would be needed for a student to implement this project<br /> <br /> '''Difficulty'''<br /> <br /> Explain the level of difficulty involved<br /> <br /> '''Probable Mentors'''<br /> <br /> Put your name (and tag) here if you are willing to mentor a student for this idea<br /> <br /> ----<br /> <br /> =More information=<br /> <br /> ==Getting started==<br /> <br /> [[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!<br /> <br /> ==Frequently Asked Questions==<br /> <br /> Check out [[GSoC FAQ|our GSoC FAQ page.]]</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=Label_sets&diff=1838 2011-02-22T14:33:22Z

<p>Magiclko: </p> <hr /> <div><br /> __TOC__<br /> <br /> =General=<br /> <br /> &lt;div class=&quot;simplebox&quot;&gt;The function and usage of label sets have change radically with version 1.90. This page refers to v 1.90 or newer versions.&lt;/div&gt;<br /> <br /> Label sets are basically list templates where each list has a set of codes with labels and can be used in most question types either as answers or as subquestions. Contrary to earlier versions of LimeSurvey label sets are merely copied to the particular question as subquestion or answers. So if you change a label set after you 'used' it the changes are not propagated to the questions where a label set has been used as a template.<br /> <br /> This new usage of label sets gives much more flexibility for future development and makes the structure of a question more logical.<br /> <br /> &lt;div class=&quot;simplebox&quot;&gt;'''Hint:''' A label set must be at least contain the same base language as the survey, else you will not be able to use it for any question of your survey.&lt;/div&gt;<br /> <br /> An example of label set is as follows. If one wants to define a custom 7-point scale, a label set provides this function. In this example, a very simple custom label set with the code/label pairs is shown. Note that the label is what appears in the actual questions.<br /> <br /> {|<br /> |'''Code'''||'''Label'''<br /> |-<br /> |1||Not useful at all<br /> |-<br /> |2||2<br /> |-<br /> |3||3<br /> |-<br /> |4||Somewhat useful<br /> |-<br /> |5||5<br /> |-<br /> |6||6<br /> |-<br /> |7||Very useful<br /> |}<br /> <br /> Another graphical example:<br /> <br /> Graphic (3 different smileys) instead of label text:<br /> <br /> [[File:3xSmiley-Question.gif]]<br /> <br /> =How to...=<br /> <br /> Click on the [[File:labels.png]] &quot;Edit/Add Label Sets&quot;-Icon in the Administration-Menu to edit, create, delete, import or export label sets used in the 'flexible' labels questions.<br /> <br /> ==...add a new label set==<br /> *'''Set Name:''' Each new label set has to be given a name.<br /> *'''Languages:''' Every label set must be specified for the language it's used for. You can choose as many languages from the menu as you want.<br /> <br /> ==...import a label set==<br /> *Choose a previous exported label set in a .csv-Format and click on the &quot;Import Label Set&quot;-Button to import. Alternative: import a whole survey - in this case the Label-Sets are imported with the questions.<br /> *To edit a label set outside of LimeSurvey (for instance, using a text editor or Excel), see this tutorial: [[Editing label sets using Microsoft Excel]].<br /> <br /> ==...edit, delete, or export a label set==<br /> <br /> Choose an already existing label Set in the drop-down-Box in the label set administration bar to edit, delete or export a label set.<br /> *'''Edit label set:''' Here it&amp;acute;s possible to rename the Label Set and add/remove languages for this Label Set.<br /> **To edit a label set outside of LimeSurvey (for instance, using a text editor or Excel), see this tutorial: [[Editing label sets using Microsoft Excel]].<br /> *'''Delete label set:''' After a pop-up, you can delete the selected Label Set.<br /> *'''Export label set:''' Export current Label Set to a .csv-File.<br /> *'''Labels bar:'''<br /> <br /> +To add a new label you have to fill in a label code, assessment value and label-text and press on the &quot;Add new label&quot;-Button. After this the label should be listed above. It's possible to use a graphic instead of or additionally to a label text. Just use HTML-code to include the graphic you want, e.g.:<br /> <br /> &lt;syntaxhighlight lang=&quot;php&quot; enclose=&quot;div&quot;&gt;<br /> <br /> &lt;img border=&quot;0&quot; src=&quot;http://www.yourdomain.at/pics/pic.gif&quot;&gt;<br /> <br /> &lt;/syntaxhighlight&gt;<br /> <br /> If your label set has more than one language, you can choose which language you want to edit. Every label needs a code, an assessment value and a title. The code can only be changed in the base language of the Label Set. The assessment value can be ignored (set it to 0) if you do not use [[Assessments|assessments]]. The title is the text, which is displayed in the question.<br /> *'''Del-button''': You can delete labels with the &quot;Del&quot;-button.<br /> *'''Up/down-buttons''': It's possible to change the row of labels by the &quot;Up&quot; and &quot;Dn&quot;-buttons.<br /> *'''Fix sort''': You can check the consistency and do a sort of the labels by pressing the &quot;Fix Sort&quot;-Button.<br /> <br /> Labels which are in use by questions are hyperlinked to the question.<br /> <br /> &lt;div class=&quot;simplebox&quot;&gt;(:idea:) '''Hint:''' The order of the labels can be modified by editing the label-set, however it is not possible to add new labels once the label-set is in use with question of an active survey.&lt;/div&gt;<br /> <br /> &lt;div class=&quot;simplebox&quot;&gt;(:idea:) '''Hint:''' Some useful label sets are available on the [http://www.limesurvey.org/en/additional-downloads/Label-Set-Templates/ limesurvey site]&lt;/div&gt;<br /> <br /> =Uploaded resources management=<br /> <br /> This tab lets you manage files (pictures, media files) that were uploaded in the HTML Editor.<br /> <br /> You can:<br /> * Browse available files<br /> * Export files as a ZIP archive<br /> * Import a ZIP archive of files<br /> <br /> Caution:<br /> * Authorized file extensions are defined in config-defaults.php by your system administrator.<br /> * Files for the survey are in the upload/labels/&lt;lid&gt; sub directory.<br /> ** Uploaded files will only be seen while browsing resources on this survey objects (labels) not in other labels or objects (groups, questions, answers).<br /> ** However do not expect this limited visibility to ensure confidentiality of the resources as they are reachable with a simple browser to anyone who knows the URL to the file.<br /> * Creation of sub directories of the ZIP archive won't work.<br /> * You can't import a ZIP file containing sub directories.</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=LimeSurvey_Documentation_Wiki&diff=1908 2011-02-10T09:02:19Z

<p>Magiclko: </p> <hr /> <div><br /> =LimeSurvey manual (1.85 and later)=<br /> <br /> The LimeSurvey manual is available in the following languages:<br /> *[[File:gb.png]] '''[[English Instructions for LimeSurvey|English]] - This is the base language!'''<br /> *[[File:cn.png]] [[Chinese (Simplified) Manual|Chinese (Simplified]])<br /> *[[File:cn.png]] [[安装|Chinese (Traditional]])<br /> *[[File:fr.png]] [[Instructions fran&amp;ccedil;aises pour LimeSurvey|French]]<br /> *[[File:de.png]] [[Deutsche Anleitung f&amp;uuml;r LimeSurvey|German]]<br /> *[[File:gr.png]] [[Greek Manual|Greek]]<br /> *[[File:it.png]] [[Documentazione Italiano|Italian]]<br /> *[[File:jp.png]] [[日本語マニュアル|Japanese]]<br /> *[[File:pl.png]] [[Podręcznik obsługi|Polish]]<br /> *[[File:pt.png]] [[Manual de Instru&amp;ccedil;&amp;otilde;es do LimeSurvey|Portuguese]]<br /> *[[File:es.png]] [[Manual de Instrucciones en Espa&amp;ntilde;ol|Spanish]]<br /> <br /> Please note that not all translations are complete/up-to-date.  English is the base language (likely most complete and up-to-date). We always need help to translate pages from English to one of the other languages. If you would like to help, [[Creating, editing and translating LimeSurvey Wiki pages|start here]].<br /> <br /> =LimeSurvey development=<br /> *[[Development overview]] - General pages about LimeSurvey development<br /> *[[LimeSurvey 1.x development documentation]] - All pages about LimeSurvey 1 development<br /> <br /> =Translating LimeSurvey=<br /> <br /> If you want to '''add new translations''' or '''correct a translation''' please follow these instructions:<br /> *[http://docs.limesurvey.org/tiki-index.php?page=LimeSurvey+1.x+Translating+LimeSurvey How to translate LimeSurvey 1.x]<br /> <br /> =Google Summer of Code / Code-In participation=<br /> *[[LimeSurvey Google Code-in 2010]]<br /> *[[GSoC_Getting_Started]]<br /> *[[LimeSurvey GSoC 2011]]<br /> *[[LimeSurvey GSoC 2010]]<br /> *[[LimeSurvey GSoC 2009]]<br /> <br /> Temporary: [[LimeSurvey Documentation|Shadow, Structured copy]] of this top level page</div>

Magiclko https://www.limesurvey.org/manual/index.php?title=LimeSurvey_GSoC_2011&diff=2021 2011-02-09T11:04:12Z

<p>Magiclko: </p> <hr /> <div><br /> This is the main page for GSoC2011. Maybe you are interested in one of these subpages:<br /> *[http://docs.limesurvey.org/Project+Ideas+for+GSOC+2011 Project Ideas for GSOC 2011]<br /> *text<br /> <br /> ...or one of these general pages:<br /> *[http://docs.limesurvey.org/tiki-index.php?page=GSoC_Getting_Started Getting started]<br /> *text</div>

Magiclko