refactor(hr): decouple resume storage from WordPress filesystem#3838
refactor(hr): decouple resume storage from WordPress filesystem#3838rathorevaibhav wants to merge 2 commits intodevelopfrom
Conversation
Portal already serves uploaded resumes publicly from its own storage symlink (storage/app/public via /storage/resume), and the iframe in the applicant details/edit views renders them same-origin without any auth or framing issues. The MoveFilesToWordPress command and the MoveResumeToWebsite listener that called it via Artisan on every ApplicationCreated event were duplicating the file onto WordPress's upload directory purely to surface a coloredcow.com URL — a redundant indirection that also imposes a hard filesystem coupling between portal and WP. Removing it eliminates that coupling so the WordPress site can move to its own server without portal-side changes. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
💤 Files with no reviewable changes (5)
WalkthroughThis pull request removes the resume file migration feature by deleting the Artisan command and event listener, deregistering them from service providers, and updating configuration to remove the now-unused upload directory setting while introducing new URL-based configuration entries for admin, analytics, and CubeJS services. ChangesResume Migration Feature Removal
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Employee portal
|
||||||||||||||||||||||||||||
| Project |
Employee portal
|
| Branch Review |
refs/pull/3838/merge
|
| Run status |
|
| Run duration | 00m 23s |
| Commit |
|
| Committer | Vaibhav Rathore |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
|
|
0
|
|
|
0
|
|
|
0
|
|
|
0
|
|
|
4
|
| View all changes introduced in this branch ↗︎ | |
…ordpress-resume-storage
Summary
MoveFilesToWordPressconsole command andMoveResumeToWebsiteevent listener that copied portal-uploaded resumes into WordPress'swp-content/uploads/directory and rewrote the resume URL to acoloredcow.com/wp-content/uploads/...link.website_upload_dirconfig entry (was only consumed by the deleted command)./storage/resume/...same-origin without any auth or framing issues.Why
Context: coloredcow-admin/coloredcow#1230 — DevOps is moving
coloredcow.com(WordPress) onto its own Ubuntu 24.04 EC2 server so it can run modern PHP, leaving the portal on the existing server. While auditing what would break, thisMoveFilesToWordPressplumbing turned out to be the only remaining hard coupling between portal and WordPress filesystems.The flow it implemented:
resume_filevia portal UI →Application::saveResumeFile()saves tostorage/app/public/resume/YYYY/MM/...and stores/storage/resume/...in DB.ApplicationCreatedevent →MoveResumeToWebsitelistener → synchronousArtisan::call('hr:move-resume-to-website').exec("cp ...")to a local WordPress upload path (WEBSITE_UPLOAD_DIR), then rewritesapplications.resumetohttps://coloredcow.com/wp-content/uploads/....Issues with the existing implementation:
exec()shell call inside a request-time event listener.if ($d) continue;).mkdir()— would fail if year directory doesn't exist.MoveFilesToWordPressdoesn't match command signaturehr:move-resume-to-website.'Command description'— placeholder never filled in.WHERE resume LIKE '/storage/resume%' LIMIT 50processes 50 random old records on every new application — looks like a one-time backlog migration script that someone wired into an event listener as an afterthought.The portal-side serving already works:
Nginx serves these as static files at
https://portal.coloredcow.com/storage/resume/.... The blade iframe loads same-origin → noX-Frame-Optionsissues, no auth issues, browser PDF viewer renders inline. Same access pattern (publicly readable by anyone with the URL) as the WP-hosted variant — no new privacy risk.What this changes for users
Nothing visible. The HR admin "View Resume" link in the applicant details/edit pages continues to work — only the URL changes for new portal-uploaded resumes (from
coloredcow.com/wp-content/uploads/...toportal.coloredcow.com/storage/resume/...).Existing records are untouched:
https://coloredcow.com/wp-content/uploads/...(most of the table — these come from the WordPress career form path) keep working as long as the WPwp-content/uploads/directory remains served fromcoloredcow.com(which it will, even after the WP server move per the migration plan's rsync step)./storage/resume/...(the backlog this command was supposed to drain) start working immediately because the portal serves them directly.Test plan
storage/app/public/resume/YYYY/MM/<filename>.pdfandapplications.resumeis/storage/resume/YYYY/MM/<filename>.pdf(no longer rewritten to acoloredcow.comURL)/hr/recruitment/applicant/details/show/{id}for the new application → confirm iframe renders the PDF inline/hr/recruitment/job/{id}/edit→ confirm iframe still renders for the new application and for an existing application (whose URL is the legacy WP-hosted form)resumefield is still accepted as a URL and the existing flow is unaffectedphp artisan listand confirmhr:move-resume-to-websiteis gone🤖 Generated with Claude Code
Summary by CodeRabbit