[limesurvey-developers] Greetings from a former dev and new plugin

[Thibault Le Meur]

Hi guys,

As an old core member I'd like to congratulate the whole team for the
excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even easier to
extend thanks to the plugin/event system.

I know that I code like a sysadmin, but as I needed new features on survey
notifications I got back to my best IDE (vim).
The result is a new plugin named ConfirmByEmail with the following features:
* multiple email templates for each survey (not limited to the
participant's notification, the basic and detailed admin notification from
the core feature)
* destination email addresses can be taken from the response (usable for
open-surveys with no auto-registration or no allow-save enabled)
* destination email addresses are EM expressions and thus can depend on the
participant's answers (this enables email routing based on the response)
* if the destination email addresses list (semi-column separated list)
contains no valid email address, no email is sent. This makes it possible
to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions. As it is
setup using an EM expression, conditions are supported to select which file
to upload or not.

You can review it here:
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail

The code needs a bit more polishing and testing, but I'd like to share it
with you.

All inputs are welcome to help improve it.

Regards,
Thibault

[Sam Mousa]

Hi Thibault,

I've quickly looked at your plugin code and saw that it is using some
global functions.
If you want to have an easy (and documented) migration path to newer
versions of LS, please limit yourself to using the plugin API object.
If you miss some features there request them and we can easily add them!

Cheers,

Post by Thibault Le Meur
Hi guys,
As an old core member I'd like to congratulate the whole team for the
excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even easier
to extend thanks to the plugin/event system.
I know that I code like a sysadmin, but as I needed new features on survey
notifications I got back to my best IDE (vim).
* multiple email templates for each survey (not limited to the
participant's notification, the basic and detailed admin notification from
the core feature)
* destination email addresses can be taken from the response (usable for
open-surveys with no auto-registration or no allow-save enabled)
* destination email addresses are EM expressions and thus can depend on
the participant's answers (this enables email routing based on the response)
* if the destination email addresses list (semi-column separated list)
contains no valid email address, no email is sent. This makes it possible
to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions. As it is
setup using an EM expression, conditions are supported to select which file
to upload or not.
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail
The code needs a bit more polishing and testing, but I'd like to share it
with you.
All inputs are welcome to help improve it.
Regards,
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[TLM Gmail]

Hi Sam,

You're right I've tried to avoid changes in LS core for now, but found
features missing in the LimeSurveyApi (or maybe I don't see how to use
them) so I had to use global functions.

I've done a quick review of the functions I'm using outside of the LSApi:

* common_helpers functions such as "validateEmailAddress",
"getSurveyInfo", "getFullResponseTable", "SendEmailMessage"
==> Is it safe to use them, or should they be exposed through LSApi ?

* Survey::model()->findByPk($surveyId)->active
==> I guess that a getSurveyStatus($surveyId) would be great [returning
isActive, hasTokenTable). Or, maybe the event could contain a little
more info than just the surveyId

* I'm using \LimeExpressionManager::ProcessString() accepts an
interresting third parameter that isn't available in
this->pluginManager->getAPI()->EMevaluateExpression()
==> EMevaluateExpression() could be easily updated to have this third param

* Maybe add a EMevaluateQuestionRelevance($sgqa), returning
\LimeExpressionManager::QuestionIsRelevant($sgqa)

What do you think ?

Thibault

Post by Sam Mousa
Hi Thibault,
I've quickly looked at your plugin code and saw that it is using some
global functions.
If you want to have an easy (and documented) migration path to newer
versions of LS, please limit yourself to using the plugin API object.
If you miss some features there request them and we can easily add them!
Cheers,
Hi guys,
As an old core member I'd like to congratulate the whole team for
the excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even
easier to extend thanks to the plugin/event system.
I know that I code like a sysadmin, but as I needed new features
on survey notifications I got back to my best IDE (vim).
* multiple email templates for each survey (not limited to the
participant's notification, the basic and detailed admin
notification from the core feature)
* destination email addresses can be taken from the response
(usable for open-surveys with no auto-registration or no
allow-save enabled)
* destination email addresses are EM expressions and thus can
depend on the participant's answers (this enables email routing
based on the response)
* if the destination email addresses list (semi-column separated
list) contains no valid email address, no email is sent. This
makes it possible to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions.
As it is setup using an EM expression, conditions are supported to
select which file to upload or not.
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail
The code needs a bit more polishing and testing, but I'd like to
share it with you.
All inputs are welcome to help improve it.
Regards,
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Sam Mousa]

Hi Thibault,

All global functions are off limits, also directly using classes other than
the api class will cause breakage in the future.
So we might need to add some / lots of wrappers.

Cheers

Post by TLM Gmail
Hi Sam,
You're right I've tried to avoid changes in LS core for now, but found
features missing in the LimeSurveyApi (or maybe I don't see how to use
them) so I had to use global functions.
* common_helpers functions such as "validateEmailAddress",
"getSurveyInfo", "getFullResponseTable", "SendEmailMessage"
==> Is it safe to use them, or should they be exposed through LSApi ?
* Survey::model()->findByPk($surveyId)->active
==> I guess that a getSurveyStatus($surveyId) would be great [returning
isActive, hasTokenTable). Or, maybe the event could contain a little more
info than just the surveyId
* I'm using \LimeExpressionManager::ProcessString() accepts an
interresting third parameter that isn't available in
this->pluginManager->getAPI()->EMevaluateExpression()
==> EMevaluateExpression() could be easily updated to have this third param
* Maybe add a EMevaluateQuestionRelevance($sgqa), returning
\LimeExpressionManager::QuestionIsRelevant($sgqa)
What do you think ?
Thibault
Hi Thibault,
I've quickly looked at your plugin code and saw that it is using some
global functions.
If you want to have an easy (and documented) migration path to newer
versions of LS, please limit yourself to using the plugin API object.
If you miss some features there request them and we can easily add them!
Cheers,

Post by Thibault Le Meur
Hi guys,
As an old core member I'd like to congratulate the whole team for the
excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even easier
to extend thanks to the plugin/event system.
I know that I code like a sysadmin, but as I needed new features on
survey notifications I got back to my best IDE (vim).
* multiple email templates for each survey (not limited to the
participant's notification, the basic and detailed admin notification from
the core feature)
* destination email addresses can be taken from the response (usable for
open-surveys with no auto-registration or no allow-save enabled)
* destination email addresses are EM expressions and thus can depend on
the participant's answers (this enables email routing based on the response)
* if the destination email addresses list (semi-column separated list)
contains no valid email address, no email is sent. This makes it possible
to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions. As it
is setup using an EM expression, conditions are supported to select which
file to upload or not.
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail
The code needs a bit more polishing and testing, but I'd like to share it
with you.
All inputs are welcome to help improve it.
Regards,
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

------------------------------------------------------------------------------
_______________________________________________
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Thibault Le Meur]

Hi Sam,

Thanks for your answer. Indeed this means we need to add a lot to the LSApi !

How do you want to proceed in order to define this LSApi ?
If LSApi methods are developed on demand (waiting for feature requests) it will become an incoherent list of methods which may become redundant with future ones.

Basically, as plugins may need to add feature to any part of LS, they can do almost everything. Thus I feel like LSApi will end up exposing every class public methods to LSApi.

So, to my understanding (but again I'm not a software designer), the added value of an LSApi would be:
- to add an independence layer encapsulating internal public Class methods inside a stable API so that this API is not affected by internal class changes,
- to be able to add a Plugin permission monitor (maybe associating a Plugin with a specific LS user account for whom user permissions could be tailored) to improve security

Am I right ?

A last question, how and when (LS release ?) do you intend to prevent Plugins from accessing global functions as well as direct class calls ? Is such code already available in a branch ?

Thanks in advance,
Thibault

Envoyé de mon iPad

Post by Sam Mousa
Hi Thibault,
All global functions are off limits, also directly using classes other than the api class will cause breakage in the future.
So we might need to add some / lots of wrappers.
Cheers

Post by TLM Gmail
Hi Sam,
You're right I've tried to avoid changes in LS core for now, but found features missing in the LimeSurveyApi (or maybe I don't see how to use them) so I had to use global functions.
* common_helpers functions such as "validateEmailAddress", "getSurveyInfo", "getFullResponseTable", "SendEmailMessage"
==> Is it safe to use them, or should they be exposed through LSApi ?
* Survey::model()->findByPk($surveyId)->active
==> I guess that a getSurveyStatus($surveyId) would be great [returning isActive, hasTokenTable). Or, maybe the event could contain a little more info than just the surveyId
* I'm using \LimeExpressionManager::ProcessString() accepts an interresting third parameter that isn't available in this->pluginManager->getAPI()->EMevaluateExpression()
==> EMevaluateExpression() could be easily updated to have this third param
* Maybe add a EMevaluateQuestionRelevance($sgqa), returning
\LimeExpressionManager::QuestionIsRelevant($sgqa)
What do you think ?
Thibault

Post by Sam Mousa
Hi Thibault,
I've quickly looked at your plugin code and saw that it is using some global functions.
If you want to have an easy (and documented) migration path to newer versions of LS, please limit yourself to using the plugin API object.
If you miss some features there request them and we can easily add them!
Cheers,

Post by Thibault Le Meur
Hi guys,
As an old core member I'd like to congratulate the whole team for the excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even easier to extend thanks to the plugin/event system.
I know that I code like a sysadmin, but as I needed new features on survey notifications I got back to my best IDE (vim).
* multiple email templates for each survey (not limited to the participant's notification, the basic and detailed admin notification from the core feature)
* destination email addresses can be taken from the response (usable for open-surveys with no auto-registration or no allow-save enabled)
* destination email addresses are EM expressions and thus can depend on the participant's answers (this enables email routing based on the response)
* if the destination email addresses list (semi-column separated list) contains no valid email address, no email is sent. This makes it possible to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions. As it is setup using an EM expression, conditions are supported to select which file to upload or not.
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail
The code needs a bit more polishing and testing, but I'd like to share it with you.
All inputs are welcome to help improve it.
Regards,
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Thibault Le Meur]

Hi Denis,

At first I just needed a way to notify a participant whose email address
would be taken from the response and with a customizable template.

Then I figured out that it would be great to use it for 'admin'
notifications with the added rooting feature (the destination addresses
depend on the participant's answer).

From this came the idea that someone would soon or later ask for the

possibility to send multiple different emails, so I added multiple email
support and multilingual support.

Then I found out that ANSWERTABLE wasn't returning uploaded files, which is
ok for simple confirmation emails but could be a pb if you want to use the
'routing' feature to push some uploaded files to some admins and others to
some other admins.

So basically, this is it: I only needed the features from first phrase and
turned out to implement far more because I prefer to do this now.

I've also implemented a way to sign messages with s/mime but hasn't
published it because it requires hacks to the core LS code (and maybe to
phpMailer) and my goal here was to implement a feature without touching the
core code.

As far as the Manual is concerned me I say this, but was waiting for core
dev feedback before publishing it officially :-)

I've seen that you've developed several plugins yourself and I'm interested
to know if you've managed to stick to the LimeSurveyApi or if you've been
forced to use global functions and direct core classes calls.

Regards,
Thibault

Le 30 déc. 2015 à 18:15, Denis Chenu <***@shnoulle.net> a écrit :

Hi Thibault,

This plugin can replace core "admin" email , right ? A question :; why
doid you need such developpement ?
For the "uploaded" files ? Or for X emails ?

Great to have some news from you :).

There are a "manual" place to put plugins :
https://manual.limesurvey.org/Available_third_party_plugins .

Denis

[Sam Mousa]

Hi Thibault,

The goal of the API object is indeed mainly to provide 1 (possibly)
abstract entry point for plugins.
That way we can guarantee compatibility.
Currently the code base of 2.x is a mess with most code not following best
practices of the last decade.
If you use things like global functions (which other than very few specific
valid use cases should not be used in general), we have to choose between
breaking your plugin, or keeping the bad code in our repository.
For LS3 I have refactored most of the global functions into static helper
classes as a sort of stop-gap / quick fix.

In the future I would like to implement API versioning as well, where the
API object being passed into your plugin has a version and you can choose
which one to use. This would allow us to upgrade the API without breaking
plugins that depend on a specific API version.

-- Statements in this mail reflect my personal opinion, they may not be
shared by the rest of the team.

So in conclusion yes we will need to add lots of stuff to the plugin API
and I would like to do this organically. I feel it should be possible to
create a structured API if we think about adding stuff.

Hope that helps,

Cheers!

Post by Thibault Le Meur
Hi Denis,
At first I just needed a way to notify a participant whose email address
would be taken from the response and with a customizable template.
Then I figured out that it would be great to use it for 'admin'
notifications with the added rooting feature (the destination addresses
depend on the participant's answer).
From this came the idea that someone would soon or later ask for the
possibility to send multiple different emails, so I added multiple email
support and multilingual support.
Then I found out that ANSWERTABLE wasn't returning uploaded files, which
is ok for simple confirmation emails but could be a pb if you want to use
the 'routing' feature to push some uploaded files to some admins and others
to some other admins.
So basically, this is it: I only needed the features from first phrase and
turned out to implement far more because I prefer to do this now.
I've also implemented a way to sign messages with s/mime but hasn't
published it because it requires hacks to the core LS code (and maybe to
phpMailer) and my goal here was to implement a feature without touching the
core code.
As far as the Manual is concerned me I say this, but was waiting for core
dev feedback before publishing it officially :-)
I've seen that you've developed several plugins yourself and I'm
interested to know if you've managed to stick to the LimeSurveyApi or if
you've been forced to use global functions and direct core classes calls.
Regards,
Thibault
Hi Thibault,
This plugin can replace core "admin" email , right ? A question :; why
doid you need such developpement ?
For the "uploaded" files ? Or for X emails ?
Great to have some news from you :).
https://manual.limesurvey.org/Available_third_party_plugins .
Denis
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

[Denis Chenu]

Hi,

Post by Thibault Le Meur
At first I just needed a way to notify a participant whose email
address would be taken from the response and with a customizable template.

We really need a better manual too then : this can be done in core ;).

https://manual.limesurvey.org/Survey_settings#Notification_.26_data_management

Denis

------------------------------------------------------------------------------

[Denis Chenu]

Hi Thibault,

This plugin can replace core "admin" email , right ? A question :; why
doid you need such developpement ?
For the "uploaded" files ? Or for X emails ?

Great to have some news from you :).

There are a "manual" place to put plugins :
https://manual.limesurvey.org/Available_third_party_plugins .

Denis

Post by Thibault Le Meur
Hi guys,
As an old core member I'd like to congratulate the whole team for the
excellent work on the 2.x branch.
Not only has it become more stable, more powerful, but it is even
easier to extend thanks to the plugin/event system.
I know that I code like a sysadmin, but as I needed new features on
survey notifications I got back to my best IDE (vim).
* multiple email templates for each survey (not limited to the
participant's notification, the basic and detailed admin notification
from the core feature)
* destination email addresses can be taken from the response (usable
for open-surveys with no auto-registration or no allow-save enabled)
* destination email addresses are EM expressions and thus can depend
on the participant's answers (this enables email routing based on the
response)
* if the destination email addresses list (semi-column separated list)
contains no valid email address, no email is sent. This makes it
possible to add relevance conditions to confirmation emails.
* it is possible to attach some files from file-upload questions. As
it is setup using an EM expression, conditions are supported to select
which file to upload or not.
https://github.com/lemeur/Limesurvey-Plugin-ConfirmByEmail
The code needs a bit more polishing and testing, but I'd like to share
it with you.
All inputs are welcome to help improve it.
Regards,
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers

------------------------------------------------------------------------------

[Thibault Le Meur]

Post by Denis Chenu
Hi,

Post by Thibault Le Meur
At first I just needed a way to notify a participant whose email
address would be taken from the response and with a customizable template.

We really need a better manual too then : this can be done in core ;).

Nope It just means I need better glasses ;-)
However I think the file upload as attachment and multiple templates might prove to be useful in the future so I don't regret the development time: maybe one day these features will be part of LS core.

Thibault



------------------------------------------------------------------------------

[Thibault Le Meur]

Hi Sam,

Post by Sam Mousa
The goal of the API object is indeed mainly to provide 1 (possibly)
abstract entry point for plugins.
That way we can guarantee compatibility.

Ok that makes sense.

Post by Sam Mousa
Currently the code base of 2.x is a mess with most code not following best
practices of the last decade.
If you use things like global functions (which other than very few specific
valid use cases should not be used in general), we have to choose between
breaking your plugin, or keeping the bad code in our repository.

There is no choice here: breaking the plugin is the only way.

Post by Sam Mousa
For LS3 I have refactored most of the global functions into static helper
classes as a sort of stop-gap / quick fix.

Ok.

Post by Sam Mousa
In the future I would like to implement API versioning as well, where the
API object being passed into your plugin has a version and you can choose
which one to use. This would allow us to upgrade the API without breaking
plugins that depend on a specific API version.

That would be fantastic.

Post by Sam Mousa
-- Statements in this mail reflect my personal opinion, they may not be
shared by the rest of the team.

These statements seem perfect, I don't think see someone in the team would argue against them ;-)

Post by Sam Mousa
So in conclusion yes we will need to add lots of stuff to the plugin API
and I would like to do this organically. I feel it should be possible to
create a structured API if we think about adding stuff.

Okay so to sum things up:
1- Plugin devs should fill in feature requests into LSApi tickets describing why they need a new API method, and what it would do in their opinion
* In a perfect world they could propose a proof-of-concept implementation for the new call in a method
2- The team would take care of integrating them into a structured Api

=> Is this the proposed process ? (sounds ok to me)

Thibault






------------------------------------------------------------------------------

[Sam Mousa]

Yes :)

On Thu, Dec 31, 2015 at 3:06 PM, Thibault Le Meur <

Post by TLM Gmail
Hi Sam,

Post by Sam Mousa
The goal of the API object is indeed mainly to provide 1 (possibly)
abstract entry point for plugins.
That way we can guarantee compatibility.

Ok that makes sense.

Post by Sam Mousa
Currently the code base of 2.x is a mess with most code not following

best

Post by Sam Mousa
practices of the last decade.
If you use things like global functions (which other than very few

specific

Post by Sam Mousa
valid use cases should not be used in general), we have to choose between
breaking your plugin, or keeping the bad code in our repository.

There is no choice here: breaking the plugin is the only way.

Post by Sam Mousa
For LS3 I have refactored most of the global functions into static helper
classes as a sort of stop-gap / quick fix.

Ok.

Post by Sam Mousa
In the future I would like to implement API versioning as well, where the
API object being passed into your plugin has a version and you can choose
which one to use. This would allow us to upgrade the API without breaking
plugins that depend on a specific API version.

That would be fantastic.

Post by Sam Mousa
-- Statements in this mail reflect my personal opinion, they may not be
shared by the rest of the team.

These statements seem perfect, I don't think see someone in the team would
argue against them ;-)

Post by Sam Mousa
So in conclusion yes we will need to add lots of stuff to the plugin API
and I would like to do this organically. I feel it should be possible to
create a structured API if we think about adding stuff.

1- Plugin devs should fill in feature requests into LSApi tickets
describing why they need a new API method, and what it would do in their
opinion
* In a perfect world they could propose a proof-of-concept
implementation for the new call in a method
2- The team would take care of integrating them into a structured Api
=> Is this the proposed process ? (sounds ok to me)
Thibault
------------------------------------------------------------------------------
_______________________________________________
limesurvey-developers mailing list
https://lists.sourceforge.net/lists/listinfo/limesurvey-developers