Think a plugin can use LimeExpressionManager::updateReplacementFields('seed'=>$seed) for this.
Need to have the good time to get it. Maybe a new event.

This one can not be used : https://github.com/LimeSurvey/LimeSurvey/pull/1256 since it's done opnly when survey is started (but no database update (? unsure)

PS : i think all database data can be accesssible via Expression Manager.

What's the use-case?

@ollehar, in our case we wanted to pass the user's seed value into a GET parameter when calling an external reporting script. Just to make sure users can call the report with another ID by simply changing from e.g. 11 (their ID) to 10 (the previous user). So we wanted to check ID and seed value.

For

PS : i think all database data can be accesssible via Expression Manager.

Because plugin can hack DB columns and add anything ;) (no idea, but can be potentially great)

One place holder really needed : SUBMITDATE : then can check if survey is submitted or not (with token <-> response table or in some plugins).

+1 for submitdate placeholder

STARTDATE and DATESTAMP can be interesting too : for example : condition on lastpage
date("Y-m-d H:i:s") > STARTDATE + 10 minutes with tip "You don't read enough on this survey"

Maybe with SURVEY:XXX for all non related to question survey DB column :)

@Mazi : if it work with core plugin ( in core/plugins or .plugin unsure) : are you OK ?

Think of

1. Activate plugin
2. Check list with (global)
   1. Add all DB column Y/N (not related to question (ie: not starting with sid)
   2. If no if checked : Add SEED Y/N
   3. Add STARTDATE Y/N
   4. Add DATESTAMP (if exist)
3. Check list by survey where all existing data column can be checked/unchecked/leave default (i really like the 3 options here : Y/N/«inherit»
4. Maybe add a SurveyGroups settings (for plugin inheritance)

@ollehar : it's a next feature, right, even if adding SEED or STARTDATE or … is really easy : we can't get it in master, right ?
If we add it by plugins (deactuvated by default) it don't broke existing survey with Question code as SEED or STARTDATE or …

@DenisChenu, while I like the idea of separating code by creating plugins, I consider supporting additional EM placeholders a core feature so it makes more sense adding this to the upcoming LS 4 version.
I think there is no need to add an additional list/feature for enabling certain placeholders. We can just support them out of the box as we do with {SID} or {SAVEDID}.

If you support it out of the box : you broke some of my surveys where i add a STARTDATE question : then NO it can not be forced ! (and potential usage of SEED question code)
(and if you support it out of the box : i don't take it even for 4.0)

If it's i core : it must be in ExpressionManager reserved word

@DenisChenu, I didn't know that the discussed placeholders are not a reserved EM word yet. Of course, it has to be added there first. Since e.g. underscores are not allowed at questions code, why don't we used such placeholders like {START_DATE}, {SEED_VALUE} and the like?
That should work fine and all we need is documenting everything properly.

START_DATA : question START, subquestion DATE …

But the important things : if it's in core : i don't take it even for 4.0 (but maybe make my own plugin before it come in ls core)

2nd important things : STARTDATE : easy (for dev), START_DATE (or anything else) need a function for correspondance

" if it's in core : i don't take it even for 4.0 (but maybe make my own plugin"
Why?

Because i'm not OK to adding it in core if a plugin solution is available [*], and because adding it in core can broke some survey.

* : because in my situation : have a plugin is the only way to have stable solution when i need stable solution. No bug not resolved during month and month …

@Mazi :

in our case we wanted to pass the user's seed value into a GET parameter when calling an external reporting script. Just to make sure users can call the report with another ID by simply changing from e.g. 11 (their ID) to 10 (the previous user). So we wanted to check ID and seed value.

I want to play (no client on this one) : https://gitlab.com/SondagesPro/QuestionSettingsType/generateUniqId

A plugin for LimeSurvey to generate an unique id for usage in survey.

Then you can have your solution :)

Hi Denis, our workaround due to the missing placeholder is indeed to populate an equation question using rand() and then using that value as an additional parameter.
But since "seed" does something very similar, just supporting the placeholder will do the trick.

Warning : with SAVEDID, when deactivate, reactivate : id of response are updated :)

@Mazi : https://github.com/LimeSurvey/LimeSurvey/pull/1256/commits/ddd4a65fb13951d1033064fa91e024fc7e500586
Sample plugin for start

Thanks, Denis!

https://github.com/LimeSurvey/LimeSurvey/commit/011890d128084176074421cbe82cdd342706f729#diff-bccf0f511c5328f1ef2c78b92305646a