diff --git a/.env.example b/.env.example
index 3b3995570..86969f78c 100644
--- a/.env.example
+++ b/.env.example
@@ -20,3 +20,6 @@ JWT_SECRET=
#Crowdin
CROWDIN_PERSONAL_TOKEN=
CROWDIN_PROJECT_ID=
+
+# For dmptool-narrative-generator service
+NARRATIVE_SERVICE_URL=http://narrative:3030
\ No newline at end of file
diff --git a/CHANGELOG.md b/CHANGELOG.md
index e73498b97..8ea4eb811 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,4 +1,50 @@
### Added
+- Added missing `slug` property to all `tags` in the graphQL queries
+- Added guidance text from the backend to the Question Answer page [#580]
+- Added new, shared `ProjectRoles` component that generates the list of Project Roles for both the Project Member Search and Edit Project member pages [#945]
+- Added `Help text` fields to `Description, Repositories, Metadata Standards, License, Access Level and Custom Text` fields in Research Output question type [#970]
+- Added customizable `Initial Access Level` field to the QuestionAdd page for Research Outputs question type [#969]
+- Added new `Start DMP` page at `projects/[projectId]/dmp/start` to direct user to create new plan or upload existing [#956]
+- Added `autosave` back to the `PlanOverviewQuestionpage` [#944]
+- Hooked up the `Download plan` page and added a `download-narrative` api endpoint [#313]
+
+### Updated
+- Guidance page updates [#934]
+ - Hooked up `admin/guidance` page that lists all the `guidance groups` and offers `Create Guidance Group` button and edit options for existing Guidance Groups [#934]
+ - Hooked up `admin/guidance/groups/create`, and created a new page for `admin/guidance/groups/[groupId]` to include guidance text for all tags in one place and to allow
+ publishing at that level [#934]
+ - Added skeleton for loading of TinyMCEEditor. Especially needed it for the new Guidance Group Edit page, since we are loading so many at once [#934]
+ - Updated stripHtmlTags to include replacement of ` ` [#934]
+ - Updated `DashboardListItem` to have the option to be fully clickable. This makes clicking on smaller devices easier [#934]
+- Made improvements to auth handling in `middleware` and `authHelper.ts` [#1035]
+- Made text changes to upcoming blog posts [#989]
+- For Research Outputs, updated repositories and metadata standards fields to be automatically enabled when user selects custom ones [#943]
+- Updated Licenses and Output Types to use label "Use custom list" [#943]
+- Updated `Output Types` in static `Research Outputs` table [#962]
+ - Added a description field to custom types
+ - Added tooltip icons next to each default output type with the description
+ - Updated Output Types component to behave like the Licenses component, where users can delete default types
+ - Updated unit test
+- Improved project creation steps by updating pages in the flow (header, home, plan dashboard, create project details,and funding search) to help users in creating a plan [#956]
+- Updated Project Details subdomains field to only display once a user selects a research domain [#947]
+- Updated `Remove` buttons to be `secondary` buttons, rather than `red` [#964]
+
+### Fixed
+- For Research Outputs, fixed custom Licenses select field to display selected value [#943]
+- Fixed issue where custom repos and standards were not saving in state [#943]
+
+### Removed
+- Removed Research Outputs section from the plan overview page
+- Removed reference to the old `outputs` association on the graphQL query
+- Removed `Description` fields for Research Output question fields [#970]
+- Removed `scrollToTop` from `Template Create` page [#950]
+
+### Chore
+- Updated `next` version to `15.5.7` due to vulnerability
+- Ran `npm audit fix` to address `glob` vulnerability and `js-yaml` vulnerability
+====================================================================================================================================
+## All changes above the line happened after the merge to the main branch on Nov 3, 2025
+### Added
- Added user's org as a filter for the Plan Create (`projects/9/dmp/create`) page, and updated filter text to include `organization` [#735]
- Fixed filtering on the Plan Create (`projects/9/dmp/create`) page so that it takes search term into consideration when used with checked filters [#735]
- Moved checkbox filters below search field to make them more noticeable [#735]
@@ -6,7 +52,7 @@
- Removed `Title` field from TinyMCEEditor's `Insert Link` form, and made `new window` the default for `Open link in...` [#874]
- Integrated related works UI with GraphQL backend.
- Added updated description that includes template source, affiliation name, version and publish date on the `Plan Overview` page [#621]
-
+- Added plan feedback status (Feedback received, Feedback requested, No feedback) to the `Plan Overview` page [#411]
### Updated
- Updated `TinyMCEEditor` to allow users to change text color and background color.
diff --git a/app/[locale]/__tests__/page.spec.tsx b/app/[locale]/__tests__/page.spec.tsx
index 845303667..e8aca56ce 100644
--- a/app/[locale]/__tests__/page.spec.tsx
+++ b/app/[locale]/__tests__/page.spec.tsx
@@ -10,37 +10,33 @@ describe('Home Page', () => {
render();
// Check for the heading
- expect(screen.getByRole('heading', { level: 1 })).toHaveTextContent('Home Page');
+ expect(screen.getByRole('heading', { level: 1 })).toHaveTextContent('title');
// Check for the PageLinkCard sections
- expect(screen.getByText('Create & Manage')).toBeInTheDocument();
- expect(screen.getByText('Account & Administration')).toBeInTheDocument();
+ expect(screen.getByText('createAndManage.title')).toBeInTheDocument();
+ expect(screen.getByText('createAndManage.description')).toBeInTheDocument();
+ expect(screen.getByText('accountAndAdmin.title')).toBeInTheDocument();
+ expect(screen.getByText('accountAndAdmin.description')).toBeInTheDocument();
// Check for section descriptions
- expect(screen.getByText('Create new templates and projects')).toBeInTheDocument();
- expect(screen.getByText('Manage your account and access admin features')).toBeInTheDocument();
+ expect(screen.getByText('sections.templateManagement.title')).toBeInTheDocument();
+ expect(screen.getByText('sections.templateManagement.description')).toBeInTheDocument();
+ expect(screen.getByText('sections.planDashboard.title')).toBeInTheDocument();
+ expect(screen.getByText('sections.planDashboard.description')).toBeInTheDocument();
+ expect(screen.getByText('sections.accountSettings.title')).toBeInTheDocument();
+ expect(screen.getByText('sections.accountSettings.description')).toBeInTheDocument();
+ expect(screen.getByText('sections.adminOverview.title')).toBeInTheDocument();
+ expect(screen.getByText('sections.adminOverview.description')).toBeInTheDocument();
// Check for all links to be present
const allLinks = screen.getAllByRole('link');
expect(allLinks).toHaveLength(4);
-
- expect(screen.getByText('Template Management')).toBeInTheDocument();
- expect(screen.getByText('Project Management')).toBeInTheDocument();
- expect(screen.getByText('Account Settings')).toBeInTheDocument();
- expect(screen.getByText('Admin Overview')).toBeInTheDocument();
-
- expect(screen.getByText('Create and manage templates (Must be Admin to access)')).toBeInTheDocument();
- expect(screen.getByText('Create and manage projects')).toBeInTheDocument();
- expect(screen.getByText('View and manage your account')).toBeInTheDocument();
- expect(screen.getByText('Access administrative functions')).toBeInTheDocument();
-
-
- const templateManagementLink = screen.getByText('Template Management').closest('a');
- const projectManagementLink = screen.getByText('Project Management').closest('a');
- const accountSettingsLink = screen.getByText('Account Settings').closest('a');
- const adminOverviewLink = screen.getByText('Admin Overview').closest('a');
+ const templateManagementLink = screen.getByText('sections.templateManagement.title').closest('a');
+ const projectManagementLink = screen.getByText('sections.planDashboard.title').closest('a');
+ const accountSettingsLink = screen.getByText('sections.accountSettings.title').closest('a');
+ const adminOverviewLink = screen.getByText('sections.adminOverview.title').closest('a');
expect(templateManagementLink).toHaveAttribute('href', '/en-US/template');
expect(projectManagementLink).toHaveAttribute('href', '/en-US/projects');
diff --git a/app/[locale]/admin/guidance/__mocks__/mockGuidanceGroupsData.json b/app/[locale]/admin/guidance/__mocks__/mockGuidanceGroupsData.json
new file mode 100644
index 000000000..ad38ab9f5
--- /dev/null
+++ b/app/[locale]/admin/guidance/__mocks__/mockGuidanceGroupsData.json
@@ -0,0 +1,256 @@
+{
+ "guidanceGroups": [
+ {
+ "__typename": "GuidanceGroup",
+ "id": 2397,
+ "name": "CDL Guidance Group",
+ "description": "This is the guidance group for all CDL guidance",
+ "latestPublishedVersion": "1",
+ "latestPublishedDate": "2025-11-26 19:43:42",
+ "guidance": [
+ {
+ "__typename": "Guidance",
+ "tagId": 2,
+ "guidanceText": "
Give a summary of the data you will collect or create, noting the content, coverage and data type, e.g., tabular data, survey data, experimental measurements, models, software, audiovisual data, physical samples, etc.
Consider how your data could complement and integrate with existing data, or whether there are any existing data or methods that you could reuse.
Indicate which data are of long-term value and should be shared and/or preserved.
If purchasing or reusing existing data, explain how issues such as copyright and IPR have been addressed. You should aim to minimize any restrictions on the reuse (and subsequent sharing) of third-party data.
Clearly note what format(s) your data will be in, e.g., plain text (.txt), comma-separated values (.csv), geo-referenced TIFF (.tif, .tfw).
Explain why you have chosen certain formats. Decisions may be based on staff expertise, a preference for open formats, the standards accepted by data centers, or widespread usage within a given community.
Using standardized, interchangeable, or open formats ensures the long-term usability of data; these are recommended for sharing and archiving.
Note what volume of data you will create in MB/GB/TB. Indicate the proportions of raw data, processed data, and other secondary outputs (e.g., reports).
Consider the implications of data volumes in terms of storage, access, and preservation. Do you need to include additional costs?
Consider whether the scale of the data will pose challenges when sharing or transferring data between sites; if so, how will you address these challenges?
Outline how the data will be collected and processed. This should cover relevant standards or methods, quality assurance, and data organisation.
Indicate how the data will be organized during the project, mentioning, e.g., naming conventions, version control, and folder structures. Consistent, well-ordered research data will be easier to find, understand, and reuse.
Explain how the consistency and quality of data collection will be controlled and documented. This may include processes such as calibration, repeat samples, or measurements, standardized data capture, data entry validation, peer review of data, or representation with controlled vocabularies.
What metadata will be provided to help others identify and discover the data?
Researchers are strongly encouraged to use community metadata standards where these are in place. The Research Data Alliance offers a Directory of Metadata Standards. Data repositories may also provide guidance about appropriate metadata standards.
Consider what other documentation is needed to enable reuse. This may include information on the methodology used to collect the data, analytical and procedural information, definitions of variables, units of measurement, any assumptions made, the format and file type of the data, and software used to collect and/or process the data.
Consider how you will capture this information and where it will be recorded, e.g., in a database with links to each item, in a \"readme\" text file, in file headers, etc.
Investigators carrying out research involving human participants should request consent to preserve and share the data. Do not just ask for permission to use the data in your study or make unnecessary promises to delete it at the end.
Consider how you will protect the identity of participants, e.g., via anonymization or using managed access procedures.
Ethical issues may affect how you store and transfer data, who can see/use it, and how long it is kept. You should demonstrate that you are aware of this and have planned accordingly.
If you are collecting Traditional Knowledge as part of the project it is advisable to apply TK Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
If you are generating data derived from Indigenous lands and/or waters, it is advisable to use BC Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
State who will own the copyright and IPR of any existing data as well as new data that you will generate. For multi-partner projects, IPR ownership should be covered in the consortium agreement.
Outline any restrictions needed on data sharing, e.g., to protect proprietary or patentable data.
If you are collecting Traditional Knowledge as part of the project it is advisable to apply TK Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
If you are generating data derived from Indigenous lands and/or waters, it is advisable to use TK Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
Describe where the data will be stored and backed up during the course of research activities. This may vary if you are doing fieldwork or working across multiple sites so explain each procedure.
Identify who will be responsible for backup and how often this will be performed. The use of robust, managed storage with automatic backup, for example, that provided by university IT teams, is preferable. Storing data on laptops, computer hard drives, or external storage devices alone is very risky.
Also consider data security, particularly if your data is sensitive e.g., detailed personal data, politically sensitive information or trade secrets. Note the main risks and how these will be managed. Also note whether any institutional data security policies are in place.
Identify any formal standards that you will comply with, e.g., ISO 27001. See the DCC Briefing Paper on Information Security Management - ISO 27000 and UK Data Service guidance on data security.
How will you share the data, e.g., deposit in a data repository, use a secure data service, handle data requests directly, or use another mechanism? The methods used will depend on a number of factors such as the type, size, complexity, and sensitivity of the data.
When will you make the data available? Research funders expect timely release. They typically allow embargoes but not prolonged exclusive use.
Who will be able to use your data? If you need to restrict access to certain communities or apply data sharing agreements, explain why.
Consider strategies to minimize restrictions on sharing. These may include anonymizing or aggregating data, gaining participant consent for data sharing, gaining copyright permissions, and agreeing a limited embargo period.
How might your data be reused in other contexts? Where there is potential for reuse, you should use standards and formats that facilitate this, and ensure that appropriate metadata is available online so your data can be discovered. Persistent identifiers should be applied so people can reliably and efficiently find your data. They also help you to track citations and reuse.
Where will the data be deposited? If you do not propose to use an established repository, the data management plan should demonstrate that the data can be curated effectively beyond the lifetime of the grant.
It helps to show that you have consulted with the repository to understand their policies and procedures, including any metadata standards, and costs involved.
An international list of data repositories is available via re3data and some universities or publishers provide lists of recommendations, e.g., PLOS ONE recommended repositories.
Outline the plans for data sharing and preservation - how long will the data be retained and where will it be archived? Will additional resources be needed to prepare data for deposit or meet any charges from data repositories?
Outline the roles and responsibilities for all activities, e.g., data capture, metadata production, data quality, storage and backup, data archiving, and data sharing. Individuals should be named where possible.
For collaborative projects you should explain the coordination of data management responsibilities across partners.
Carefully consider and justify any resources needed to deliver the plan. These may include storage costs, hardware, staff time, costs of preparing data for deposit, and repository charges.
Outline any relevant technical expertise, support, and training that is likely to be required and how it will be acquired.
If you are not depositing in a data repository, ensure you have appropriate resources and systems in place to share and preserve the data. See UK Data Service guidance on costing data management.
Consider whether there are any existing procedures that you can base your approach on. If your group/department has local guidelines that you work to, point to them here.
List any other relevant funder, institutional, departmental, or group policies on data management, data sharing, and data security.
Describe where the data will be stored and backed up during the course of research activities. This may vary if you are doing fieldwork or working across multiple sites so explain each procedure.
Identify who will be responsible for backup and how often this will be performed. The use of robust, managed storage with automatic backup, for example, that provided by university IT teams, is preferable. Storing data on laptops, computer hard drives, or external storage devices alone is very risky.
See UK Data Service Guidance on data storage or DataONE Best Practices for storage.
Also consider data security, particularly if your data is sensitive, e.g., detailed personal data, politically sensitive information, or trade secrets. Note the main risks and how these will be managed. Also note whether any institutional data security policies are in place.
Identify any formal standards that you will comply with, e.g., ISO 27001. See the DCC Briefing Paper on Information Security Management - ISO 27000 and UK Data Service guidance on data security.
Outline the plans for data sharing and preservation - how long will the data be retained and where will it be archived? Will additional resources be needed to prepare data for deposit or meet any charges from data repositories?
Outline how the data will be collected and processed. This should cover relevant standards or methods, quality assurance, and data organization.
Indicate how the data will be organized during the project, mentioning, e.g., naming conventions, version control, and folder structures. Consistent, well-ordered research data will be easier to find, understand, and reuse.
Explain how the consistency and quality of data collection will be controlled and documented. This may include processes such as calibration, repeat samples or measurements, standardized data capture, data entry validation, peer review of data, or representation with controlled vocabularies.
Clearly note what format(s) your data will be in, e.g., plain text (.txt), comma-separated values (.csv), geo-referenced TIFF (.tif, .tfw).
Explain why you have chosen certain formats. Decisions may be based on staff expertise, a preference for open formats, the standards accepted by data centers or widespread usage within a given community.
Using standardized, interchangeable, or open formats ensures the long-term usability of data; these are recommended for sharing and archiving.
Outline the roles and responsibilities for all activities, e.g., data capture, metadata production, data quality, storage and backup, data archiving, and data sharing. Individuals should be named where possible.
For collaborative projects you should explain the coordination of data management responsibilities across partners.
Investigators carrying out research involving human participants should request consent to preserve and share the data. Do not just ask for permission to use the data in your study or make unnecessary promises to delete it at the end.
Consider how you will protect the identity of participants, e.g., via anonymization or using managed access procedures.
Ethical issues may affect how you store and transfer data, who can see/use it, and how long it is kept. You should demonstrate that you are aware of this and have planned accordingly.
If you are collecting Traditional Knowledge as part of the project, it is advisable to apply TK Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
If you are generating data derived from Indigenous lands and/or waters, it is advisable to use BC Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
State who will own the copyright and IPR of any existing data as well as new data that you will generate. For multi-partner projects, IPR ownership should be covered in the consortium agreement.
Outline any restrictions needed on data sharing, e.g., to protect proprietary or patentable data.
If you are collecting Traditional Knowledge as part of the project it is advisable to apply TK Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
If you are generating data derived from Indigenous lands and/or waters, it is advisable to use BC Notices and engage with communities around the application of Labels to support ongoing connection to inform future data management.
Consider whether there are any existing procedures that you can base your approach on. If your group/department has local guidelines that you work to, point to them here.
List any other relevant funder, institutional, departmental, or group policies on data management, data sharing, and data security.
Carefully consider and justify any resources needed to deliver the plan. These may include storage costs, hardware, staff time, costs of preparing data for deposit, and repository charges.
Outline any relevant technical expertise, support, and training that is likely to be required and how it will be acquired.
If you are not depositing in a data repository, ensure you have appropriate resources and systems in place to share and preserve the data. See UK Data Service guidance on costing data management.
Where will the data be deposited? If you do not propose to use an established repository, the data management plan should demonstrate that the data can be curated effectively beyond the lifetime of the grant.
It helps to show that you have consulted with the repository to understand their policies and procedures, including any metadata standards, and costs involved.
An international list of data repositories is available via re3data and some universities or publishers provide lists of recommendations, e.g., PLOS ONE recommended repositories.
How will you share the data, e.g., deposit in a data repository, use a secure data service, handle data requests directly, or use another mechanism? The methods used will depend on various factors such as the type, size, complexity, and sensitivity of the data.
When will you make the data available? Research funders expect timely release. They typically allow embargoes but not prolonged exclusive use.
Who will be able to use your data? If you need to restrict access to certain communities or apply data sharing agreements, explain why.
Consider strategies to minimize restrictions on sharing. These may include anonymizing or aggregating data, gaining participant consent for data sharing, gaining copyright permissions, and agreeing a limited embargo period.
How might your data be reused in other contexts? Where there is potential for reuse, you should use standards and formats that facilitate this, and ensure that appropriate metadata is available online so your data can be discovered. Persistent identifiers should be applied so people can reliably and efficiently find your data. They also help you to track citations and reuse.
What metadata will be provided to help others identify and discover the data?
Researchers are strongly encouraged to use community metadata standards where these are in place. The Research Data Alliance offers a Directory of Metadata Standards. Data repositories may also provide guidance about appropriate metadata standards.
Consider what other documentation is needed to enable reuse. This may include information on the methodology used to collect the data, analytical and procedural information, definitions of variables, units of measurement, any assumptions made, the format and file type of the data and software used to collect and/or process the data.
Consider how you will capture this information and where it will be recorded, e.g., in a database with links to each item, in a \"readme\" text file, in file headers, etc.
Note what volume of data you will create in MB/GB/TB. Indicate the proportions of raw data, processed data, and other secondary outputs (e.g., reports).
Consider the implications of data volumes in terms of storage, access, and preservation. Do you need to include additional costs?
Consider whether the scale of the data will pose challenges when sharing or transferring data between sites; if so, how will you address these challenges?
Give a summary of the data you will collect or create, noting the content, coverage and data type, e.g., tabular data, survey data, experimental measurements, models, software, audiovisual data, physical samples, etc.
Consider how your data could complement and integrate with existing data, or whether there are any existing data or methods that you could reuse.
Indicate which data are of long-term value and should be shared and/or preserved.
If purchasing or reusing existing data, explain how issues such as copyright and IPR have been addressed. You should aim to minimize any restrictions on the reuse (and subsequent sharing) of third-party data.