Skip to content

Conversation

@Raine-Yang-UofT
Copy link
Contributor

@Raine-Yang-UofT Raine-Yang-UofT commented Apr 4, 2025

Proposed Changes

(Describe your changes here. Also describe the motivation for your changes: what problem do they solve, or how do they improve the application or codebase? If this pull request fixes an open issue, use a keyword to link this pull request to the issue.)

...

  • Add members parameter in /api/courses/:course_id/assignments/:assignment_id/groups endpoint to create a group with members.
  • For an individual assignment (group_max = 1), the group name created via API with one member is set to the member name.
Screenshots of your changes (if applicable)
Associated documentation repository pull request (if applicable) MarkUsProject/Wiki/pull/231

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change that adds functionality) X
🐛 Bug fix (non-breaking change that fixes an issue)
🎨 User interface change (change to user interface; provide screenshots)
♻️ Refactoring (internal change to codebase, without changing functionality)
🚦 Test update (change that only adds or modifies tests)
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

  • I have performed a self-review of my changes.
    • Check that all changed files included in this pull request are intentional changes.
    • Check that all changes are relevant to the purpose of this pull request, as described above.
  • I have added tests for my changes, if applicable.
    • This is required for all bug fixes and new features.
  • I have updated the project documentation, if applicable.
    • This is required for new features.
  • If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

  • I have updated the project Changelog (this is required for all changes).
  • I have verified that the pre-commit.ci checks have passed.
  • I have verified that the CI tests have passed.
  • I have reviewed the test coverage changes reported by Coveralls.
  • I have requested a review from a project maintainer.

Questions and Comments

(Include any questions or comments you have regarding your changes.)

@coveralls
Copy link
Collaborator

coveralls commented Apr 4, 2025

Pull Request Test Coverage Report for Build 14286000465

Details

  • 95 of 97 (97.94%) changed or added relevant lines in 3 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+0.01%) to 91.887%

Changes Missing Coverage Covered Lines Changed/Added Lines %
app/models/assignment.rb 27 29 93.1%
Totals Coverage Status
Change from base Build 14283696351: 0.01%
Covered Lines: 41547
Relevant Lines: 44532

💛 - Coveralls

Copy link
Collaborator

@david-yz-liu david-yz-liu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Raine-Yang-UofT nice work!

group = nil

Group.transaction do
group = if new_group_name.nil?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I'd like to avoid this style of variable assignment. Instead, keep the if statement at the outer level and initialize group in each branch. This also allows you to delete the group = nil line above.

group = if new_group_name.nil?
if members.length == 1 && self.group_max == 1
student_user_name = members.first
if self.is_timed
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great condition to check. Putting it here is a larger divergence from the original logic (which didn't check is_timed at all).

So instead of putting it here, add it to the condition on line 401 (&& !self.is_timed), so that for timed assessments the previous logic will execute. This also helps remove some of the code duplication.

raise 'A group name was not provided'
end
else
existing_group = self.course.groups.find_by(group_name: new_group_name)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't need to change this code from the original version


group.save!

if groupings.exists?(group_id: group.id)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, prefer using explicit self for all attributes/methods

grouping = Grouping.create!(group: group, assignment: self)

unless members.empty?
students = Student.joins(:user)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use self.course.students (need to ensure only students from the current course are queried)

unless members.empty?
students = Student.joins(:user)
.where(users: { user_name: members })
.index_by { |s| s.user.user_name }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good time to use pluck, as you really only need the user name and id here


grouping.student_memberships.create!(
role_id: student.id,
membership_status: if index.zero?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have the same stylistic comment as above. However, in this case you should be able to fit this on one line if you apply the ternary expression to just :inviter or :accepted, and not the other parts

end
end

context 'when group already exists in assignment' do
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reword to "when group already has a grouping for assignment"

let(:student2) { create(:student, user: user2, course: course) }

shared_examples 'group persistence and members' do |expected_member_count: 0|
it 'creates persistent group and grouping' do
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would split this into two assertions, one for the first assertion and one for the third assertion (the second is just testing an association so I don't think it's necessary). Also for the third assertion I would use find_by rather than where

if expected_member_count > 0
expect(grouping.student_memberships.first.membership_status).to eq(StudentMembership::STATUSES[:inviter])
if expected_member_count > 1
expect(grouping.student_memberships.last.membership_status).to eq(StudentMembership::STATUSES[:accepted])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing just last is a bit strange; it's more precise to use a loop for the rest.

I also recommend adding an additional test case for having more than two members.

@david-yz-liu david-yz-liu merged commit fe3d3c6 into MarkUsProject:master Apr 6, 2025
6 checks passed
@david-yz-liu
Copy link
Collaborator

Thank you, @Raine-Yang-UofT!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants