Research whether to eliminate groups from the db

[bcb37]

It's been noted that the 'group' field of the Experiment User table is doesn't serve any useful purpose, and complicates backend queries unnecessarily.

The workingGroup field is used to determine what group a student is in at any given time. There is code to verify that the workingGroup is included in group, but UpGrade currently does nothing with the group information.

Tasks:

• Verify that removing the group field - and associated code - would not create any regressions.
• Determine whether there are any possible use cases for the group field in upcoming features (e.g. rostering integration, allowing student to switch classes)

Deliverable:

• ticket(s) to do the work of removing group (if that's what we want)

[VivekFitkariwala]

@bcb37 and @amurphy-cl We are using the user's group in the segment evaluation so we can't remove this.

[ppratikcr7]

@amurphy-cl Currently we consider users' group's for excluding group segment and not the workingGroup. So, is this correct? For example: User is initiated with the below details:

{ "id": "user1", "group": { "school": [ "school1", "school2" ], "class": [ "class1", "class2" ] }, "workingGroup": { "school": "school2", "class": "class1" } }

And the group experiment has group as 'school' and participants has group segment exclusion set to "school": "school1". The users' workingGroup has "school": "school2", but the user will not get the assignments as we check for group where we have the "school": "school1" and we exclude the user based on the group segment exclusion rule.

[amurphy-cl]

Won't do because we need/are using group.