Jonathan Katz
57d78c54d1
<!-- Add the related story/sub-task/bug number, like Resolves #123, or remove if NA --> **Related issue:** Resolves #46390 Migration to add a non nullable team_id column. I chose this approach so that server code doesn't have to deal with a potentially null team id for categories. It first adds team_id=0 to all the existing categories, then duplicates that for every fleet so that default categories can be edited and deleted by admins. It also renames the default categories to include the emojis in their name, which required updating some test expectations, and also mapping default names to the new ones for Fleet maintained apps. If we don't do that, FMA's manifests would have to all be updated right after 4.87 releases and every user would have to migrate immediately. This would also break existing gitops files if the names aren't mapped. The alternative would be to keep the names unchanged, and add custom logic in various places to insert the emojis in the backend and frontend. # Checklist for submitter If some of the following don't apply, delete the relevant line. ## Testing - [x] Added/updated automated tests - [ ] Where appropriate, [automated tests simulate multiple hosts and test for host isolation](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/reference/patterns-backend.md#unit-testing) (updates to one hosts's records do not affect another) - [x] QA'd all new/changed functionality manually ## Database migrations - [x] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [x] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [x] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`).
Platform packages
This directory contains infrastructure and cross-cutting technical concerns that are independent of Fleet's business domain. These packages provide foundational capabilities used across the codebase.
Platform vs domain
Following separation of concerns, we distinguish:
- Platform (infrastructure): Technical concerns like database connectivity, HTTP utilities, middleware, and transport-level error handling. These packages have no knowledge of Fleet's business domain.
- Domain (business logic): Feature-specific code organized into bounded contexts. Domain packages depend on platform packages, not the reverse.
Guidelines
- Platform packages must not import domain packages
- Platform packages should be general-purpose and reusable
- Architectural boundaries are enforced by
arch_test.go