Hotfixes release v2025.08.14

[bjester]

Summary

PR	Issues	Category	QA Focus
#5083	#5063	Enhancement	Trigger data export from Account settings
#5088	#5057, #5058, #5088	Enhancement	Interact and provide feedback on Search recommendations
#5097	#5124	Enhancement	(skip)
#5103	#4878	Enhancement	Publish a channel
#5106	#5093	Enhancement	Visual check of modal headers
#5125	#5111	Enhancement	Change folder language before using import modal for importing search recommendations
#5126	#5116	Enhancement	Browse search recommendations
#5128	#5042	Enhancement	Edit a channel and resources with grade levels
#5144	#5115	Enhancement	(skip)
#5149	N/A	Enhancement	Preview a resource
#5155	#5131, #5146, #2178	Enhancement	(skip)
#5248	#5069	Enhancement	Deploy staged channel
#5253	#5211, #4086	Enhancement	Review selected resources in import modal
#5255	N/A	Enhancement	Review selected resources in import modal
#5261	N/A	Enhancement	Browse search recommendations
#5040	N/A	Bug fix	N/A
#5104	#4073	Bug fix	View channel details
#5147	#5065	Bug fix	N/A
#5102	#5068	Tech Debt	N/A
#4902	N/A	DevOps	N/A
#5105	N/A	DevOps	N/A
#5134	N/A	DevOps	N/A
#5143	N/A	DevOps	N/A
#5177	N/A	DevOps	N/A
#5190	N/A	DevOps	N/A
#5196	N/A	DevOps	N/A
#5197	N/A	DevOps	N/A
#5254	N/A	DevOps	N/A
#5293	N/A	DevOps	N/A

Dependency PRs

PR	Category
#5076	Dependency
#5084	Dependency
#5085	Dependency
#5086	Dependency
#5096	Dependency
#5098	Dependency
#5099	Dependency
#5108	Dependency
#5113	Dependency
#5117	Dependency
#5119	Dependency
#5120	Dependency
#5121	Dependency
#5136	Dependency
#5137	Dependency
#5139	Dependency
#5141	Dependency
#5148	Dependency
#5152	Dependency
#5154	Dependency
#5164	Dependency
#5179	Dependency
#5181	Dependency
#5182	Dependency
#5198	Dependency
#5199	Dependency
#5200	Dependency
#5201	Dependency
#5202	Dependency
#5203	Dependency
#5204	Dependency
#5205	Dependency
#5207	Dependency
#5210	Dependency
#5223	Dependency
#5224	Dependency
#5226	Dependency
#5238	Dependency
#5239	Dependency
#5256	Dependency

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

To fix the problem, add a permissions block to the workflow file .github/workflows/call-contributor-issue-comment.yml. This block should be placed at the root level (above jobs:) to apply to all jobs in the workflow, unless a job overrides it. The permissions should be set to the minimum required for the workflow to function. Since the workflow is triggered by issue_comment and likely interacts with issues, a minimal starting point would be:

permissions:
issues: writecontents: read

This grants read access to repository contents and write access to issues, which is typically sufficient for workflows responding to issue comments. If the workflow requires additional permissions (e.g., for pull requests), those can be added as needed. The change should be made at the top of the file, after the name: and before the on: block.

To fix the problem, add a permissions block to the workflow or job definition to explicitly set the minimum required permissions for the GITHUB_TOKEN. Since this workflow only calls a reusable workflow and does not perform any direct actions, the safest minimal permissions are contents: read. This can be set at the workflow level (applies to all jobs) or at the job level (applies only to the specific job). The best practice is to set it at the workflow level unless a job requires different permissions. Edit the .github/workflows/call-manage-issue-header.yml file to add the following block after the name: line and before the on: block:

permissions:
contents: read

No additional imports, methods, or definitions are needed.

---

To fix the problem, you should add a permissions block to the workflow file .github/workflows/community-contribution-labeling.yml. The block can be added at the root level (applies to all jobs) or at the job level (applies only to the specific job). Since this workflow only contains a single job that calls a reusable workflow, the best practice is to add the permissions block at the root level, immediately after the name and before the on key. The minimal starting point is to set all permissions to read unless the workflow requires write access to specific resources. For workflows that label issues, you typically need issues: write and possibly contents: read. Therefore, add:

permissions:
contents: readissues: write

immediately after the name line.

To fix the problem, add a permissions block to the workflow file. The block should be placed at the top level (applies to all jobs) or at the job level (for each job that needs specific permissions). The minimal and safest starting point is permissions: {} (no permissions), but most workflows require at least contents: read to check out code. Since this workflow uses actions/checkout and does not appear to require write access, set permissions: contents: read at the top level, which will apply to all jobs unless overridden. This change should be made near the top of the file, after the name: and before on:.

---

To fix the problem, add a permissions block to the workflow to explicitly set the minimum required permissions for the GITHUB_TOKEN. Since the workflow only performs linting and pre-commit checks, it likely only needs read access to repository contents. The best way to fix this is to add permissions: contents: read at the top level of the workflow file, just below the name field and before the on block. This will apply the least privilege principle to all jobs in the workflow, unless a job overrides it with its own permissions block.

---

To fix the problem, add a permissions block to the workflow file. The best practice is to set the minimal permissions required for the workflow to function. Since the job is using a reusable workflow, and we do not know the exact permissions required by unassign-inactive-issues.yaml, the safest minimal starting point is to set permissions: read-all at the workflow level. This can be further restricted if the reusable workflow's documentation specifies more limited needs (e.g., only issues: write). The permissions block should be added at the top level of the workflow file, after the name and run-name fields and before the on field.

---

To fix the problem, add a permissions block to the workflow or the specific job to explicitly set the minimal required permissions for the GITHUB_TOKEN. Since the job is calling a reusable workflow that likely needs to update a spreadsheet and possibly interact with pull requests, a safe minimal starting point is to grant contents: read and pull-requests: write permissions. This should be added at the job level (under call-update-spreadsheet:) or at the root of the workflow (applies to all jobs). The best practice is to add it at the job level for clarity and least privilege. No other changes are needed.

---

To avoid revealing potentially sensitive internal information, the handler for KeyError in the api_create_channel_endpoint function should not return the string representation of the exception object as part of the HTTP error response. Instead, it should return a generic error message (e.g., "Required attribute missing from data"), optionally logging the actual exception server-side for debugging. This involves editing lines 224–227 to remove str(e) from the response message, and possibly adding a server-side logging call for the exception.

• Change the return value of the except KeyError as e: block to a generic message: "Required attribute missing from data".
• Optionally, log the error (using logging.exception or similar).
• Do not include the missing key name or stringified exception in the HTTP response body.

To fix the problem, the function should return a generic error message to the client when a KeyError is caught, rather than interpolating the exception message which can leak information about internal variable names or input data structure. The actual error details (including the exception message) should be recorded in logs and/or sent to Sentry for developer diagnostics.

Detailed steps:

• Replace the except KeyError as e: block such that it logs or reports the error (using the existing handle_server_error or report_exception methods, as appropriate).
• The HTTP response should return a generic error message like "Required attribute missing from data" without any dynamic content (i.e., do not interpolate str(e) into the message).

Files/lines to change:

• Only make changes inside contentcuration/contentcuration/views/internal.py within the api_commit_channel function and do not alter code that is not shown.
• Add logging/reporting of the actual exception for admin/developer reference.

---

The best fix is to replace the HttpResponseBadRequest in the except KeyError as e: block so that it does not return the exception detail (str(e)) to the user. Instead, it should return a generic "Required attribute missing from request data" message. The detail can be logged server-side using the Python logging module or sent to Sentry if available.

Specifically:

• In api_add_nodes_to_tree (lines ~354-357), replace the return statement so the user response does not include str(e).
• Optionally, add a call to logging.error() (or use the existing Sentry report facility as imported) to capture the original exception detail for diagnostics.
• No additional dependencies are needed, as logging is already imported and Sentry reporting appears available.
• No changes outside this block are required.

---

[rtibbles]

Let's hotfix this!