Macasek, Michael A. a écrit :
I suppose we will have to design the authorization system so that it
will be possible to give permissions to read/write these questions
***Yes the user model has to be built out quite a bit and it will
provide for this type of permissions.
Ok so page_sections are an extension view of our former question_groups
with more flexibility in their reuse/inclusion and their use in survey
**While it is potentially possible for survey sections to be reused in
other surveys the code does not allow for this at this time. It is
something we hope to include in the future.
Yes thanks this is cristal clear.
Ok so this is the replacement of our old template system: it seems
Does "One cannot modify the layout components through the
template_params" imply that layout components must be customized by
modifying the "templates"object directly ?
***The layout components refer to parts of the question layout that do
not directly relate to one of the question_secions. For example in a
matrix question the table html tag is purely there for layout,
currently there is no way to use the template_params that are
associated with one of the question_sections to add a class to the
table html tag. Template_params are only capable of modifying the html
directly related to the question_section they are associated with (e.g.
you can add a class to an input html tag). While we understand why it
would be desirable to be able to add a class to the table html tag the
additionally complexity that would be added to the code/template_params
system is not something we wanted to get into at this point. For now it
is possible to overcome this by adding a class template_param to the
question object that will add the class the html tag that wraps the
question. You can then use CSS selectors such as
".classname_on_question_wrapper table" to style to table. Does that
help/answer your question?
Ok, I understand now that your goal is to be able to keep track of
several responses-set for a given user: old ones are "Inactive Progress
"However only one of those progresses can be marked as not completed.":
I would have said the opposite!
If I understand well, we record a user's answers on the fly in a
progress object which memories the session status. The user may abort
(willingly or not the session). He could get back later but as soon as
he submits a full session (a progress object), he shouldn't be able to
try again. thus I would have said "Only one progress can be marked as
*****There is only ever at most one active progress for a given user on
a given survey. The term Active Progress means that the user has not
yet completed taking the survey. It is possible for a user to have
taken and completed a survey previously, in this case there would be
completed progresses for that user on that survey. If an Active
Progress exists for a user on survey it is an indication that the user
has not yet completed taking the survey. If a user attempts to return
to a survey that has an Active Progress for that user on that survey
they will return to that survey at the point where they left off. Once
the user completes the survey it is marked as complete or inactive.
That Inactive Progress then hold all the information related to that
instance the user took the survey, this includes all the responses. If
a user attempts to take a survey where he/she has no Active Progresses
an new active progress is created and the user takes the survey.
" and the only one not-submitted is the "Active Progress" one. this is
indeed interresting, for instance we could compare answers before/after.
But then: how do you handle anonymous surveys?
* Imagine you have a survey that requires neither an invitation code
nor some kind of authentication
* an anonymous participant begins to answer the survey but fails to
proceed (no true submit) [could be because of a browser crash or
because he decides to stop answering]
* a new (anonymous) participant tries to access the survey
=> Will the second one be presented partial answers from the first ?
I used the word 'tokens' with quotes to refer to our previous
invitation code system in LS 1.x
interresting: will help reusing "tokens"
***I am not sure what you mean by "tokens" in this context.
Thanks for your answers,
The data model is missing:
* user/group roles,
* metadata and custom attributes, and
* versioning, just to name a few.
The difference between metadata and custom attributes is that:
* metadata is data that will de directly associated with an object (a
field) this consists of information that every LS admin will track
such as full name of a user, email address of a user, etc.
* custom attributes will allow for LS admins to add additional
metadata that is related to their particular domain to objects.