Hi All,

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 conclusions
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 it.
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 central database.
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 participant 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 table.

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



Aniessh Sethh