SAK-51713 Tests & Quizzes Instructors should see all student submissions when a assessment is published to the entire site

[st-manu]

https://sakaiproject.atlassian.net/browse/SAK-51713

Summary by CodeRabbit

• Chores
  • Updated database migration scripts for version 25.1 to 25.2 compatibility, including configuration of assessment permissions across supported database systems.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Adds database migration scripts for Sakai 25.1 to 25.2 supporting MySQL and Oracle. Introduces 'assessment.all.groups' permission and uses temporary tables to map roles to functions, applying permissions across realms while preventing duplicates via NOT EXISTS clauses.

Changes

Cohort / File(s)	Change Summary
Sakai 25.1–25.2 Database Migrations docs/conversion/sakai_25_1-25_2_mysql_conversion.sql, docs/conversion/sakai_25_1-25_2_oracle_conversion.sql	Adds migration logic (SAK-51713) to define the 'assessment.all.groups' function and grant it across Sakai realms. Uses temporary tables (PERMISSIONS_SRC_TEMP, PERMISSIONS_TEMP) to map roles to the function, populates mappings, and inserts into SAKAI_REALM_RL_FN with deduplication logic. Excludes helper and template realms, then cleans up temporary artifacts.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly reflects the main change: adding the assessment.all.groups permission to enable instructors to see all student submissions when assessments are published site-wide.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 50294e1 and 2022b6f.

📒 Files selected for processing (2)

• docs/conversion/sakai_26_mysql_conversion.sql (1 hunks)
• docs/conversion/sakai_26_oracle_conversion.sql (1 hunks)

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (2)

docs/conversion/sakai_25_1-25_2_mysql_conversion.sql (1)

8-8: Temporary table operations lack defensive guards.

CREATE TABLE will fail if tables already exist from a partial previous run, and DROP TABLE will fail if tables were never created. Adding defensive guards improves script resilience.

🔎 Suggested fix:

 -- Add this to populate existing sites with the permission
+DROP TABLE IF EXISTS PERMISSIONS_SRC_TEMP;
 CREATE TABLE PERMISSIONS_SRC_TEMP (ROLE_NAME VARCHAR(99), FUNCTION_NAME VARCHAR(99));

+DROP TABLE IF EXISTS PERMISSIONS_TEMP;
 CREATE TABLE PERMISSIONS_TEMP (ROLE_KEY INTEGER, FUNCTION_KEY INTEGER);

-DROP TABLE PERMISSIONS_TEMP;
-DROP TABLE PERMISSIONS_SRC_TEMP;
+DROP TABLE IF EXISTS PERMISSIONS_TEMP;
+DROP TABLE IF EXISTS PERMISSIONS_SRC_TEMP;

Also applies to: 12-12, 32-33

docs/conversion/sakai_25_1-25_2_oracle_conversion.sql (1)

16-16: Temporary table operations may fail on partial re-runs.

Oracle's CREATE TABLE fails if the table exists, and DROP TABLE fails if it doesn't. For robustness, consider dropping before creating. In Oracle 12.2+, you can use the PRIVATE TEMPORARY TABLE feature, or for older versions, add a preceding drop with exception handling.

🔎 Simpler approach - drop before create:

 -- Add this to populate existing sites with the permission
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PERMISSIONS_SRC_TEMP'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
 CREATE TABLE PERMISSIONS_SRC_TEMP (ROLE_NAME VARCHAR(99), FUNCTION_NAME VARCHAR(99));

+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PERMISSIONS_TEMP'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
 CREATE TABLE PERMISSIONS_TEMP (ROLE_KEY INTEGER, FUNCTION_KEY INTEGER);

Or at the end:

-DROP TABLE PERMISSIONS_TEMP;
-DROP TABLE PERMISSIONS_SRC_TEMP;
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PERMISSIONS_TEMP'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/
+BEGIN EXECUTE IMMEDIATE 'DROP TABLE PERMISSIONS_SRC_TEMP'; EXCEPTION WHEN OTHERS THEN NULL; END;
+/

Also applies to: 20-20, 41-42

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2022b6f and 50f0d20.

📒 Files selected for processing (2)

• docs/conversion/sakai_25_1-25_2_mysql_conversion.sql (1 hunks)
• docs/conversion/sakai_25_1-25_2_oracle_conversion.sql (1 hunks)

🔇 Additional comments (3)

docs/conversion/sakai_25_1-25_2_mysql_conversion.sql (1)

19-30: LGTM!

The bulk insert logic correctly uses NOT EXISTS for idempotency and appropriately excludes helper and user template realms. The join strategy to propagate permissions to existing realms is sound.

docs/conversion/sakai_25_1-25_2_oracle_conversion.sql (2)

3-11: LGTM!

The MERGE statement properly handles idempotent insertion of the function, avoiding errors on re-run. This is the correct Oracle pattern for "insert if not exists".

---

27-39: LGTM!

The bulk insert logic is correct and idempotent. The NOT EXISTS clause prevents duplicates, and the realm exclusions are appropriate.

[st-manu]

is it necessary to address rabbit comments? they are meant to prevent errors if the scripts are executed twice, which isn't something that should really be considered, right? I'm going to mark both comments as resolved

[ottenhoff]

ignore the rabbit comments. this looks fine.