This addresses the linkage of participants to the creation of studies by implementing filtering and sorting of participants.
Summary of changes
Added a "Participants" tab to the "Create a new Study" modal
The "Participants" tab features the same filter system from the participants page accessed via the QualOpt navbar at the top of the website. The only difference being a "Load Participants" button added to the modal as the participants table isn't populated when the modal is opened, this could be added as a feature request to dynamically populate the table on modal popup.
Prior to this, participants were selected via a 'select' class form input that was directly linked via ng-model to a participants array which were then used to populate a new study's participants field. I have since changed this to a group of checkboxes for an streamlined user experience that allows for a simpler identification of selected participants (a checkbox is easier to notice than a bunch of highlighted rows).
In saying so, there were difficulties in capturing checkbox selection for participants as well as importing the filter pipe from the participants page into the modal.
study.pipe.ts is adapted from participant.pipe.ts and enables the filtering of participants by occupation, number of repositories and emails etc., identically to the participants page
Each checkbox (corresponding to a participant's selection) is mapped to a HashMap of participants (the selectedParticipants[participant.id] object), saving a boolean true or false value for each selected (or deselected) participant. Prior to this, as participants were directly linked to the studies.participants object (which was submitted via form to create a study), no preprocessing on form submission was required. This is not the case now, as the HashMap of selectedParticipants is now iterated through and added to studies.participants when the 'Save' button is pressed.
Some things to note
The original issue - #34 suggests that there will be no use of the 'Participants" page once the filtering of participants has been linked to study creation and as such can be deleted. However, as many other features have been added since issue #34's creation (which have been listed on #34's issue page), with many of them dependent on the 'Participants' page, I have opted to leave it unchanged as to avoid tampering with the added features.
Last but not least, ideally the participants table would load automatically on tab change, so the user doesn't have to load them manually by clicking the 'Load Participants" button. However, I couldn't find the correct functionality supported with the ngb-tabset API and with my elementary knowledge of Angular 4 feel that it could be implemented better by someone more familiar with the tools available than I am.
This addresses the linkage of participants to the creation of studies by implementing filtering and sorting of participants.
Summary of changes Added a "Participants" tab to the "Create a new Study" modal The "Participants" tab features the same filter system from the participants page accessed via the QualOpt navbar at the top of the website. The only difference being a "Load Participants" button added to the modal as the participants table isn't populated when the modal is opened, this could be added as a feature request to dynamically populate the table on modal popup.
Prior to this, participants were selected via a 'select' class form input that was directly linked via ng-model to a participants array which were then used to populate a new study's participants field. I have since changed this to a group of checkboxes for an streamlined user experience that allows for a simpler identification of selected participants (a checkbox is easier to notice than a bunch of highlighted rows).
In saying so, there were difficulties in capturing checkbox selection for participants as well as importing the filter pipe from the participants page into the modal.
study.pipe.ts
is adapted fromparticipant.pipe.ts
and enables the filtering of participants by occupation, number of repositories and emails etc., identically to the participants pageselectedParticipants[participant.id]
object), saving a boolean true or false value for each selected (or deselected) participant. Prior to this, as participants were directly linked to the studies.participants object (which was submitted via form to create a study), no preprocessing on form submission was required. This is not the case now, as the HashMap ofselectedParticipants
is now iterated through and added to studies.participants when the 'Save' button is pressed.Some things to note The original issue - #34 suggests that there will be no use of the 'Participants" page once the filtering of participants has been linked to study creation and as such can be deleted. However, as many other features have been added since issue #34's creation (which have been listed on #34's issue page), with many of them dependent on the 'Participants' page, I have opted to leave it unchanged as to avoid tampering with the added features.
Last but not least, ideally the participants table would load automatically on tab change, so the user doesn't have to load them manually by clicking the 'Load Participants" button. However, I couldn't find the correct functionality supported with the ngb-tabset API and with my elementary knowledge of Angular 4 feel that it could be implemented better by someone more familiar with the tools available than I am.