mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-20 14:06:27 +00:00
jubnl
6763648c45
SettingsRepository (getForUser/upsertForUser/getOne/deleteForUser) replaces the per-user settings table's raw SQL; SettingsService drops DatabaseService entirely. instance-api-keys.ts's readInstanceApiKey/writeInstanceApiKey/ resolveApiKey take an explicit AppSettingsRepository/UsersRepository instead of a raw connection. An earlier version resolved those two repositories itself from the active MikroORM request context, so none of its six callers needed to change. That worked in production and e2e (always inside a real request) but broke service construction in plain unit tests across every calling domain (addons, auth x2, maps, transit, unsplash - 185 failures on a full run), since none of them wrap a request context. Each of those six services now injects its own AppSettingsRepository/UsersRepository and passes them through explicitly, matching how every other converted repository in this migration is consumed; their own SQL is untouched (outside Plan 3a).
43 lines
2.1 KiB
TypeScript
43 lines
2.1 KiB
TypeScript
import { Module } from '@nestjs/common';
|
|
import { MikroOrmModule } from '@mikro-orm/nestjs';
|
|
import { AddonsController } from './addons.controller';
|
|
import { AddonsService } from './addons.service';
|
|
import { AddonGuard } from './addon.guard';
|
|
import { AddonsMcp } from './addons.mcp';
|
|
import { Addons } from '../../db/entities/Addons.entity';
|
|
import { PhotoProviders } from '../../db/entities/PhotoProviders.entity';
|
|
import { PhotoProviderFields } from '../../db/entities/PhotoProviderFields.entity';
|
|
import { AppSettings } from '../../db/entities/AppSettings.entity';
|
|
import { Users } from '../../db/entities/Users.entity';
|
|
|
|
/**
|
|
* GET /api/addons — enabled add-ons + photo providers (was an inline handler in
|
|
* server/src/app.ts). The addon sub-features (atlas, vacay) keep their own
|
|
* modules; this only serves the EXACT /api/addons listing.
|
|
*
|
|
* Exports AddonsService — the owner of addon/feature-flag enablement reads
|
|
* (isAddonEnabled + bag-tracking/collab-features flags, extracted from
|
|
* adminService per finding `admin-1`) — for the in-container consumers.
|
|
* Deliberately NOT @Global (permissions precedent): e2e TestingModules resolve
|
|
* it transitively through each consumer's explicit import.
|
|
*
|
|
* AddonsMcp puts the same listing on the MCP surface, so a model can read which
|
|
* add-ons this instance has switched on instead of guessing from the tools it
|
|
* was handed.
|
|
*
|
|
* MikroOrmModule.forFeature registers AddonsRepository/PhotoProvidersRepository/
|
|
* PhotoProviderFieldsRepository/AppSettingsRepository for AddonsService's
|
|
* @InjectRepository constructor (Plan 3a Task 4) — the forFeature +
|
|
* @InjectRepository wiring pattern Task 0 set up on SettingsModule. `Users` was
|
|
* added by Task 5: `googleKeySource` passes `UsersRepository` explicitly to
|
|
* `instance-api-keys.ts`'s resolveApiKey now, instead of that file resolving
|
|
* one off the ambient request context.
|
|
*/
|
|
@Module({
|
|
imports: [MikroOrmModule.forFeature([Addons, PhotoProviders, PhotoProviderFields, AppSettings, Users])],
|
|
controllers: [AddonsController],
|
|
providers: [AddonsService, AddonGuard, AddonsMcp],
|
|
exports: [AddonsService, AddonGuard],
|
|
})
|
|
export class AddonsModule {}
|