Closed cdparra closed 7 years ago
I found this in the current implementation for creating new ballots for a working group. Should this implementation remain in the cases where the resource space belongs to a working group? if (workingGroup.getBlockMajority()) { ballotConfig.setValue("YES/NO/ABSTAIN/BLOCK"); ballotConfig.save(); ballotConfig = new BallotConfiguration(); ballotConfig.setBallotId(consensusBallot.getId()); ballotConfig .setKey(GlobalData.CONFIG_COMPONENT_VOTING_SYSTEM_PLURALITY_BLOCK_THRESHOLD); ballotConfig .setValue(workingGroup.getMajorityThreshold() != null ? workingGroup .getMajorityThreshold() : "SIMPLE"); ballotConfig.save(); } else { ballotConfig.setValue("YES/NO/ABSTAIN"); ballotConfig.save(); }
In the current implementation of the endpoint "PUT /api/assembly/:aid/group/:gid/ballot" only archives the ballot. Should we maintain this behavior, or should allow updating the ballot?
About (1), we should read the list of configurations for the ballot from the request. The request should include a "configs" array with one config for the type of voting system, and other configs for the configurations related to that voting system. See the config options for the component of voting in the default campaign json for the available configs.
About the PUT, we should also UPDATE the ballot (not only archive)
Add endpoints to create new Ballots in a campaign, archived currently active ballots and list active/archived ballots. As examples, see the Working Group create/archive ballot endpoints:
POST /api/assembly/:aid/group/:gid/ballot controllers.WorkingGroups.nextBallotForWorkingGroup(aid: Long, gid: Long)
PUT /api/assembly/:aid/group/:gid/ballot controllers.WorkingGroups.archiveWorkingGroupsBallot(aid: Long, gid: Long)
To make this possible, let's create the following endpoints (which will make it possible to create ballots not only on campaigns, but on other entities two:
POST /api/space/:rsid/ballot
=> should create a new ballot in the resource space with id:rsid
(e.g., the resource space of a campaign). The endpoint should allow apps to specify which entities in that resource space are included in the ballot by specifying the type of entity (e.g., CONTRIBUTION_PROPOSAL, CONTRIBUTION_IDEA, CONTRIBUTION_NOTE, CONTRIBUTION_DISCUSSION, CONTRIBUTION_COMMENT, CONTRIBUTION_NOTE, WORKING_GROUP, APPCIVIST_USER) and a list of UUIDs that identify those entities. If neither is specified, the default is to include all contributions of type PROPOSAL with status PUBLISHED.PUT /api/space/:cid/ballot
=> should update the ballot and can be used to archive it (change status of the ballot from active to archived). Whenever a ballot changes from active to archived, we should update the history of archived ballots.GET /api/space/:cid/ballot?status='x'&starts_at=xxx&ends_at=yyy
=> should list ballots with status = x, and with start/end dates in the range specified by xxx and yyy (if these are not specified, don't filter by date