feat: Add dashboard user to job schedule execution description#3397
feat: Add dashboard user to job schedule execution description#3397codeKonami wants to merge 1 commit into
Conversation
Include the logged-in Parse Dashboard user in the job execution
description ("Executing from job schedule web console by <user>.") to
provide a basic level of auditability of who triggered a job from the
dashboard. Falls back to the previous description when no dashboard user
is configured or cannot be determined.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review. Tip
Note Please respond to review comments from AI agents just like you would to comments from a human reviewer. Let the reviewer resolve their own comments, unless they have reviewed and accepted your commit, or agreed with your explanation for why the feedback was incorrect. Caution Pull requests must be written using an AI agent with human supervision. Pull requests written entirely by a human will likely be rejected, because of lower code quality, higher review effort and the higher risk of introducing bugs. Please note that AI review comments on this pull request alone do not satisfy this requirement. Our CI and AI review are safeguards, not development tools. If many issues are flagged, rethink your development approach. Invest more effort in planning and design rather than using review cycles to fix low-quality code. |
📝 WalkthroughWalkthrough
ChangesJob description username lookup
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant Caller
participant ParseApp
participant DashboardServer
participant ParseServer
Caller->>ParseApp: runJob(job)
ParseApp->>DashboardServer: fetch(PARSE_DASHBOARD_PATH)
alt username header present
DashboardServer-->>ParseApp: response with username header
ParseApp->>ParseApp: description includes username
else fetch fails or no username
DashboardServer-->>ParseApp: error or null username
ParseApp->>ParseApp: description uses default
end
ParseApp->>ParseServer: Parse._request('POST', 'jobs', {input, jobName, when: 0, description})
ParseServer-->>ParseApp: response
ParseApp-->>Caller: result
Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 inconclusive)
✅ Passed checks (6 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Pull request overview
This PR improves auditability for Cloud Code jobs triggered from the Parse Dashboard by including the currently logged-in dashboard auth user in the _JobStatus.description when running a job via Jobs → Run now.
Changes:
- Update
ParseApp.runJobto read theusernameresponse header from the dashboard route and append it to the job execution description when present. - Add Jest coverage for the new behavior, including fallback behavior when the username is missing or lookup fails.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/lib/ParseApp.js |
Adds dashboard-user attribution to the job execution description by reading the username header. |
src/lib/tests/ParseApp.test.js |
Adds unit tests verifying user attribution and fallback behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| describe('ParseApp.runJob', () => { | ||
| beforeEach(() => { | ||
| Parse._request = jest.fn(() => Promise.resolve({})); | ||
| window.PARSE_DASHBOARD_PATH = '/'; | ||
| }); |
| let description = 'Executing from job schedule web console.'; | ||
| try { | ||
| const response = await fetch(window.PARSE_DASHBOARD_PATH || '/'); | ||
| const dashboardUser = response.headers.get('username'); | ||
| if (dashboardUser) { | ||
| description = `Executing from job schedule web console by ${dashboardUser}.`; | ||
| } | ||
| } catch { | ||
| // If the dashboard user cannot be determined, fall back to the default description. | ||
| } |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
src/lib/tests/ParseApp.test.js (1)
32-36: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAdd
afterEachto restoreglobal.fetchandwindow.PARSE_DASHBOARD_PATH.The
beforeEachsetsParse._requestandwindow.PARSE_DASHBOARD_PATH, and each test overwritesglobal.fetch, but nothing restores these globals after the suite runs. AddingafterEachprevents potential leakage if the jsdom environment is reused across test files.♻️ Proposed fix
beforeEach(() => { Parse._request = jest.fn(() => Promise.resolve({})); window.PARSE_DASHBOARD_PATH = '/'; }); + + afterEach(() => { + jest.restoreAllMocks(); + delete global.fetch; + delete window.PARSE_DASHBOARD_PATH; + });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/lib/tests/ParseApp.test.js` around lines 32 - 36, The ParseApp test suite leaves global state behind because `beforeEach` and the tests mutate `global.fetch` and `window.PARSE_DASHBOARD_PATH` without restoring them. Add an `afterEach` in `ParseApp.test.js` alongside `describe('ParseApp.runJob', ...)` to reset both values to their original state after every test, so the jsdom environment and shared globals do not leak across test files.src/lib/ParseApp.js (1)
590-598: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick winUse
HEADwith a short timeout here
This only needs theusernameheader. The dashboard route already sets that header before sending the HTML, soHEADavoids downloading the body; add an abort timeout too so job execution doesn’t hang on a slow dashboard.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/lib/ParseApp.js` around lines 590 - 598, The dashboard user lookup in ParseApp’s description-building logic is fetching the full page body when it only needs the username header. Update the `fetch` call in the job-schedule console path to use a `HEAD` request instead of the default method, and add a short abort timeout so the `description` fallback in `ParseApp` doesn’t hang on a slow dashboard response.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/lib/ParseApp.js`:
- Around line 590-598: The dashboard user lookup in ParseApp’s
description-building logic is fetching the full page body when it only needs the
username header. Update the `fetch` call in the job-schedule console path to use
a `HEAD` request instead of the default method, and add a short abort timeout so
the `description` fallback in `ParseApp` doesn’t hang on a slow dashboard
response.
In `@src/lib/tests/ParseApp.test.js`:
- Around line 32-36: The ParseApp test suite leaves global state behind because
`beforeEach` and the tests mutate `global.fetch` and
`window.PARSE_DASHBOARD_PATH` without restoring them. Add an `afterEach` in
`ParseApp.test.js` alongside `describe('ParseApp.runJob', ...)` to reset both
values to their original state after every test, so the jsdom environment and
shared globals do not leak across test files.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: fdfbed22-c473-4dbc-bd08-ace916392445
📒 Files selected for processing (2)
src/lib/ParseApp.jssrc/lib/tests/ParseApp.test.js
Pull Request
Issue
There is currently no way to tell who triggered a Cloud Code job from the dashboard. When a job is run manually via Jobs → Run now, the resulting
_JobStatusentry always has the same generic description:On a dashboard instance shared by several users (dashboard authentication with multiple
usersconfigured), this makes it impossible to audit which dashboard operator started a given job run.Closes:
Approach
Include the currently logged-in Parse Dashboard user (the dashboard authentication user, not a Parse
_Userof the app) in the job execution description, so the_JobStatusrecord reads:This provides a simple, built-in level of auditability of job executions triggered from the dashboard.
Implementation details:
usernameHTTP response header on the main dashboard route (Parse-Dashboard/app.js,res.append('username', req.user.matchingUsername)), and is consumed the same way by the sidebar (src/components/Sidebar/Sidebar.react.js).ParseApp.runJobnow reads that header and, when present, appendsby <user>to the job description before posting the job.usernameheader) or the lookup fails for any reason, the original descriptionExecuting from job schedule web console.is used unchanged.Tasks
Note: no user-facing docs describe this internal job description string, so no documentation change is required. The
CHANGELOGis generated automatically by semantic-release from the commit message, so no manual changelog entry is added.Summary by CodeRabbit