Type and CDWG should not be editable after creation.
In #113
We should validate if an affiliation_id and curation_panel_id combo exist in the DB. There should not be duplicates.
In #118
Curation_panel_id should be unique.
Taken care of with changes in #118
curation_panel_id should be renamed to expert_panel_id
In #113
affiliation_id and expert_panel_id will always end in the same number ( example: 10025 and 40025 )
In #118
Can fields be prefilled based on type selected and affiliation_id input?
Per notes in the meeting, Rachel and Matt mentioned that prefilling based on a selection might be creating more issues for our future selves.
Members will need to be able to be added for Independent Curation Groups.
Per Matt on slack, Members will always be added in the GPM and VCI/GCI interfaces. The affiliations service will be "read-only" for all members.
For Members: we will need to check both the VCI/GCI to see who has access and the GPM to see who was added. Short term is to check to see who is in the VCI/GCI until we can get access to the GPM. (Boto and DynamoDB)
Per messages in slack, removing this option might be creating more problems for ourselves in the future. However, it is possible to remove this ability for everyone. We can remove this option by not granting delete permissions to users.
Can we remove deletion as a feature? If not, create an "Almost SuperUser" group with everything except delete functionality. Remove delete functionality from all groups/permissions.
Per messages in slack and above comment, Superusers should be website admins (developers) who would have the ability to create new superusers, and Affiliation Admins would be managers/team leads who can grant permissions to all other users (sans superusers).
Instead of delete, can we have an "archive" functionality? If not possible, can add Archive as a status.
Per messages in slack, we can create a archive status. Rachel asked if then we could filter by the headers. Gabriella is checking.
Change superuser ability to edit, keep fields read-only for staff.
In #122
Check with Courtney about Status types for the future, do we need both Inactive and Retired?
Notes from Rachel:
Retired vs inactive
Inactive group is basically done. Not doing anymore curation.
Retired this group started but then they never curated and then disbanded
I have added these definitions into the documentation in the "terminology" section.
Note that GCEP and VCEP need to be a part of the full_name in the documentation; and update documentation to all changes.
Type and CDWG should not be editable after creation.
We should validate if an affiliation_id and curation_panel_id combo exist in the DB. There should not be duplicates.
Curation_panel_id should be unique.
curation_panel_id should be renamed to expert_panel_id
affiliation_id and expert_panel_id will always end in the same number ( example: 10025 and 40025 )
Can fields be prefilled based on type selected and affiliation_id input?
Members will need to be able to be added for Independent Curation Groups.
For Members: we will need to check both the VCI/GCI to see who has access and the GPM to see who was added. Short term is to check to see who is in the VCI/GCI until we can get access to the GPM. (Boto and DynamoDB)
Once Live, we will need these user groups:
Can we remove bulk deletion option?
Can we remove deletion as a feature? If not, create an "Almost SuperUser" group with everything except delete functionality. Remove delete functionality from all groups/permissions.
Instead of delete, can we have an "archive" functionality? If not possible, can add Archive as a status.
Change superuser ability to edit, keep fields read-only for staff.
Check with Courtney about Status types for the future, do we need both Inactive and Retired?
Note that GCEP and VCEP need to be a part of the full_name in the documentation; and update documentation to all changes.
Rachel requested the ability to filter by status and other filters.