This is an update on the CPDB meeting we had on 12th May. The major
outcomes discussed in the meetings were
1) We will be extending the sign up control feature to allow the
participant to fill in their attribute as well.
2) We will be giving the grouping as not a separate feature but as a
part of the jqGrid filtering feature. Of course the participant will
be visible to the user only if has the required permission, such as,
he is the owner of the participant, and the participant is open to
be added to multiple surveys.
3) It was also clarified that the flow of participants can be either
way, i.e. it can be CPDB -> tokens table and from tokens table
-> CPDB. For implementing that we came to the following
4) From the 3rd point it is clear we are keeping the existing token
system as it is, we are building the central database on the top of
- No participant_id i.e UUID will be generated for the
participant who is added directly to the token table. The reason
is not to have two separate UUID's for the same participant in
the central table.
- When a participant is added to the central table, the
uniqueness(for now) will be determined using the name+e_mail
plus owner depending on the privacy settings, if similar the
participant will simply not be duplicated in the central
- If the participant is added to the central table first and
then to the token table, everything works as initially planned.
5) As soon as the participant is added from the token table to the
central table, his max_surveys value is increased by 1, thus
allowing him to be added to one more survey, in case he/she is a new
entry in the CPDB, we give the max_surveys a value of 2 and link the
existing survey from which it is added.
6) The insertion of attribute value from the answer given by the
participant, will be left for a later stage.
To be discussed in the next meeting :
1) As in the relationship diagram we have, we don't have attribute
specific to a particular survey, what if one user wants to have sex
as his participant's attribute, the other doesn't. Do we create
attribute as survey specific? This particular case is in relation to
the scenario where the participants will directly being added to the
2) In the case 2 on point 3, For example the participant is added
to the central table by uid '1', and to the token's table by uid
'2', and the user with uid '2' is adding the
to the central table only for the reason to be added to one other
survey. Now under the default scenario, a participant will not be
visible to other users except the owner's. So what UUID the
participant get, or we create a duplicate entry with the other uid.
One solution that Jason came up with was to check for name+email and
if it is the same, simply link the participant in the
lime_survey_links. What about the ownership then, who owns the
participant? I think we are leaving the middle scenario here, and
just concentrating on either completely free and completely private.
3) The attribute control is based on the participant_id. When we are
keeping the existing system in place, what about the attributes. We
can afford to create the attribute_ui feature for the token table as
well and allow the selective addition of attributes to the central
I think this pretty much sums up what we discussed and what is left
to be discussed .The log of the meeting is available here
And the wiki page is available here