How Booking Data Scoping and Soft Delete Works

Source: Multiple controllers

• All major booking-related models use soft delete via a default_scope that excludes records where deleted=true
• Soft-deleted records remain in the database but are automatically excluded from all normal queries; use unscoped to include them in queries when needed (e.g., for reporting or admin investigation)
• All queries are scoped to the current company via the company_limited concern, preventing cross-company data access
• Pagination parameters are optional: if page/per_page params are missing, the query returns ALL matching records (no automatic pagination)
• Sort direction and sort field values are validated server-side to prevent SQL injection attacks

Support scenarios

• "A booking that was deleted is still showing up" → If it appears in a normal view, there may be a bug in the scoping. Soft-deleted records should be excluded by default_scope. Check whether the query is using unscoped inadvertently.
• "A booking was deleted but we need the data" → Soft-deleted records remain in the database. They can be accessed using unscoped queries or direct database access. The data is not permanently lost.
• "The page is loading slowly with thousands of bookings" → If pagination parameters are not being passed, the system returns ALL records. Ensure the UI is sending page and per_page parameters to limit the result set.
• "Can another company see our bookings?" → No. All queries are scoped to the current company via company_limited. Cross-company data access is prevented at the query level.