Documenting code, one commit at a time.
This post details improvements to error handling within the Reimpact/platform project, focusing on delete operations and providing more specific and informative error messages.
Previously, the platform had a generic catch-all for delete errors. This made it difficult to distinguish between expected errors, such as foreign key violations, and unexpected errors, hindering debugging
Maintaining data accuracy across all tenants in a multi-tenant application can be challenging. This post explores how to correct an issue where global rates were inadvertently made tenant-specific in a Laravel application, impacting data integrity.
Originally, the rates table was intended to store global rates applicable to all tenants.
When working with the Reimpact/platform project, we encountered an issue with large upload deletions that resulted in failures and an unhelpful JSON response. This post describes how we resolved the deletion failure and improved the user experience by displaying a Filament notification instead of a raw JSON page.
Deleting a large number of generated reports and calculated data
The platform project is undergoing continuous improvement to enhance its notification system.
Initially, the notification system stored data in a simple text column. However, as the platform evolved, the need for richer, structured data within notifications became apparent. This required a transition to a more flexible data type.
The Reimpact platform is focused on streamlining various business processes. Recent updates enhance the platform's interaction with databases, specifically focusing on user notifications and improved error handling for foreign key violations in both MySQL and PostgreSQL.
A key improvement involves enabling database notifications within Filament panels.
The Reimpact/platform project focuses on providing a multi-tenant application structure. Recently, we encountered an issue with tenant database schemas being reset prematurely during Livewire updates. This post dives into the problem and the solution implemented.
In a multi-tenant application, each tenant typically has its own database schema. We use middleware to set the correct
The Reimpact/platform project involves building a comprehensive platform, and a recent update focused on enhancing the user experience when managing data through Filament resources. This post details the addition of delete actions to a MassiveUpload resource, streamlining data management directly from the resource table and view pages.
The primary feature added is the ability
The Reimpact/platform project is undergoing improvements to its testing infrastructure, specifically focusing on Filament resources. The goal is to ensure comprehensive test coverage for CRUD operations across various resources, while also addressing tenant-specific data handling.
Previously, testing Filament resources lacked sufficient coverage, especially
The Reimpact platform is undergoing continuous improvements to enhance its multi-tenancy capabilities. Recent work focuses on optimizing database queries within the Packaging module, ensuring data isolation and preventing errors in tenant-specific schemas.
In a multi-tenant environment, each tenant operates within its own schema. The Packaging module, responsible for managing
In multi-tenant applications, managing data isolation is crucial. The Reimpact platform, designed for managing various industrial processes, initially relied on company_id filtering within each database table to achieve this isolation. This approach, while functional, introduced redundancy and complexity across our Eloquent models.
