System create a new file upload system where all files are saved in a central table#2076
Open
ali-ichk wants to merge 42 commits intoGibbonEdu:v31.0.00from
Conversation
FileGateway.php - All 6 required methods are complete: recordFileUpload(), recordFileUploadWithPointer(), selectFilesByForeignRecord(), selectOrphanedFileRecords(), verifyFileIntegrity(), FilePointerGateway.php - Core method implemented: recordFilePointer()
…ss. Implemented the new Gateway class in 5 locations where a file is being uploaded.
…ass to integrate with the new file tracking system and implemented the method where custom fields are of type image or file
… of type image or file is handled.
…here-all-files-are-saved-in-a-central-table
…here-all-files-are-saved-in-a-central-table
SKuipers
requested changes
Mar 20, 2026
Member
SKuipers
left a comment
SKuipers
left a comment
There was a problem hiding this comment.
Hi Ali, I've started a review and have flagged some spots to have a look at before I merge.
Co-authored-by: Sandra Kuipers <sandra@skuipers.com>
…are-saved-in-a-central-table' of https://github.com/ali-ichk/core into System-Create-a-new-file-upload-system-where-all-files-are-saved-in-a-central-table * 'System-Create-a-new-file-upload-system-where-all-files-are-saved-in-a-central-table' of https://github.com/ali-ichk/core: Apply suggestions from code review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gibbon currently lacks centralized tracking of file uploads across the system. When files are uploaded through various modules, there's no systematic way to track which files exist, identify orphaned files when records are deleted, audit file usage, or implement file lifecycle management. This change introduces a comprehensive file tracking infrastructure that records all file uploads in new gibbonFile and gibbonFilePointer tables, providing metadata tracking and relationship mapping between files and database records. The FileHandler class provides a unified API for recording, deleting, and querying file uploads. Foreign key constraints ensure automatic cleanup of file records when parent records are deleted. This foundation enables future features like storage analytics, orphaned file cleanup, file retention policies, and audit trails while maintaining full backward compatibility with existing upload functionality.
Description
File Upload Tracking System
Added comprehensive file upload tracking system to monitor and manage all file uploads across the system
Added new database tables gibbonFile and gibbonFilePointer to track file metadata and relationships
Added FileHandler class to centralize file tracking operations (record, delete)
Added FileGateway and FilePointerGateway for database operations
Integrated file tracking across 12 modules covering 40+ file upload locations:
- Planner Module: units, homework submissions, and resources (6 files)
- Departments Module: department resources (1 file)
- Staff Module: staff contracts with bug fixes (1 file)
- Free Learning Module: unit logos and student work (4 files)
- Parent Photo Upload: profile images with bug fixes (1 file)
- Professional Development Module: supporting evidence and expense receipts (2 files)
- Enrichment and Flow Module: domain, credit, and opportunity logos, journey evidence (7 files)
- Flexible Learning Module: unit submission evidence (2 files)
- Policies Module: policy documents (2 files)
- Info Grid Module: entry logos (2 files)
- Committees Module: committee logos (2 files)
Implemented consistent file deletion tracking when files are removed or replaced
Added partial failure handling to report tracking issues without blocking uploads
Motivation and Context
Currently, Gibbon lacks centralized tracking of file uploads across the system. When files are uploaded through various modules (Planner, Staff, Free Learning, etc.), there's no systematic way to:
Track which files exist in the system and where they're stored
Identify orphaned files when database records are deleted
Audit file usage and relationships across tables
Implement file lifecycle management (retention policies, cleanup)
Generate reports on storage usage by module or user
Ensure data integrity between filesystem and database
How Has This Been Tested?
Testing Environment
PHP version: PHP 8.3
Database: MySQL
Gibbon version: v31.0.00
Modules tested: 12 modules across 40+ file upload locations
Testing was performed across 12 modules covering 40+ file upload locations including Planner, Staff, Free Learning, Professional Development, Enrichment and Flow, Flexible Learning, Policies, Info Grid, Committees, Departments, and Parent Photo Upload modules. Database schema was validated to ensure tables, foreign keys, and indexes were created correctly. Core infrastructure testing confirmed FileHandler::recordFileUpload() and FileHandler::deleteFile() work properly with various file types. Each module's add and edit operations were tested to verify files upload correctly, tracking records are created in the database, file replacements work, and deletion tracking functions properly. Error handling was tested to ensure tracking failures don't block successful uploads (partial failure returns warning1). Regression testing confirmed all existing upload functionality works unchanged with no breaking changes to module behavior. The implementation is transparent to end users and maintains full backward compatibility.
Test Results
All 40+ file upload locations successfully integrated
File tracking records created correctly in database
File deletion tracking works as expected
No regressions in existing upload functionality
Bug fixes verified and working correct