Welcome, Guest
Username: Password:

TOPIC: Your feedback: Plugins for LimeSurvey 2.05

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93275

  • c_schmitz
  • c_schmitz's Avatar
  • Online
  • LimeSurvey Team
  • Posts: 987
  • Thank you received: 134
  • Karma: 97
Article cannot be shown
Best regards

Carsten Schmitz
LimeSurvey project leader
The administrator has disabled public write access.
The following user(s) said Thank You: DenisChenu, actxcellence

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93293

  • helper
  • helper's Avatar
  • Offline
  • Expert Lime
  • Posts: 126
  • Thank you received: 18
  • Karma: 0
From my perspective (learning hospital/university), the objectivity of an API would be to provide hooks to other API's (for example, advanced web services). These could include interfaces with print services and/or electronic medical records (like Epic).

My current homegrown hooks:
  1. Output report customization for PDF/print and BLOB preparation for mainframe DB2.
  2. Output report writes to mainframe DB2
  3. Survey logon based on a medical record number and year of birth instead of token, username/password.
  4. Automatic token generation when a patient logs on.
  5. Appointment lookup (via web service to our appointment systems)
  6. Token population from patient registry flags (for example, diabetes, hypertension, etc.)
Last Edit: 3 years 2 months ago by helper.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93306

  • tfj
  • tfj's Avatar
  • Offline
  • Expert Lime
  • Posts: 80
  • Thank you received: 6
  • Karma: 5
At my workplace, we think this is great news. Many thanks to the LimeSurvey team!

In response to your request for suggestions for plugins, we would like to see an encrypted question type, which would encrypt the answer to a particular question. We accomplish this now through php scripts after the submit button is clicked for a particular record. We think it would be cleaner and more efficient to accomplish this in a plugin.

Thank you for considering our feedback.

tfj
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93370

  • thomsol
  • thomsol's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 4
  • Karma: 0
Anxious to see the Question Type plug-ins... Are the new (2.05) plug-ins documented anywhere? (Sorry, probably a newbie question)
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93381

  • Marsip
  • Marsip's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 2
  • Thank you received: 1
  • Karma: 0
Hello!

I would first have to thank you for your effort in making custom questions available via plugins. I wrote this topic a year ago ( www.limesurvey.org/en/forum/future-featu...s-with-a-php-plug-in ) and it is now much closer to reality.

I have checked the file \limesurvey\application\helpers\common_helper.php [v2.05] and it still contains hard coded questions.

I would suggest you to refactor the code by moving all of the current built-in questions into plugins. In the process you will learn what is needed to reimplement all of the current functionality via APIs. If you don't do this, there will always be first class (built-in) and second class (pluggable) question types.

I think the plugin would have to be a multifile solution, put into a separate directory:
- PHP template + custom CSS for front end (what people see when answering surveys)
- PHP template + custom CSS for back end (what admins see when creating surveys)
- PHP logic files; I'd like to see them implemented as interfaces (inheritance and other OO stuff); see php.net/manual/en/language.oop5.interfaces.php . Don't drop OO features, because of supporting 5.2 and earlier (they are EOLed anyway).

Maybe the logic could be in three parts:
- front-end only logic file
- back-end only logic file
- common front- and back-end logic file

Basically my end use scenario is to get question options from a SQL server, they could be different for different groups of respondents (tokens). One of the API calls could be: get me info for this token (name, lastname, group)

Don't be afraid to break SQL schema compatibility. I wrote my own software that imports data directly from lime sql tables, but I'm not that much bothered if I have to do some adjustments to the code.

question types have to have a more descriptive designation, not only a capital letter. I suggest vendor.questiontype. For the built-in questions it could be "lime.array10" or "lime.multiplenum"

Then there's the SQL schema problem. I think there should be an API call to the question plugin to declare what MySQL data types it needs:
- colname
- coltype
- optional description
- storage type (SQL or file; could be merged with coltype; if coltype=="FILE", then it's file based)
- optional function pointer for formatting (printing) output, for example printing floating point numbers
- optional formatting function parameters
The function (specified by function pointer) is then called by the lime core with all of the above parameters and returns a printable output from SQL / file. It could also be a picture (PNG/JPG or HTML to be inserted into innerhtml placeholder).

When developing question types, there should also be an option to (easily) change the custom question type SQL schema (and delete the file storage).

The colname is prefixed in the SQL DB, but the API should be able to work with both full and short colnames. (the prefix should be available to the question type, if it needs to directly update the SQL DB, not via the built-in APIs).

Consider also file based storage. All you need is to create a directory and a generate a token based file name. Pretty much the same APIs could be used as with the SQL storage, only optional parameter "$storagetype='FILE'" would have to be specified, when creating SQL schema. Reading and writing to a LONGBLOB/TEXT and a file should be practically the same. If the respondent uploads a file, it is better to be saved to a filesystem than into an SQL blob.

That's pretty much it. I'll be happy to test the alpha builds.

Best regards,
Marsip
Last Edit: 3 years 2 months ago by Marsip. Reason: typo
The administrator has disabled public write access.
The following user(s) said Thank You: actxcellence

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93382

  • Mazi
  • Mazi's Avatar
  • Online
  • LimeSurvey Team
  • Posts: 5966
  • Thank you received: 364
  • Karma: 259
1. I think all statistics related wishes will not be added before Limesurvey 2.1 and the re-coding of the question types?

2. For public statistics it might be very useful to be able to compare the user's answers with the aggregated data.

3. Can we have something like "beforeSurveyStart" which could e. g. be used to have some kind of login system in addition to using tokens to restrict access to a survey?

Best regards/Beste Grüße,
Dr. Marcel Minke
(Limesurvey Head of Support)
Need Help? We offer professional Limesurvey support
Contact: marcel.minke(at)limesurvey.org'"
The administrator has disabled public write access.
The following user(s) said Thank You: lfanfoni

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93398

  • DenisChenu
  • DenisChenu's Avatar
  • Offline
  • Moderator Lime
  • Posts: 8954
  • Thank you received: 1258
  • Karma: 371
Think we can have some Core Stats but less than actually.
  1. beforeSurveyStart is the 1st TODO i think, and (before|after)SurveySubmitted too
  2. export: maybe move SPSS and R export to Plugin, after we can have TripleS plugin (i work on a specific actually : restrict to selected column ;) ).
  3. need to beforeCreateFieldMap and afterCreateFieldMap (for example to update group/question order: move )
  4. (before|after)surveyRigth

Like Mazi say, move all question into Plugin and attribute into Plugin excpet some Base.

Thinking for Question:
Maybe the actual Questions->type can be use for DB, then same subroutine Stat/export.

type Text: answered/ansered or not , maybe to a DISTINCT count (for example Equation can be text question for stats)
type single: linked with answer (even with Gender etc ...)
type discrete: 1/0/NULL
type json: "very specific" : file upload actually

And add the type 'combine' for all array, single + comment/multi/multi text etc ....

Denis
PS: afterv reading other user:
Needed:
beforeEnterSurvey : token generation/survey logon/prefill (helper 2+4+6 )
afterSurveySubmitted: encrypted functionnality (tfj)
questionPlugin: directly encrypted functionnality (tfj)

For Marsip: look and add function to remotecontrol : it's done for this.
Last Edit: 3 years 2 months ago by DenisChenu. Reason: PS
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93537

I think the first method should be "onLogin", and maybe another method to "login" which receive the username/password and it permit access to the limesurvey, it could help to integration with another systems.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #93800

  • sys_sby
  • sys_sby's Avatar
  • Offline
  • Junior Lime
  • Posts: 26
  • Karma: 0
I think this is plugin (feature) can be consider:
1. Point Rewards and history participants
2. Participants portal, it is contain feature: survey list,survey applied, Point Rewards,Personal Participant data, FAQ
3. Setting permission Report based on hierarchy user level (Parent-children report structure)
4. Custom aggregate and comparison in Reporting (i.e: comparing aggregate City A VS City B, comparing aggregate Survey A VS Survey B)

Thank you very much

Regards
Sys_sby
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 2 months ago #94036

  • sys_sby
  • sys_sby's Avatar
  • Offline
  • Junior Lime
  • Posts: 26
  • Karma: 0
I think this plug in (feature) also can be consider:
1. Apply and approval survey for participant
2. Feedback and comment for participant survey filled ( I think in question page)
3. Custom grouping questions for assessment report and report display (it also for calculation)

Thank you very much

Regards
Sys_sby
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 3 years 1 month ago #94740

  • trougakoss
  • trougakoss's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 1
  • Karma: 0
We are very excited to hear about the new plans for the plugin API.
There are many ideas that come in mind, but we would like to make a comment on the proposed encryption of the results of a survey (by tfj)

afterSurveySubmitted: encrypted functionnality (tfj)
questionPlugin: directly encrypted functionnality (tfj)


It seems quite useful and especially for a number of limesurvey implementations, where sensitive information might be stored.
Bearing in mind that the limesurvey application can be used as a voting system, we would like to propose the multiple (serial) key encryption of the responses, than just a single key encryption.
That would ensure the maximum security of the results and make the decryption proccess possible only when all involved parties can provide their private keys.


Thank you very much

Regards
Spiros Trougakos
NKUA (National Kapodistrian Univeristy of Athens)
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 2 years 11 months ago #96895

  • actxcellence
  • actxcellence's Avatar
  • Offline
  • Premium Lime
  • Posts: 42
  • Thank you received: 7
  • Karma: 0
In a number of project, customers asked me to use the multi-language email option for other e-Mail during the survey open period.

e.g.
to excuse about some minor glitch in the invitation,
to remind and say thank you to all without filtering the participants who already answered

this is not a hook thing, but an idea for a e-mail plugin:

Send email to all tokens with this filter (filter in any column of the token table)
Schon die Bedienungsanleitung von LimeSurvey angeschaut?
Bedienungsanleitung (DE) | Tricks, um mehr Antworten auf Fragen im Forum zu erhalten
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 2 years 10 months ago #98250

  • jlwood
  • jlwood's Avatar
Has there been any movement on the idea of an encrypted field type? We're implementing Limesurvey in a University setting and this would solve a number of IRB headaches. I'm a mediocre php programmer but willing to try my hand at this as time allows.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 2 years 8 months ago #99860

  • sammousa
  • sammousa's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 10
  • Thank you received: 3
  • Karma: 2
Hey guys,

Thanks for the ideas on encryption. Below I'll try to go into some concerns on encrypting data.
When applying encryption there are several attack surfaces that need to be considered:
- Database layer
- Application layer

When using symmetric encryption, encrypting data in the database only protects us from attacks on the database layer. Any attack gaining access to Limesurvey will also gain access to the key(s) used.

When using asymmetrical encryption we are able to make data secure from being read by the application itself, thus rendering any attacks on the application layer useless.

Since the database layer can, in most cases, be protected by simply denying all outside access I feel (symmetrically) encrypting the data inside the database is not the most efficient way to increase data security.

That said, applying some kind of asymmetrical encryption is definitely an interesting idea. It does have some downsides though:
- Limesurvey will not have access to the stored data, breaking any kind of dynamic texts and conditions for surveys that are not finished in one go. (ie. that have their data written and read from the database between start and finish, for example when resuming from a token link).
- If we don't want the data to be stored (unencrypted) in memory a lot of changes are required to the core to ensure that data is encrypted as soon as possible after receiving it.

In 2.10 we will introduce question plugins, these are question plugins will allow third party developers to create question types and will definitely allow you to add both symmetrical and asymmetrical encryption to individual questions.

For 2.05 there are several features that might aid you in developing a solution that is secure enough (in security nothing is ever really secure, it is secure enough or not secure enough).

- use the afterSurveyCompleted event to get the data, encrypt it and store / send it. When using the default plugin getters and setters this won't be the most efficient approach when exporting big data sets later, but it will work and be secure.
- if you want us to we can add a function to the plugin api to allow you to delete responses, your plugin could then delete the response after having encrypted and stored it.

Thanks again for the feedback, and keep the suggestions coming!

(disclaimer: While being part of the team, the opinions stated are my own and don't necessarily reflect the opinion of the Limesurvey development team as a whole.)
Last Edit: 2 years 8 months ago by sammousa.
The administrator has disabled public write access.

Your feedback: Plugins for LimeSurvey 2.05 2 years 5 months ago #102331

  • Spydre13
  • Spydre13's Avatar
  • Offline
  • Fresh Lemon
  • Posts: 7
  • Karma: 0
helper,

I just came across this post from a while back about custom hooks. I am trying to integrate limesurvey with a medical application, and I'm very interested in your #3 and #4 hooks. We had been using the newtoken.php for limesurvey <2.0 but it's not as secure as we would like. Are these hooks something you could share with myself and the community, or is it something you need to keep private?

I'm specifically trying to pass users into a survey in a secure method, without the possibility of users viewing their browser history and getting back into a previous survey. Also some data in the survey is sensitive, so it can't be visible on the URL in the browser history.

Any insight from you or anyone else on this site would be greatly appreciated.

Thanks,
Nate
helper wrote:
From my perspective (learning hospital/university), the objectivity of an API would be to provide hooks to other API's (for example, advanced web services). These could include interfaces with print services and/or electronic medical records (like Epic).

My current homegrown hooks:
  1. Output report customization for PDF/print and BLOB preparation for mainframe DB2.
  2. Output report writes to mainframe DB2
  3. Survey logon based on a medical record number and year of birth instead of token, username/password.
  4. Automatic token generation when a patient logs on.
  5. Appointment lookup (via web service to our appointment systems)
  6. Token population from patient registry flags (for example, diabetes, hypertension, etc.)
The administrator has disabled public write access.
Time to create page: 2.032 seconds