Added back the create retro and edit retro links to /pairs as they were removed because of a bug when group-based pairing was added.
Previously, the query that retrieved retros simply looked for a retro (and unfortunately multiple) that was associated with the user and the year and week (through a pair). This worked fine when it was only possible for a user to be in one pair per week, but it broke down once a user could be in many pairs in the same week due to being in multiple groups. The end effect was if you were paired in Group A and Group B, and created a retrospective for Group A, the "create retro" link would change to "edit retro" for both Group A and Group B, and would link to the retro that you created for Group A under both links. This now works properly.
This also fixed a subtle bug due to zipping the user's groups with the user's pairs for a given week when a user wasn't in a pair for all of their groups that week. If that pair that they weren't in was not the last group in the list of groups (order was arbitrary), then the pairs could shift to a different group. Pairs are now connected to groups explicitly, so it is possible for the second group out of three to not have a pair for the current user and have it display properly.
Although not a possible case presently, the /pairs route will now properly display multiple pairs for a group if the user is in multiple pairs.
Added back the create retro and edit retro links to /pairs as they were removed because of a bug when group-based pairing was added.
Previously, the query that retrieved retros simply looked for a retro (and unfortunately multiple) that was associated with the user and the year and week (through a pair). This worked fine when it was only possible for a user to be in one pair per week, but it broke down once a user could be in many pairs in the same week due to being in multiple groups. The end effect was if you were paired in Group A and Group B, and created a retrospective for Group A, the "create retro" link would change to "edit retro" for both Group A and Group B, and would link to the retro that you created for Group A under both links. This now works properly.
This also fixed a subtle bug due to zipping the user's groups with the user's pairs for a given week when a user wasn't in a pair for all of their groups that week. If that pair that they weren't in was not the last group in the list of groups (order was arbitrary), then the pairs could shift to a different group. Pairs are now connected to groups explicitly, so it is possible for the second group out of three to not have a pair for the current user and have it display properly.
Although not a possible case presently, the /pairs route will now properly display multiple pairs for a group if the user is in multiple pairs.
Closes #126