Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality

2025-04-23T01:27:46Z

Jpatel42: /* 7. Testing Strategy */

= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality =

== Team Members ==
* '''James Patel'''
* '''Sweekar Burji'''
* '''Isaac Taylor'''

== 1. Expertiza Overview ==
Expertiza is a modular peer‑review and assignment management platform. Core modules:
* '''Assignments''': creation, distribution, deadlines
* '''Reviews''': peer‑review workflows, rubric configuration
* '''Teams''': student grouping and collaboration
* '''Feedback & Grading''': role‑based score/comment interfaces
Role‑based access controls define permissions for instructors, TAs, and students, ensuring secure, fine‑grained data access.

== 2. Project Overview ==
Refactor the **Student Teams** feature to:
# Improve maintainability
# Clarify domain concepts
# Enforce precise, assignment‑specific membership mappings
Align data model and business logic with a clear “Participant” abstraction, reducing complexity and eliminating duplication.

== 3. Problem Statement ==
Legacy implementation issues:
* ''Generic Mapping Table'': `teams_users` simply relates `user_id` ↔ `team_id`, allowing cross‑assignment memberships without context.
* ''Ambiguous Naming & Raw SQL'': unclear model relationships drive developers to bypass ActiveRecord, raising security and maintainability concerns.
* ''Testing Gaps & Duplication'': sparse specs around membership logic; duplicated code in controllers and models increases risk of regressions.

== 4. Design Goals & Objectives ==
# '''Domain Clarity'''
## Rename `teams_users` → `teams_participants`
## Replace `user_id` with `participant_id` to tie membership to a `Participant` record
# '''Data Integrity'''
## Add DB constraints: FKs to `participants` & `teams`; unique index on `[:participant_id, :team_id]`
## Enforce presence and uniqueness via ActiveRecord validations
# '''Code Quality & Maintainability'''
## Extract membership logic into `TeamsParticipant` model & new `TeamsParticipantsController`
## Apply Single Responsibility Principle—controllers for HTTP, models for business rules
# '''Testing & Verification'''
## Expand RSpec coverage to ≥ 90% for refactored components
## Consolidate logic (e.g., `get_team_members`, `add_member_to_invited_team`) on `TeamsParticipant`
# '''Success Metrics'''
* Test coverage ↑ (SimpleCov)
* Cyclomatic complexity ↓ (CodeClimate)
* No CodeQL warnings

== 5. System Architecture Overview ==

=== 5.1 Data Flow (MVC Pattern) ===
<pre>
[ Models ] → [ Controllers ] → [ Views ]
↑ ↓
ActiveRecord HTTP responses & redirects
validations
</pre>

=== 5.2 Entity‑Relationship Diagram (ASCII) ===
<pre>
+-------------+ +-------------------+ +-------------+
| Participant |1----*| TeamsParticipant |*----1| Team |
+-------------+ +-------------------+ +-------------+
(id) (participant_id) (id, name,…)
(team_id)
(duty_id)
(status)
</pre>

=== 5.3 Schema Changes (Rails Migrations) ===
; Rename table
<syntaxhighlight lang="ruby">
rename_table :teams_users, :teams_participants
</syntaxhighlight>
; Add participant FK
<syntaxhighlight lang="ruby">
add_column :teams_participants, :participant_id, :bigint, null: false
add_foreign_key :teams_participants, :participants
</syntaxhighlight>
; Remove old column
<syntaxhighlight lang="ruby">
remove_column :teams_participants, :user_id
</syntaxhighlight>
; Unique index
<syntaxhighlight lang="ruby">
add_index :teams_participants, [:participant_id, :team_id], unique: true
</syntaxhighlight>

== 6. Detailed Component Design ==

=== 6.1 Models ===

==== TeamsParticipant ====
* '''Attributes''': `team_id`, `participant_id`, `duty_id` (optional), `pair_programming_status`
* '''Associations''':
** `belongs_to :team`
** `belongs_to :participant`
** `belongs_to :duty, optional: true`
* '''Validations''':
** presence of `team_id` and `participant_id`
** uniqueness of `participant_id` scoped to `team_id`
* '''Class Methods''':
** `.team_empty?(team_id)`
** `.add_member_to_invited_team(token, participant_id)`
** `.get_team_members(team_id)`
** `.get_teams_for_participant(participant_id)`

==== Participant ====
* Rename association `team_user` → `teams_participant`
* Update `has_many :teams_participants`, adjust dependent destroy logic

=== 6.2 Controllers ===

==== TeamsParticipantsController ====
* '''Actions''': `index`, `new`, `create`, `destroy`, `destroy_selected`, `update_duties`
* '''Responsibilities''':
** Handle membership lifecycle (create, delete, bulk remove, duty update)
** Strong params: permit only `:participant_id`, `:team_id`, duty fields
** Render HTML or JSON with appropriate flash/redirects

==== JoinTeamRequestsController ====
* Refactored to use `TeamsParticipant` for listing requests and popups
* Simplified business logic—no raw SQL, uses ActiveRecord scopes

=== 6.3 Views (UI) ===
* Replace `user.name` with `participant.full_name` in student teams pages
* Render duty assignment via partial `_duty_form.html.erb`
* Include before/after screenshots in documentation to illustrate updates

== 7. Testing Strategy ==

=== 7.1 Unit Testing (RSpec Model Specs) ===
* **TeamsParticipant**: test associations, validations, and class methods

=== 7.2 Controller Testing ===
* **TeamsParticipantsController**: verify HTTP codes, redirects, flash messages, and error handling

=== 7.3 Integration & System Testing ===
* **Capybara System Specs**: workflows for team creation, invitations, duty assignment, member removal; UI assertions

=== 7.4 Fixtures & Factories ===
* Update `FactoryBot` definitions: replace `:user_team` with `:teams_participant`
* Use shared contexts for assignments, participants, and teams

[[File:OODD 1st image.png|900px|center]]

== 8. Design Rationale & Impact ==
* '''Single Responsibility''': clear separation of concerns between controllers and models
* '''Domain Alignment''': “participant” abstraction captures assignment context
* '''Security & Quality''': ActiveRecord replaces raw SQL; CodeQL scans pass cleanly
* '''Maintainability''': centralized logic enables easier future enhancements
* '''Risks & Mitigations''':
** Migration complexity → write reversible migrations, schedule maintenance window
** Data integrity → pre‑validate existing records before enforcing constraints

== 9. References ==
* '''Migration Script''': `db/migrate/20240319000001_rename_teams_users_to_teams_participants.rb`
* '''CodeQL Workflow''': `.github/workflows/codeql.yml`
* '''Expertiza Wiki''': System design and refactor guidelines
* '''RSpec Coverage Reports''': `coverage/index.html`

File:OODD 1st image.png

2025-04-23T01:26:48Z

Jpatel42:

CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality

2025-04-23T01:19:53Z

Jpatel42: /* 7. Testing Strategy */

= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality =

== Team Members ==
* '''James Patel'''
* '''Sweekar Burji'''
* '''Isaac Taylor'''

== 1. Expertiza Overview ==
Expertiza is a modular peer‑review and assignment management platform. Core modules:
* '''Assignments''': creation, distribution, deadlines
* '''Reviews''': peer‑review workflows, rubric configuration
* '''Teams''': student grouping and collaboration
* '''Feedback & Grading''': role‑based score/comment interfaces
Role‑based access controls define permissions for instructors, TAs, and students, ensuring secure, fine‑grained data access.

== 2. Project Overview ==
Refactor the **Student Teams** feature to:
# Improve maintainability
# Clarify domain concepts
# Enforce precise, assignment‑specific membership mappings
Align data model and business logic with a clear “Participant” abstraction, reducing complexity and eliminating duplication.

== 3. Problem Statement ==
Legacy implementation issues:
* ''Generic Mapping Table'': `teams_users` simply relates `user_id` ↔ `team_id`, allowing cross‑assignment memberships without context.
* ''Ambiguous Naming & Raw SQL'': unclear model relationships drive developers to bypass ActiveRecord, raising security and maintainability concerns.
* ''Testing Gaps & Duplication'': sparse specs around membership logic; duplicated code in controllers and models increases risk of regressions.

== 4. Design Goals & Objectives ==
# '''Domain Clarity'''
## Rename `teams_users` → `teams_participants`
## Replace `user_id` with `participant_id` to tie membership to a `Participant` record
# '''Data Integrity'''
## Add DB constraints: FKs to `participants` & `teams`; unique index on `[:participant_id, :team_id]`
## Enforce presence and uniqueness via ActiveRecord validations
# '''Code Quality & Maintainability'''
## Extract membership logic into `TeamsParticipant` model & new `TeamsParticipantsController`
## Apply Single Responsibility Principle—controllers for HTTP, models for business rules
# '''Testing & Verification'''
## Expand RSpec coverage to ≥ 90% for refactored components
## Consolidate logic (e.g., `get_team_members`, `add_member_to_invited_team`) on `TeamsParticipant`
# '''Success Metrics'''
* Test coverage ↑ (SimpleCov)
* Cyclomatic complexity ↓ (CodeClimate)
* No CodeQL warnings

== 5. System Architecture Overview ==

=== 5.1 Data Flow (MVC Pattern) ===
<pre>
[ Models ] → [ Controllers ] → [ Views ]
↑ ↓
ActiveRecord HTTP responses & redirects
validations
</pre>

=== 5.2 Entity‑Relationship Diagram (ASCII) ===
<pre>
+-------------+ +-------------------+ +-------------+
| Participant |1----*| TeamsParticipant |*----1| Team |
+-------------+ +-------------------+ +-------------+
(id) (participant_id) (id, name,…)
(team_id)
(duty_id)
(status)
</pre>

=== 5.3 Schema Changes (Rails Migrations) ===
; Rename table
<syntaxhighlight lang="ruby">
rename_table :teams_users, :teams_participants
</syntaxhighlight>
; Add participant FK
<syntaxhighlight lang="ruby">
add_column :teams_participants, :participant_id, :bigint, null: false
add_foreign_key :teams_participants, :participants
</syntaxhighlight>
; Remove old column
<syntaxhighlight lang="ruby">
remove_column :teams_participants, :user_id
</syntaxhighlight>
; Unique index
<syntaxhighlight lang="ruby">
add_index :teams_participants, [:participant_id, :team_id], unique: true
</syntaxhighlight>

== 6. Detailed Component Design ==

=== 6.1 Models ===

==== TeamsParticipant ====
* '''Attributes''': `team_id`, `participant_id`, `duty_id` (optional), `pair_programming_status`
* '''Associations''':
** `belongs_to :team`
** `belongs_to :participant`
** `belongs_to :duty, optional: true`
* '''Validations''':
** presence of `team_id` and `participant_id`
** uniqueness of `participant_id` scoped to `team_id`
* '''Class Methods''':
** `.team_empty?(team_id)`
** `.add_member_to_invited_team(token, participant_id)`
** `.get_team_members(team_id)`
** `.get_teams_for_participant(participant_id)`

==== Participant ====
* Rename association `team_user` → `teams_participant`
* Update `has_many :teams_participants`, adjust dependent destroy logic

=== 6.2 Controllers ===

==== TeamsParticipantsController ====
* '''Actions''': `index`, `new`, `create`, `destroy`, `destroy_selected`, `update_duties`
* '''Responsibilities''':
** Handle membership lifecycle (create, delete, bulk remove, duty update)
** Strong params: permit only `:participant_id`, `:team_id`, duty fields
** Render HTML or JSON with appropriate flash/redirects

==== JoinTeamRequestsController ====
* Refactored to use `TeamsParticipant` for listing requests and popups
* Simplified business logic—no raw SQL, uses ActiveRecord scopes

=== 6.3 Views (UI) ===
* Replace `user.name` with `participant.full_name` in student teams pages
* Render duty assignment via partial `_duty_form.html.erb`
* Include before/after screenshots in documentation to illustrate updates

== 7. Testing Strategy ==

=== 7.1 Unit Testing (RSpec Model Specs) ===
* **TeamsParticipant**: test associations, validations, and class methods

=== 7.2 Controller Testing ===
* **TeamsParticipantsController**: verify HTTP codes, redirects, flash messages, and error handling

=== 7.3 Integration & System Testing ===
* **Capybara System Specs**: workflows for team creation, invitations, duty assignment, member removal; UI assertions

=== 7.4 Fixtures & Factories ===
* Update `FactoryBot` definitions: replace `:user_team` with `:teams_participant`
* Use shared contexts for assignments, participants, and teams

[[File:|900px|center]]

== 8. Design Rationale & Impact ==
* '''Single Responsibility''': clear separation of concerns between controllers and models
* '''Domain Alignment''': “participant” abstraction captures assignment context
* '''Security & Quality''': ActiveRecord replaces raw SQL; CodeQL scans pass cleanly
* '''Maintainability''': centralized logic enables easier future enhancements
* '''Risks & Mitigations''':
** Migration complexity → write reversible migrations, schedule maintenance window
** Data integrity → pre‑validate existing records before enforcing constraints

== 9. References ==
* '''Migration Script''': `db/migrate/20240319000001_rename_teams_users_to_teams_participants.rb`
* '''CodeQL Workflow''': `.github/workflows/codeql.yml`
* '''Expertiza Wiki''': System design and refactor guidelines
* '''RSpec Coverage Reports''': `coverage/index.html`

CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality

2025-04-23T01:19:22Z

Jpatel42: /* 7. Testing Strategy */

= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality =

== Team Members ==
* '''James Patel'''
* '''Sweekar Burji'''
* '''Isaac Taylor'''

== 1. Expertiza Overview ==
Expertiza is a modular peer‑review and assignment management platform. Core modules:
* '''Assignments''': creation, distribution, deadlines
* '''Reviews''': peer‑review workflows, rubric configuration
* '''Teams''': student grouping and collaboration
* '''Feedback & Grading''': role‑based score/comment interfaces
Role‑based access controls define permissions for instructors, TAs, and students, ensuring secure, fine‑grained data access.

== 2. Project Overview ==
Refactor the **Student Teams** feature to:
# Improve maintainability
# Clarify domain concepts
# Enforce precise, assignment‑specific membership mappings
Align data model and business logic with a clear “Participant” abstraction, reducing complexity and eliminating duplication.

== 3. Problem Statement ==
Legacy implementation issues:
* ''Generic Mapping Table'': `teams_users` simply relates `user_id` ↔ `team_id`, allowing cross‑assignment memberships without context.
* ''Ambiguous Naming & Raw SQL'': unclear model relationships drive developers to bypass ActiveRecord, raising security and maintainability concerns.
* ''Testing Gaps & Duplication'': sparse specs around membership logic; duplicated code in controllers and models increases risk of regressions.

== 4. Design Goals & Objectives ==
# '''Domain Clarity'''
## Rename `teams_users` → `teams_participants`
## Replace `user_id` with `participant_id` to tie membership to a `Participant` record
# '''Data Integrity'''
## Add DB constraints: FKs to `participants` & `teams`; unique index on `[:participant_id, :team_id]`
## Enforce presence and uniqueness via ActiveRecord validations
# '''Code Quality & Maintainability'''
## Extract membership logic into `TeamsParticipant` model & new `TeamsParticipantsController`
## Apply Single Responsibility Principle—controllers for HTTP, models for business rules
# '''Testing & Verification'''
## Expand RSpec coverage to ≥ 90% for refactored components
## Consolidate logic (e.g., `get_team_members`, `add_member_to_invited_team`) on `TeamsParticipant`
# '''Success Metrics'''
* Test coverage ↑ (SimpleCov)
* Cyclomatic complexity ↓ (CodeClimate)
* No CodeQL warnings

== 5. System Architecture Overview ==

=== 5.1 Data Flow (MVC Pattern) ===
<pre>
[ Models ] → [ Controllers ] → [ Views ]
↑ ↓
ActiveRecord HTTP responses & redirects
validations
</pre>

=== 5.2 Entity‑Relationship Diagram (ASCII) ===
<pre>
+-------------+ +-------------------+ +-------------+
| Participant |1----*| TeamsParticipant |*----1| Team |
+-------------+ +-------------------+ +-------------+
(id) (participant_id) (id, name,…)
(team_id)
(duty_id)
(status)
</pre>

=== 5.3 Schema Changes (Rails Migrations) ===
; Rename table
<syntaxhighlight lang="ruby">
rename_table :teams_users, :teams_participants
</syntaxhighlight>
; Add participant FK
<syntaxhighlight lang="ruby">
add_column :teams_participants, :participant_id, :bigint, null: false
add_foreign_key :teams_participants, :participants
</syntaxhighlight>
; Remove old column
<syntaxhighlight lang="ruby">
remove_column :teams_participants, :user_id
</syntaxhighlight>
; Unique index
<syntaxhighlight lang="ruby">
add_index :teams_participants, [:participant_id, :team_id], unique: true
</syntaxhighlight>

== 6. Detailed Component Design ==

=== 6.1 Models ===

==== TeamsParticipant ====
* '''Attributes''': `team_id`, `participant_id`, `duty_id` (optional), `pair_programming_status`
* '''Associations''':
** `belongs_to :team`
** `belongs_to :participant`
** `belongs_to :duty, optional: true`
* '''Validations''':
** presence of `team_id` and `participant_id`
** uniqueness of `participant_id` scoped to `team_id`
* '''Class Methods''':
** `.team_empty?(team_id)`
** `.add_member_to_invited_team(token, participant_id)`
** `.get_team_members(team_id)`
** `.get_teams_for_participant(participant_id)`

==== Participant ====
* Rename association `team_user` → `teams_participant`
* Update `has_many :teams_participants`, adjust dependent destroy logic

=== 6.2 Controllers ===

==== TeamsParticipantsController ====
* '''Actions''': `index`, `new`, `create`, `destroy`, `destroy_selected`, `update_duties`
* '''Responsibilities''':
** Handle membership lifecycle (create, delete, bulk remove, duty update)
** Strong params: permit only `:participant_id`, `:team_id`, duty fields
** Render HTML or JSON with appropriate flash/redirects

==== JoinTeamRequestsController ====
* Refactored to use `TeamsParticipant` for listing requests and popups
* Simplified business logic—no raw SQL, uses ActiveRecord scopes

=== 6.3 Views (UI) ===
* Replace `user.name` with `participant.full_name` in student teams pages
* Render duty assignment via partial `_duty_form.html.erb`
* Include before/after screenshots in documentation to illustrate updates

== 7. Testing Strategy ==

=== 7.1 Unit Testing (RSpec Model Specs) ===
* **TeamsParticipant**: test associations, validations, and class methods

=== 7.2 Controller Testing ===
* **TeamsParticipantsController**: verify HTTP codes, redirects, flash messages, and error handling

=== 7.3 Integration & System Testing ===
* **Capybara System Specs**: workflows for team creation, invitations, duty assignment, member removal; UI assertions

=== 7.4 Fixtures & Factories ===
* Update `FactoryBot` definitions: replace `:user_team` with `:teams_participant`
* Use shared contexts for assignments, participants, and teams

[[File:UI-1.png|900px|center]]

== 8. Design Rationale & Impact ==
* '''Single Responsibility''': clear separation of concerns between controllers and models
* '''Domain Alignment''': “participant” abstraction captures assignment context
* '''Security & Quality''': ActiveRecord replaces raw SQL; CodeQL scans pass cleanly
* '''Maintainability''': centralized logic enables easier future enhancements
* '''Risks & Mitigations''':
** Migration complexity → write reversible migrations, schedule maintenance window
** Data integrity → pre‑validate existing records before enforcing constraints

== 9. References ==
* '''Migration Script''': `db/migrate/20240319000001_rename_teams_users_to_teams_participants.rb`
* '''CodeQL Workflow''': `.github/workflows/codeql.yml`
* '''Expertiza Wiki''': System design and refactor guidelines
* '''RSpec Coverage Reports''': `coverage/index.html`

CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality

2025-04-23T00:30:44Z

Jpatel42: Created page with "= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality = == Team Members == * '''James Patel''' * '''Sweekar Burji''' * '''Isaac Taylor''' == 1. Expertiza Overview == Expertiza is a modular peer‑review and assignment management platform. Core modules: * '''Assignments''': creation, distribution, deadlines * '''Reviews''': peer‑review workflows, rubric configuration * '''Teams''': student grouping and collaboration * '''Feedback & ..."

= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality =

== Team Members ==
* '''James Patel'''
* '''Sweekar Burji'''
* '''Isaac Taylor'''

== 1. Expertiza Overview ==
Expertiza is a modular peer‑review and assignment management platform. Core modules:
* '''Assignments''': creation, distribution, deadlines
* '''Reviews''': peer‑review workflows, rubric configuration
* '''Teams''': student grouping and collaboration
* '''Feedback & Grading''': role‑based score/comment interfaces
Role‑based access controls define permissions for instructors, TAs, and students, ensuring secure, fine‑grained data access.

== 2. Project Overview ==
Refactor the **Student Teams** feature to:
# Improve maintainability
# Clarify domain concepts
# Enforce precise, assignment‑specific membership mappings
Align data model and business logic with a clear “Participant” abstraction, reducing complexity and eliminating duplication.

== 3. Problem Statement ==
Legacy implementation issues:
* ''Generic Mapping Table'': `teams_users` simply relates `user_id` ↔ `team_id`, allowing cross‑assignment memberships without context.
* ''Ambiguous Naming & Raw SQL'': unclear model relationships drive developers to bypass ActiveRecord, raising security and maintainability concerns.
* ''Testing Gaps & Duplication'': sparse specs around membership logic; duplicated code in controllers and models increases risk of regressions.

== 4. Design Goals & Objectives ==
# '''Domain Clarity'''
## Rename `teams_users` → `teams_participants`
## Replace `user_id` with `participant_id` to tie membership to a `Participant` record
# '''Data Integrity'''
## Add DB constraints: FKs to `participants` & `teams`; unique index on `[:participant_id, :team_id]`
## Enforce presence and uniqueness via ActiveRecord validations
# '''Code Quality & Maintainability'''
## Extract membership logic into `TeamsParticipant` model & new `TeamsParticipantsController`
## Apply Single Responsibility Principle—controllers for HTTP, models for business rules
# '''Testing & Verification'''
## Expand RSpec coverage to ≥ 90% for refactored components
## Consolidate logic (e.g., `get_team_members`, `add_member_to_invited_team`) on `TeamsParticipant`
# '''Success Metrics'''
* Test coverage ↑ (SimpleCov)
* Cyclomatic complexity ↓ (CodeClimate)
* No CodeQL warnings

== 5. System Architecture Overview ==

=== 5.1 Data Flow (MVC Pattern) ===
<pre>
[ Models ] → [ Controllers ] → [ Views ]
↑ ↓
ActiveRecord HTTP responses & redirects
validations
</pre>

=== 5.2 Entity‑Relationship Diagram (ASCII) ===
<pre>
+-------------+ +-------------------+ +-------------+
| Participant |1----*| TeamsParticipant |*----1| Team |
+-------------+ +-------------------+ +-------------+
(id) (participant_id) (id, name,…)
(team_id)
(duty_id)
(status)
</pre>

=== 5.3 Schema Changes (Rails Migrations) ===
; Rename table
<syntaxhighlight lang="ruby">
rename_table :teams_users, :teams_participants
</syntaxhighlight>
; Add participant FK
<syntaxhighlight lang="ruby">
add_column :teams_participants, :participant_id, :bigint, null: false
add_foreign_key :teams_participants, :participants
</syntaxhighlight>
; Remove old column
<syntaxhighlight lang="ruby">
remove_column :teams_participants, :user_id
</syntaxhighlight>
; Unique index
<syntaxhighlight lang="ruby">
add_index :teams_participants, [:participant_id, :team_id], unique: true
</syntaxhighlight>

== 6. Detailed Component Design ==

=== 6.1 Models ===

==== TeamsParticipant ====
* '''Attributes''': `team_id`, `participant_id`, `duty_id` (optional), `pair_programming_status`
* '''Associations''':
** `belongs_to :team`
** `belongs_to :participant`
** `belongs_to :duty, optional: true`
* '''Validations''':
** presence of `team_id` and `participant_id`
** uniqueness of `participant_id` scoped to `team_id`
* '''Class Methods''':
** `.team_empty?(team_id)`
** `.add_member_to_invited_team(token, participant_id)`
** `.get_team_members(team_id)`
** `.get_teams_for_participant(participant_id)`

==== Participant ====
* Rename association `team_user` → `teams_participant`
* Update `has_many :teams_participants`, adjust dependent destroy logic

=== 6.2 Controllers ===

==== TeamsParticipantsController ====
* '''Actions''': `index`, `new`, `create`, `destroy`, `destroy_selected`, `update_duties`
* '''Responsibilities''':
** Handle membership lifecycle (create, delete, bulk remove, duty update)
** Strong params: permit only `:participant_id`, `:team_id`, duty fields
** Render HTML or JSON with appropriate flash/redirects

==== JoinTeamRequestsController ====
* Refactored to use `TeamsParticipant` for listing requests and popups
* Simplified business logic—no raw SQL, uses ActiveRecord scopes

=== 6.3 Views (UI) ===
* Replace `user.name` with `participant.full_name` in student teams pages
* Render duty assignment via partial `_duty_form.html.erb`
* Include before/after screenshots in documentation to illustrate updates

== 7. Testing Strategy ==

=== 7.1 Unit Testing (RSpec Model Specs) ===
* **TeamsParticipant**: test associations, validations, and class methods

=== 7.2 Controller Testing ===
* **TeamsParticipantsController**: verify HTTP codes, redirects, flash messages, and error handling

=== 7.3 Integration & System Testing ===
* **Capybara System Specs**: workflows for team creation, invitations, duty assignment, member removal; UI assertions

=== 7.4 Fixtures & Factories ===
* Update `FactoryBot` definitions: replace `:user_team` with `:teams_participant`
* Use shared contexts for assignments, participants, and teams

== 8. Design Rationale & Impact ==
* '''Single Responsibility''': clear separation of concerns between controllers and models
* '''Domain Alignment''': “participant” abstraction captures assignment context
* '''Security & Quality''': ActiveRecord replaces raw SQL; CodeQL scans pass cleanly
* '''Maintainability''': centralized logic enables easier future enhancements
* '''Risks & Mitigations''':
** Migration complexity → write reversible migrations, schedule maintenance window
** Data integrity → pre‑validate existing records before enforcing constraints

== 9. References ==
* '''Migration Script''': `db/migrate/20240319000001_rename_teams_users_to_teams_participants.rb`
* '''CodeQL Workflow''': `.github/workflows/codeql.yml`
* '''Expertiza Wiki''': System design and refactor guidelines
* '''RSpec Coverage Reports''': `coverage/index.html`

CSC/ECE 517 Spring 2025

2025-04-23T00:29:58Z

Jpatel42:

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2528 Testing for Survey Deployment]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2535 Reimplement User Profile Management (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]
* [[CSC/ECE 517 Spring 2025 - E2506. Merging UI for View Assignments in Courses]]
* [[CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality]]

CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality

2025-04-23T00:28:37Z

Jpatel42:

= CSC/ECE 517 Spring 2025 – Refactor Student Teams Functionality =

== Team Members ==
* '''James Patel'''
* '''Sweekar Burji'''
* '''Isaac Taylor'''

== 1. Expertiza Overview ==
Expertiza is a modular peer‑review and assignment management platform. Core modules:
* '''Assignments''': creation, distribution, deadlines
* '''Reviews''': peer‑review workflows, rubric configuration
* '''Teams''': student grouping and collaboration
* '''Feedback & Grading''': role‑based score/comment interfaces
Role‑based access controls define permissions for instructors, TAs, and students, ensuring secure, fine‑grained data access.

== 2. Project Overview ==
Refactor the **Student Teams** feature to:
# Improve maintainability
# Clarify domain concepts
# Enforce precise, assignment‑specific membership mappings
Align data model and business logic with a clear “Participant” abstraction, reducing complexity and eliminating duplication.

== 3. Problem Statement ==
Legacy implementation issues:
* ''Generic Mapping Table'': `teams_users` simply relates `user_id` ↔ `team_id`, allowing cross‑assignment memberships without context.
* ''Ambiguous Naming & Raw SQL'': unclear model relationships drive developers to bypass ActiveRecord, raising security and maintainability concerns.
* ''Testing Gaps & Duplication'': sparse specs around membership logic; duplicated code in controllers and models increases risk of regressions.

== 4. Design Goals & Objectives ==
# '''Domain Clarity'''
## Rename `teams_users` → `teams_participants`
## Replace `user_id` with `participant_id` to tie membership to a `Participant` record
# '''Data Integrity'''
## Add DB constraints: FKs to `participants` & `teams`; unique index on `[:participant_id, :team_id]`
## Enforce presence and uniqueness via ActiveRecord validations
# '''Code Quality & Maintainability'''
## Extract membership logic into `TeamsParticipant` model & new `TeamsParticipantsController`
## Apply Single Responsibility Principle—controllers for HTTP, models for business rules
# '''Testing & Verification'''
## Expand RSpec coverage to ≥ 90% for refactored components
## Consolidate logic (e.g., `get_team_members`, `add_member_to_invited_team`) on `TeamsParticipant`
# '''Success Metrics'''
* Test coverage ↑ (SimpleCov)
* Cyclomatic complexity ↓ (CodeClimate)
* No CodeQL warnings

== 5. System Architecture Overview ==

=== 5.1 Data Flow (MVC Pattern) ===
<pre>
[ Models ] → [ Controllers ] → [ Views ]
↑ ↓
ActiveRecord HTTP responses & redirects
validations
</pre>

=== 5.2 Entity‑Relationship Diagram (ASCII) ===
<pre>
+-------------+ +-------------------+ +-------------+
| Participant |1----*| TeamsParticipant |*----1| Team |
+-------------+ +-------------------+ +-------------+
(id) (participant_id) (id, name,…)
(team_id)
(duty_id)
(status)
</pre>

=== 5.3 Schema Changes (Rails Migrations) ===
; Rename table
<syntaxhighlight lang="ruby">
rename_table :teams_users, :teams_participants
</syntaxhighlight>
; Add participant FK
<syntaxhighlight lang="ruby">
add_column :teams_participants, :participant_id, :bigint, null: false
add_foreign_key :teams_participants, :participants
</syntaxhighlight>
; Remove old column
<syntaxhighlight lang="ruby">
remove_column :teams_participants, :user_id
</syntaxhighlight>
; Unique index
<syntaxhighlight lang="ruby">
add_index :teams_participants, [:participant_id, :team_id], unique: true
</syntaxhighlight>

== 6. Detailed Component Design ==

=== 6.1 Models ===

==== TeamsParticipant ====
* '''Attributes''': `team_id`, `participant_id`, `duty_id` (optional), `pair_programming_status`
* '''Associations''':
** `belongs_to :team`
** `belongs_to :participant`
** `belongs_to :duty, optional: true`
* '''Validations''':
** presence of `team_id` and `participant_id`
** uniqueness of `participant_id` scoped to `team_id`
* '''Class Methods''':
** `.team_empty?(team_id)`
** `.add_member_to_invited_team(token, participant_id)`
** `.get_team_members(team_id)`
** `.get_teams_for_participant(participant_id)`

==== Participant ====
* Rename association `team_user` → `teams_participant`
* Update `has_many :teams_participants`, adjust dependent destroy logic

=== 6.2 Controllers ===

==== TeamsParticipantsController ====
* '''Actions''': `index`, `new`, `create`, `destroy`, `destroy_selected`, `update_duties`
* '''Responsibilities''':
** Handle membership lifecycle (create, delete, bulk remove, duty update)
** Strong params: permit only `:participant_id`, `:team_id`, duty fields
** Render HTML or JSON with appropriate flash/redirects

==== JoinTeamRequestsController ====
* Refactored to use `TeamsParticipant` for listing requests and popups
* Simplified business logic—no raw SQL, uses ActiveRecord scopes

=== 6.3 Views (UI) ===
* Replace `user.name` with `participant.full_name` in student teams pages
* Render duty assignment via partial `_duty_form.html.erb`
* Include before/after screenshots in documentation to illustrate updates

== 7. Testing Strategy ==

=== 7.1 Unit Testing (RSpec Model Specs) ===
* **TeamsParticipant**: test associations, validations, and class methods

=== 7.2 Controller Testing ===
* **TeamsParticipantsController**: verify HTTP codes, redirects, flash messages, and error handling

=== 7.3 Integration & System Testing ===
* **Capybara System Specs**: workflows for team creation, invitations, duty assignment, member removal; UI assertions

=== 7.4 Fixtures & Factories ===
* Update `FactoryBot` definitions: replace `:user_team` with `:teams_participant`
* Use shared contexts for assignments, participants, and teams

== 8. Design Rationale & Impact ==
* '''Single Responsibility''': clear separation of concerns between controllers and models
* '''Domain Alignment''': “participant” abstraction captures assignment context
* '''Security & Quality''': ActiveRecord replaces raw SQL; CodeQL scans pass cleanly
* '''Maintainability''': centralized logic enables easier future enhancements
* '''Risks & Mitigations''':
** Migration complexity → write reversible migrations, schedule maintenance window
** Data integrity → pre‑validate existing records before enforcing constraints

== 9. References ==
* '''Migration Script''': `db/migrate/20240319000001_rename_teams_users_to_teams_participants.rb`
* '''CodeQL Workflow''': `.github/workflows/codeql.yml`
* '''Expertiza Wiki''': System design and refactor guidelines
* '''RSpec Coverage Reports''': `coverage/index.html`

CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality

2025-04-08T17:55:21Z

Jpatel42: /* Team */

==Expertiza Background==
Expertiza is a Ruby on Rails-based open-source platform developed at NC State University, designed to enhance the management of assignment submissions, peer reviews, and team-based collaboration. It is actively maintained and improved by students and staff, enabling rich pedagogical workflows through features like topic selection, automated and manual review assignment, and team functionality.

==Student Teams Functionality Refactor==
This initiative (E2500) targets the core mechanism by which student team memberships are handled in Expertiza. The motivation was to resolve ambiguity and reduce technical debt by shifting from a global user-based team model to a participant-centric model, better aligning with the domain logic of assignment-specific participation.

==Problem Statement==
The current implementation uses the teams_users table to associate teams with users globally. However, this design fails to recognize that a student may enroll in multiple assignments, each with potentially different team affiliations. This misalignment complicates membership validation, reduces data integrity, and introduces ambiguity across the system.

Additional issues:

Business logic is embedded in controllers, violating separation of concerns.

Models like SignedUpTeam use raw SQL queries, reducing readability and increasing maintenance risk.

Lack of validation and redundant logic inflate technical debt.

==Refactor Goals==

Align the data model with a participant-centric architecture.

Create a new TeamsParticipants model and controller.

Remove redundant fields and logic (e.g., user_id in team membership).

Improve clarity, maintainability, and adherence to MVC best practices.

Enhance the views to support edge cases and provide cleaner UX.

Expand test coverage to ensure system integrity post-refactor.

==Design & Implementation==

===Schema Migration===
We introduced a migration that:

Renames teams_users to teams_participants.

Replaces user_id with participant_id, enforcing assignment specificity.

Removes redundant fields and adds proper indexing for data integrity.

#comment - Insert migration file code snippet here

===TeamsParticipant Model===
A new model TeamsParticipant was introduced to manage the many-to-many relationship between teams and assignment-specific participants.

#comment - Insert code block for TeamsParticipant model

Key Features:

belongs_to :team

belongs_to :participant

Validations for presence and uniqueness of associations

Centralized logic for managing team membership

===TeamsParticipantsController===
This new controller handles adding and removing participants from teams. By isolating this logic, we simplify the primary TeamsController and adhere more closely to Rails conventions.

#comment - Insert code block for TeamsParticipantsController#create method

Highlights:

Validates participant existence before adding to a team

Uses flash messaging for user feedback

Prevents duplicate entries through model-level validations

===View Layer Enhancements===
The front-end views were updated to:

Display team members using participant names, not user IDs

Handle nil values gracefully to avoid unexpected crashes

Provide meaningful error messages and user feedback

Present team layouts in a cleaner, more intuitive format

#comment - Add screenshots or HTML.erb snippets showing before/after of team views

==Testing Strategy==

===Unit Testing===

Model-level tests ensure associations, validations, and constraints in TeamsParticipant.

Prevents duplicate memberships.

Verifies foreign key constraints (e.g., participant must exist).

===Controller Testing===

Tests for create/destroy actions in TeamsParticipantsController.

Simulate valid and invalid inputs.

Confirm redirection behavior and error message accuracy.

===Integration Testing===

Create full user workflows from team creation to submission.

Use Capybara and feature specs for form submission, error state, and redirection flow.

#comment - Insert RSpec test case examples for TeamsParticipant and controller

===RSpec Summary=== All tests have been run with RSpec across models, controllers, and features. Integration is monitored using GitHub Actions for CI/CD. The system passed all tests post-refactor, with added coverage for new components.

#comment - Add RSpec test result screenshot

==AI-Assisted Refactoring==
We utilized Cursor IDE to accelerate the refactoring process. Its semantic code search and context-aware suggestions helped:

Refactor large controller methods into smaller ones.

Identify redundant logic and recommend method extractions.

Improve variable naming for clarity.

Safely reorganize models and controller responsibilities.

Cursor’s assistance also ensured that refactored code aligned with principles from Clean Code and best practices in Rails development.

==Design Principles Applied==

Single Responsibility Principle (SRP)

Don’t Repeat Yourself (DRY)

Separation of Concerns (SoC)

Consistent Error Handling

Explicit Association Mapping

Rails MVC Compliance

==Implementation Impact==
The refactor delivered:

Reduced ambiguity in team assignment logic.

Improved scalability for supporting multiple assignments.

Better maintainability and readability.

Robust error messaging and input validation.

Cleaner view rendering logic and fewer frontend crashes.

==Final Code Overview==

Teams and participants are now linked via TeamsParticipant, not TeamsUser.

New controller separates membership responsibilities.

Views updated to reflect new model structure.

Comprehensive test coverage ensures resilience.

No regression in functionality post-refactor.

==References==

Expertiza GitHub Repository

Ruby on Rails Guides

RSpec Documentation

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

Cursor IDE (https://www.cursor.sh/)

==Peer Review Notes==
This narrative document replaces the previous bullet-point-based design update. It is intended to provide a comprehensive explanation of both the implementation and reasoning behind our refactoring decisions. Reviewers are encouraged to evaluate the clarity of the design rationale, test completeness, and code modularity.

==Team==
Sweekar Burji (sburji)

James Patel (jpatel42)

Isaac Taylor (itaylor)

CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality

2025-04-08T17:54:58Z

Jpatel42:

CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality

2025-04-08T17:54:25Z

Jpatel42:

CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality

2025-04-08T17:50:22Z

Jpatel42: Created page with "==Expertiza Background== Expertiza is a Ruby on Rails-based open-source platform developed at NC State University, designed to enhance the management of assignment submissions, peer reviews, and team-based collaboration. It is actively maintained and improved by students and staff, enabling rich pedagogical workflows through features like topic selection, automated and manual review assignment, and team functionality. ==Student Teams Functionality Refactor== This initia..."

CSC/ECE 517 Spring 2025

2025-04-08T17:39:25Z

Jpatel42: /* Final Projects */

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2528 Testing for Survey Deployment]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2535 Reimplement User Profile Management (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]
* [[CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2500. Refactor Student Teams Functionality]]

CSC/ECE 517 Spring 2025

2025-04-08T16:56:54Z

Jpatel42: /* Final Projects */

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2528 Testing for Survey Deployment]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2535 Reimplement User Profile Management (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2536. Improve assessment360 controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]
* [[CSC/ECE 517 Spring 2025 - E2529. Testing for the Questionnaire Helper in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2541. Refactor Student Teams Functionality]]