DT-3091: Update freemarker template accessors for record model class

[rushtong]

Addresses

https://broadworkbench.atlassian.net/browse/DT-3091

Summary

In #2830, we converted the model class used in several email templates to a record class. In local functional and unit testing, record class field accessors work as expected. In production, we now see a template processing exception on these model class fields:

freemarker.core.NonStringOrTemplateOutputException: For "${...}" content: Expected a string or something automatically convertible to string (number, date or boolean), or "template output" , but this has evaluated to a method+sequence (wrapper: f.e.b.SimpleMethodModel):
==> dataset.identifier  [in template "researcher-dar-approved.ftl" at line 43, column 39]

----
Tip: Maybe using obj.something() instead of obj.something will yield the desired value
----

----
FTL stack trace ("~" means nesting-related):
	- Failed at: ${dataset.identifier}  [in template "researcher-dar-approved.ftl" at line 43, column 37]
----

This PR migrates all usages to method based field accessors for the templates that use a DatasetMailDTO model class.

Screens

Researcher DAR Approved (email type 8) with null data location

---

Researcher DAR Approved (email type 8) with valid data location

---

Data Custodian Approval (email type 7)

---

Researcher PR Approved (email type 24)

---

DAC RADAR Approval (email type 32)

---

Have you read CONTRIBUTING.md lately? If not, do that first.

• Label PR with a Jira ticket number and include a link to the ticket
• Label PR with a security risk modifier [no, low, medium, high]
• PR describes scope of changes
• Get a minimum of one thumbs worth of review, preferably two if enough team members are available
• Get PO sign-off for all non-trivial UI or workflow changes
• Verify all tests go green
• Test this change deployed correctly and works on dev environment after deployment

[Copilot]

Pull request overview

This PR updates FreeMarker email templates to use method-style accessors for DatasetMailDTO fields after that model was converted to a Java record, fixing production template processing errors where record component access was being treated as a method reference rather than a string value.

Changes:

• Update dataset.identifier → dataset.identifier() in affected templates.
• Update dataset.name → dataset.name() in affected templates.
• Update dataset.dataLocationUrl checks/usage → dataset.dataLocationUrl() in researcher-facing templates.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/main/resources/freemarker/researcher-progress-report-approved.ftl	Switch dataset field reads to record component method calls (incl. dataLocationUrl()).
src/main/resources/freemarker/researcher-dar-approved.ftl	Switch dataset field reads to record component method calls (incl. dataLocationUrl()).
src/main/resources/freemarker/data-custodian-approval.html	Switch dataset field reads to record component method calls for custodian email.
src/main/resources/freemarker/dac-radar-approved.html	Switch dataset field reads to record component method calls for DAC RADAR email.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[fboulnois]

Good catch 👍

[fboulnois]

Can we add a test for this behavior so we do not see regressions?

[rushtong]

Can we add a test for this behavior so we do not see regressions?

I'm unable to reproduce the prod behavior locally or in a unit test. In fact, template processing in unit tests work for both cases. The only freemarker configuration we have is here: https://github.com/broadinstitute/terra-helmfile/blob/b7ffb7e6fd7c3bc0556b640e6cadb49a0628bf1e/charts/consent/templates/_consent.yaml.tpl#L63 and that does not explain why prod would behave differently than a local instance.