About GUI : i ask it to @jelo , i really don't have idea on how it work for Survey manager .

About column name : 'completed'

Tammo "only" wants to ensure that LimeSurvey marks a completed survey, even tough the respondent hasn't hit the submit button on the last page.

If we want to just solve that issue, which many of us have experienced, the most direct solution would be to allow every question type to set a termination code in the advanced settings.

Better seems to be to place that in a separate question type (make more questionstypes with less options instead of less question types with more options). The equation questiontype might be not overloaded with options.

If you place the termination/complete question in a question group (BTW: Wasn't LS5 using page instead of group in the GUI. When was that reverted?), the survey response get's the completion code of that termination/complete question.

The advanced version of that termination/completion question type would contain endpage text and would allow to redirect to a different URL. The question type could be used to only mark complete status and to mark complete status and allow showing an endpage or a autourl redirection.

That way you could save a lot of time, when you have different respondent groups in your survey which only have to fill out parts of the survey, but should not be screened out via the quota workaround.

Sometimes you see surveytools using not "complete", but qualified/disqualified status codes in the response set. E.g. if a part of the survey is rushed (timer), the coding will set the responseset to disqualified even though the responseset is completed.

If we consider the equation question as a way to start and don't want to invest time in GUI work, wouldn't be the first stept to have ExpressionScript functions which allow to set the complete status. Wouldn't that be the minimal project, which still is huge.

In a nutshell: Place a equation question in a question group which is considered as an end of the survey. The ExpressionScript function to set the status of the survey to complete is used in the equation question. The big unknown is, how the core functions will react and what routines this new ExpressionScript function has to trigger to really end the survey. It doesn't look like an low hanging fruit.




an status field (perhaps an additional field, till we can be sure it has no negative impact on the basic functions) to qualified/disqualified

> In a nutshell: Place a equation question in a question group

Alternative :
Place a short text hidden question in 1st group (qualified)
Place some equation to set qualified according to expression

I agree, my primary issue is how to set a survey to completed == "Y" even though the last groep/page has not yet been reached.

I started the discussion here to see if difficult roadblocks and/or additional ideas come up.

Whenever a new feature arises, we, as developers of surveys and software can imagine possibilities and can define many more additional features.

Making it possible to use the Expression Script so set {completed = "Y"} at a specific point would be great, but the implications may be unforeseen. Like: when completed = "Y" would it also be necessary to fill in a completion date?

Or are there more completion statusses necessary? Like submitted01, submitted02 ... submittedn

Or maybe an extra column: "status" where the developer can set arbitrary (self defined) statusses which can be used when filtering. "submitted" can be a "reserved status", only to be used by the core software. Maybe the column should be able to hold more statusses, like: ["submitted01", "submitted"]

For me this is brainstorming online; let's see if we can define a sweet spot which:
1 holds useful functionality
2 for which the development time/effort is overseeable
3 which can be explained to users (= survey developers)

You will than have to sum it all up and submit a feature request. Save your time and submit a feature request now. The concept of submitting bug and feature tickets late is not sustainable. The forum posts get wiped out over time. The forum helps raising interest for a ticket and help matching people. But opening a ticket early helps to find GUI/understanding issues too. Without tickets which gets closed directly because of an misunderstanding, no signal reaches the development team. It gets all covered by forum support and the root cause stays there forever.

@jelo: I thought of that too. But when I start a discussion here, I think I attract more "users" and I would like to add a feature request when I have enough views of users.

When I, based just on my own needs, add a feature request, I become part of a developers discussion, not of a users discussion. Users talk about the usage implications, developers talk about the technical implications. I think there is a slight difference between those two.

more "users" == tammo + jelo + me ?

One can always hope...

The missing vision/plan about LimeSurvey is the problem. The expectations of most stakeholders are unclear to me.

Without a vision about what kind of surveycreators LimeSurvey should please and help, you cannot neglect feature request upfront nor consider what are the most important feature requests to implement over the next two years. You end up with a flood of ideas and issues.

I would guess you will find only a few forumposts and bugtrackertickets with more than ten different people providing opinions and ideas.
You have many posts of 2-3 users with the same issue, which never reached the bugtracker and will get deleted in a few years.

The bugtracker/issue database is the repository with the highest chance of surviving anything and currently the only systematic approach against defragmentation of issues and ideas.