The LCPL Lab System manages the full lifecycle of a lab report: a technician (Subordinate) uploads a batch of report files for a customer, a Manager or Admin reviews and approves or rejects the batch, and once approved, the system automatically emails the report files to the internal distribution list and the customer, then archives them.
| Role | What they can do |
|---|---|
| Subordinate | Upload new report batches for a customer. Can see their own uploads and the read-only Report Archive. |
| Manager | Everything a Subordinate can see, plus: review pending batches and Approve or Reject them. |
| Admin | Everything a Manager can do, plus: manage customers, the email distribution list, user accounts, permanently delete rejected files, and run one-off maintenance tools. |
| Viewer | Read-only access to the Report Archive only. Cannot upload or approve anything. |
Approval and email delivery are two separate, independent steps. A batch can sit in "Approved" for a short time before flipping to "Sent" — this is normal and is explained in Section 6.
Open the system's web address in a browser and sign in with the email and password your Admin gave you.
When an Admin creates a new account, or explicitly flags an existing one, the user is required to set a new password immediately after logging in — a dialog appears automatically and cannot be dismissed until a new password (minimum 6 characters) is set.
There is currently no self-service "change my password anytime" option for regular users. If someone needs to change their password outside of this forced flow, an Admin must reset it for them from the Users page (Section 5) or the password reset tool (Section 9.2).
Any Subordinate account can upload a new batch of report files from the Upload Report page.
In the sidebar.
E.g. "Batch #405 Analysis". If you upload multiple files, each file's name is automatically appended to this title so they stay distinguishable.
Choose from the dropdown of existing customers.
Useful context for the approving Manager, e.g. batch details or test parameters.
Drag and drop, or click to browse. Accepted formats: PDF, DOC/DOCX, XLS/XLSX, JPG, PNG. Maximum 20MB per file.
All files in this submission are grouped into a single batch and set to Pending.
Uploading does not send an email immediately. It queues a notification that a background process delivers shortly afterward — see Section 6 for why this matters.
Manager and Admin accounts see an Approvals link in the sidebar, with a red badge showing how many batches are waiting.
Every pending batch is listed with its title, description, customer, and file count.
Use the description/remarks column for context from the uploader.
Both actions take effect immediately.
The batch status changes to Approved right away. An email notification is queued for delivery (see Section 6) containing the report files as attachments, sent to the internal distribution list and CC'd to the customer's own email address (if one is on file) and to the designated senior recipient. Once that email is actually sent, the status automatically flips to Sent and the batch appears in the Report Archive.
The batch status changes to Rejected. No email is sent. The batch (and its files) moves into Rejected Files, visible only to Admin, where it stays until an Admin permanently deletes it (Section 8). Add a clear remark when rejecting — it is shown to the Admin reviewing Rejected Files.
Go to Users to create, edit, or remove accounts.
Or "Edit" next to an existing user.
When editing, leave the password field blank to keep the current password unchanged.
Subordinate, Manager, Admin, or Viewer — see Section 1.1.
New users always have this set automatically.
The user can now log in with the credentials you set.
You cannot delete your own currently logged-in account, and you cannot delete a user who has uploaded reports — the system will tell you to delete their reports first. This protects the audit trail.
This is the most important operational concept in the system to understand, because of a past incident that shaped how it works today.
Earlier versions of this system tried to send email while the user waited for the Upload or Approve page to finish loading. When the SMTP mail server became slow or unreachable, each of those page requests could hang for up to five minutes. Hostinger shared hosting limits how many PHP processes an account may run at once; a handful of these hung requests exhausted that limit and took the entire site offline for every user — even ones just trying to log in.
The system was redesigned specifically to prevent this from happening again. Uploading a report and approving a batch are now instant, database-only actions. A separate background process is the only thing that ever talks to the mail server, and it runs completely outside of any user's request.
A report is uploaded, or a batch is approved. This queues an email job in the database — a fast write, not a network call.
A scheduled task (cron job) runs send_queue.php roughly once a minute, picks up any due jobs, and actually sends the email via SMTP.
On success, the queued job is marked sent, and for approval emails, the report batch itself flips from Approved to Sent.
If SMTP is temporarily down, a failed attempt is retried later with increasing delays (2, 4, 8, 16 minutes, and so on), up to a configured maximum number of attempts, without any manual action needed.
This background sending only works if a Cron Job has been configured on the server to run send_queue.php automatically. If it has not been set up (or was removed), emails will queue up but never actually send.
You can also trigger send_queue.php manually by visiting it in your browser while logged in as Admin — useful for testing that email is working right now, without waiting for the next cron tick.
If a batch stays "Approved" for a long time without becoming "Sent", or an uploader reports the manager was never notified:
Go to Customers (Admin only) to add, edit, or remove the companies that reports are uploaded against. Every uploaded report must be linked to a customer.
The Customer form currently only captures a company name — there is no field to set a customer's own contact email from this screen, even though the underlying system does support CC'ing a customer on their own approved report if an email address is present on their record. If a customer needs to be CC'd automatically, their email currently has to be set directly in the customers table via phpMyAdmin. Worth asking your developer to restore this field to the form if customer CC's are something you rely on.
A customer cannot be deleted while they still have reports in the system — delete or reassign their reports first.
Go to Email List (Admin only) to manage who receives every approved report internally, regardless of customer. Add a name and email, and it will be CC'd/TO'd on every future approval notification. Edit or remove entries at any time — changes apply to future approvals only, not ones already sent.
If the distribution list is empty, approval emails fall back to a single designated recipient configured by your developer in the mail settings, so reports are never silently lost.
Every Approved or Sent report is visible here, grouped by year and month, to every logged-in user regardless of role or which customer the report belongs to. Anyone can view/download a file; only Admin can permanently delete one.
This means any employee with a login — not just people working with a specific customer — can browse every approved report in the archive. If that is broader access than intended, this would need to be restricted in the code (e.g. by department or customer assignment).
A link to a previous, separate archive system is kept in the sidebar for continuity while historical data is being consolidated. It opens in a new tab and is unrelated to this system's database.
Rejected batches remain here, along with the rejection remarks, until an Admin permanently deletes them. Deleting removes both the database record and the underlying file from the server — this cannot be undone.
If historical report files exist outside the system (e.g. from before it was built), they can be bulk imported using the legacy importer.
Create a folder structure of legacy_data/YEAR/MONTH/ containing the files, uploaded to the server alongside the application.
It automatically creates a "Legacy Archive" customer to file these under, if one doesn't already exist.
Each imported file is listed as it's processed; already-imported files (matched by path) are skipped automatically, so it is safe to run more than once.
Legacy Archive reports are deliberately excluded from the main dashboard counts, the Upload page's customer list, and Report Archive counts, so they don't skew day-to-day operational figures.
If someone is locked out and cannot use the forced-change flow themselves, an Admin can generate a fresh one-time password for exactly one account: select the user, confirm the action, and a random temporary password is generated and shown once on screen for you to share with them securely. It automatically forces them to set their own password on next login.
An Admin-only tool exists to send a test email using the live mail configuration, useful for confirming SMTP credentials are correct after a password rotation, without needing to wait for a real report to go through the approval flow.
This section reports specific findings from a review of the files provided for this guide. Please action these before relying on this system for anything sensitive.
The following files were found alongside the current application. Each is an old, one-off patch or debug script that was superseded by a safer version, but was apparently left on the server rather than removed. If any of these still exist on your live site, delete them now:
| File | Why it must be deleted |
|---|---|
| 22aug_fix_login.php | SEVERE: requires no login at all. Anyone who visits this URL resets every single user's password (including all Admin accounts) to the fixed value "123456". This is a complete, unauthenticated account-takeover path. |
| 22aug_debug_email.php | SEVERE: requires no login. Hardcodes the live SMTP mailbox password in plain text and, when run, can print the raw SMTP handshake to the page — exposing mail credentials to anyone who finds the URL. |
| 22aug_process_action.php / bcc_process_action.php | Older duplicates of the approval handler that still send email synchronously while the page waits — the exact defect that caused the site-wide outage described in Section 6. Properly access-controlled, but should not exist alongside the fixed version. |
| 22aug_upload_report.php | Older duplicate of the upload handler with the same blocking-email defect as above. |
| remove_hostory_from_dashboard.php | An older duplicate of the dashboard page. Properly access-controlled, but redundant and confusing to keep. |
| view_reports.php | An older "History" page no longer linked from the sidebar, superseded by Report Archive. Not a security issue by itself, but safe to remove once confirmed unused, to avoid confusion. |
Because the two files above expose them without authentication, treat the following as already compromised and change them as soon as the files are deleted:
This guide intentionally does not repeat the specific passwords found in the codebase. Treat any password that appears in a PHP file under the web root as already exposed and due for rotation.
The background email sender (send_queue.php) expects two files at specific paths: config/mail.php (SMTP settings) and includes/mailer.php (shared mail setup code). Confirm both files actually live at those exact paths on your server, in their respective config/ and includes/ folders — not sitting in the project's root folder. If they are in the wrong place, every background email send will fail with a fatal "file not found" error and no reports will ever be delivered, even though uploads and approvals will otherwise appear to work normally.
A batch shows "Approved" but the customer says they never got the email. What happened?
This is expected for a short window — approval and email delivery are separate steps (Section 6). If it has been more than a few minutes, check that the cron job is running (Section 6.3) and check the email_queue table for a failed job (Section 6.4).
Can I un-reject a batch?
Not directly through the interface. A rejected batch can only be permanently deleted by an Admin. If the rejection was a mistake, ask the Subordinate to re-upload the same files as a new batch.
Why can every employee see every customer's reports in the Archive?
That is how the Report Archive currently works — it is not filtered by customer or department (Section 8.1). If your organization needs report visibility restricted, this would need a code change.
A customer isn't receiving a CC of their own reports. Why?
Most likely their email address was never set, since the Customer Management screen currently doesn't have a field for it (Section 7.1). It can be set directly via phpMyAdmin in the meantime.
What happens to the physical files when I delete a report?
Both the database record and the underlying file on the server are deleted together, from Dashboard, Report Archive, or Rejected Files. This cannot be undone — there is no recycle bin.