### Why is this Change Important & Necessary?
<!-- Include any GitHub issue that is fixed/closed using "Fixes
#<number>" or "Closes #<number>" syntax.
Alternately write "Partially addresses #<number>" or "Related to
#<number>" as appropriate. -->

Our email format, such as the subject and footer, can be found within
the web server and the course notification cron job script, which can be
troublesome to maintain as we continue to alter their contents. A more
maintainable approach would be to normalize the given footer or subject
contents before sending them, and not store redundant content in the
master database, as they can be implied from the original subject or the
potential term and course. Fixes #11734.

### What is the New Behavior?
<!-- Include before & after screenshots/videos if the user interface has
changed. -->

The subject and footer contents are now calculated within the email cron
job script and added to the finalized email before being delivered over
the network. You can verify the original email content within the master
database (`SELECT subject, body FROM emails ORDER by created DESC LIMIT
1;` and the finalized email content within the individual logs
(`/var/local/submitty/logs/emails/mailboxes/<email>/<id>[email protected]`).

```bash
root@ubuntu:/usr/local/submitty# cat /var/local/submitty/logs/emails/mailboxes/[email protected]/[email protected]
Content-Type: text/plain; charset=utf-8
TO: [email protected]
From: submitty@vagrant
reply-to: do-not-reply@vagrant
Subject: [Submitty sample]: New Announcement: Announcement


An Instructor or Teaching Assistant made an announcement in:
SAMPLE

Announcement

Announcement Content...

Author: Quinn I.
Click here for more info: http://localhost:1511/courses/s25/sample/forum/threads/10

--
NOTE: This is an automated email notification, which is unable to receive replies.
Please refer to the course syllabus for contact information for your teaching staff.
Update your email notification settings for this course here: http://localhost:1511/courses/s25/sample/notifications/settings

root@ubuntu:/usr/local/submitty# cat /var/local/submitty/logs/emails/mailboxes/[email protected]/[email protected]
Content-Type: text/plain; charset=utf-8
TO: [email protected]
From: submitty@vagrant
reply-to: do-not-reply@vagrant
Subject: [Submitty sample] Grade Released: Grades Released Homework


Your grade is now available for Grades Released Homework in course 
SAMPLE.

Click here for more info: http://localhost:1511/courses/s25/sample/gradeable/grades_released_homework

--
NOTE: This is an automated email notification, which is unable to receive replies.
Please refer to the course syllabus for contact information for your teaching staff.
Update your email notification settings for this course here: http://localhost:1511/courses/s25/sample/notifications/settings
```

Additionally, this pull request resolves the issue of invalid email
error logs displayed on the email status page, which currently shows a
site error. The current implementation attempts to access the email
error via array access, but it's an email entity; thus, the Doctrine
getter method should be used.

Before


![image](https://github.com/user-attachments/assets/b1007ebb-ed2a-4935-ad10-77fc27a1438f)

After


![image](https://github.com/user-attachments/assets/31ca5693-6a69-41f4-9e27-70e0050379aa)


### What steps should a reviewer take to reproduce or test the bug or
new feature?

1. Release an instructor/admin announcement or grade notifications (see
#10358).
2. Wait for the emails to be automatically released (100 per min. ~ not
applicable to grade notifications unless the cron job ran recently), or
run `python3 /usr/local/submitty/sbin/send_email.py` using the
`submitty_daemon` user as many times as needed.
3. Verify the original and finalized email content using the sources
noted above.
4. For testing the email errors, run `UPDATE emails SET error = 'x';`
and notice the difference in the email status page. Revert the change
via `UPDATE emails SET error = '';`

### Automated Testing & Documentation
<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

Email unit tests have been updated to ignore the footer content.

### Other information
<!-- Is this a breaking change?  
Does this PR include migrations to update existing installations?  
Are there security concerns with this PR? -->

N/A

### Why is this Change Important & Necessary?
<!-- Include any GitHub issue that is fixed/closed using "Fixes
#<number>" or "Closes #<number>" syntax.
Alternately write "Partially addresses #<number>" or "Related to
#<number>" as appropriate. -->

The initial sample data insertion for gradeables doesn't account for the
existing notification state. Therefore, all gradeables released in the
past will have their release flag initialized as false by default,
causing the first cron job script run to release them in a large batch
for new system installations. Related to #10358.


![notification](https://github.com/user-attachments/assets/6b72ea9d-169c-4837-9844-6bed30432f0c)


### What is the New Behavior?
<!-- Include before & after screenshots/videos if the user interface has
changed. -->

The installation scripts related to inserting electronic gradeable data
for the testing courses will have the notification state set to true if
the gradeable release date is in the past, similar to how the initial
migration command handled it.

### What steps should a reviewer take to reproduce or test the bug or
new feature?

1. Visit a course database through the CLI to reset notification states
or skip the following steps through verification via `vagrant up`
 - `$ su postgres`
 - `$ psql`
- `$ \c submitty_f25_sample` (update `f25` to suit your existing system)
- `$ UPDATE electronic_gradeable_version SET g_notification_sent =
FALSE;`
3. Run the `recreate_sample_courses` command as the root user
4. Using the initial steps in step 1, visit the testing database and run
the following command to ensure the script worked as intended.
- `SELECT * FROM electronic_gradeable_version WHERE g_notification_sent
IS TRUE;` (should be non-empty)

### Automated Testing & Documentation
<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

N/A

### Other information
<!-- Is this a breaking change?  
Does this PR include migrations to update existing installations?  
Are there security concerns with this PR? -->

N/A

<!-- Include any GitHub issue that is fixed/closed using "Fixes
Alternately write "Partially addresses #<number>" or "Related to

The initial sample data insertion for gradeables doesn't account for the
existing notification state. Therefore, all gradeables released in the
past will have their release flag initialized as false by default,
causing the first cron job script run to release them in a large batch
for new system installations. Related to #10358.

![notification](https://github.com/user-attachments/assets/6b72ea9d-169c-4837-9844-6bed30432f0c)

<!-- Include before & after screenshots/videos if the user interface has
changed. -->

The installation scripts related to inserting electronic gradeable data
for the testing courses will have the notification state set to true if
the gradeable release date is in the past, similar to how the initial
migration command handled it.

new feature?

1. Visit a course database through the CLI to reset notification states
or skip the following steps through verification via `vagrant up`
 - `$ su postgres`
 - `$ psql`
- `$ \c submitty_f25_sample` (update `f25` to suit your existing system)
- `$ UPDATE electronic_gradeable_version SET g_notification_sent =
FALSE;`
3. Run the `recreate_sample_courses` command as the root user
4. Using the initial steps in step 1, visit the testing database and run
the following command to ensure the script worked as intended.
- `SELECT * FROM electronic_gradeable_version WHERE g_notification_sent
IS TRUE;` (should be non-empty)

<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

N/A

<!-- Is this a breaking change?
Does this PR include migrations to update existing installations?
Are there security concerns with this PR? -->

N/A

### Why is this Change Important & Necessary?
<!-- Include any GitHub issue that is fixed/closed using "Fixes
#<number>" or "Closes #<number>" syntax.
Alternately write "Partially addresses #<number>" or "Related to
#<number>" as appropriate. -->

Notifications for grade releases were originally introduced within
#10358. Still, students have asked for more types of notifications tied
to gradeables, such as receiving one when submissions are open for a
given gradeable.

### What is the New Behavior?
<!-- Include before & after screenshots/videos if the user interface has
changed. -->

This extends the existing hourly cron job to check for electronic
gradeables with pending submission-related notifications ready for
release to all active course users. By default, site notifications are
enabled, while email notifications are disabled to help minimize email
fatigue. For assignments with prerequisites, such as a crash course, the
student will only be notified if the minimum autograding score for the
gradeable dependency is met.

<img width="1587" height="281" alt="image"
src="https://github.com/user-attachments/assets/ce779258-a6f4-4200-8458-d5af01b95bb2"
/>


This is the site notification, which compacts the due date and late day
information into a single line.

<img width="1664" height="312" alt="image"
src="https://github.com/user-attachments/assets/694357ec-0225-47a7-868e-7bb348c15f85"
/>


This is the email notification, including all relevant information on a
separate line for readability.

```
[Subject]
Submissions Open: release_testing
[Content]
Submissions are now being accepted for "release_testing" in course SAMPLE.

Deadline: 2025-08-01 @ 09:13 AM
Late Days: 2 remaining, 5 allowed

Click here for more info: http://localhost:1511/courses/f25/sample/gradeable/release_testing
```

Additionally, the Email Status page may have multiple entries for a
gradeable as the content includes the unique students' remaining late
days, along with the applicable late days, and deadline for the
assignment.

<img width="1575" height="167" alt="image"
src="https://github.com/user-attachments/assets/8a1b0c91-e345-4531-a3af-47a69a5924e0"
/>


### What steps should a reviewer take to reproduce or test the bug or
new feature?

1. Run the required migration via `submitty_install`
2. Create a new electronic gradeable for an active course
4. Release the electronic gradeable for students to submit
5. Run `sudo -u "submitty_daemon" python3 sbin/send_notification.py`
6. Visit the notification tab (email setting is off by default; thus,
this should be manually set for testing)

### Automated Testing & Documentation
<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

I will create an issue for us to introduce a new Cypress file,
`notifications.spec.js`, within the `Cypress-Feature` workflow to handle
all types of notifications, including verification of their release
through the cron job script.

### Other information
<!-- Is this a breaking change?  
Does this PR include migrations to update existing installations?  
Are there security concerns with this PR? -->

Existing variable and function names related to score notifications have
been refactored for improved readability and to better support
integration of additional notification types.

---------

Co-authored-by: Barb Cutler <[email protected]>
Co-authored-by: Barb Cutler <Barb Cutler>

### Why is this Change Important & Necessary?

Students previously had to manually click a notification or visit the
notification page to mark gradeable release and grade release
notifications when visiting the respective page via a link, which is a
poor-quality-of-life experience.

### What is the New Behavior?

When a student visits a gradeable page, any unseen grading notifications
for that gradeable (submission open or grade release) are automatically
marked as seen in a single database update.

### What steps should a reviewer take to reproduce or test the bug or
new feature?

1. Run the respective course migration.
2. Trigger a gradeable release or grade release notification via
`send_notification.py` (`udo -u "submitty_daemon" python3
sbin/send_notification.py`: #11897 and #10358 have more in-depth
explanations).
3. Log in as the notified student (notification bell should show
unread).
4. Navigate to the gradeable page.
5. Verify the notification is now marked as seen (bell clears,
notification panel shows read).

### Automated Testing & Documentation
<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

Unit tests have been added, but an issue will be made to extend this
notification feature to end-to-end testing coverage.

### Other information

N/A

---------

Co-authored-by: Justin Manion <[email protected]>

…itty#12658)

### Why is this Change Important & Necessary?

Students previously had to manually click a notification or visit the
notification page to mark gradeable release and grade release
notifications when visiting the respective page via a link, which is a
poor-quality-of-life experience.

### What is the New Behavior?

When a student visits a gradeable page, any unseen grading notifications
for that gradeable (submission open or grade release) are automatically
marked as seen in a single database update.

### What steps should a reviewer take to reproduce or test the bug or
new feature?

1. Run the respective course migration.
2. Trigger a gradeable release or grade release notification via
`send_notification.py` (`udo -u "submitty_daemon" python3
sbin/send_notification.py`: Submitty#11897 and Submitty#10358 have more in-depth
explanations).
3. Log in as the notified student (notification bell should show
unread).
4. Navigate to the gradeable page.
5. Verify the notification is now marked as seen (bell clears,
notification panel shows read).

### Automated Testing & Documentation
<!-- Is this feature sufficiently tested by unit tests and end-to-end
tests?
If this PR does not add/update the necessary automated tests, write a
new GitHub issue and link it below.
Is this feature sufficiently documented on submitty.org?
Link related PRs or new GitHub issue to update documentation. -->

Unit tests have been added, but an issue will be made to extend this
notification feature to end-to-end testing coverage.

### Other information

N/A

---------

Co-authored-by: Justin Manion <[email protected]>