Per-project settings (owners/admins, «Configuración» tab):
- Statuses with category (TODO, IN_PROGRESS, QA, DONE, CANCELLED), colour and
"requires reason"; configurable transitions; ticket types (icon, colour) and
areas. Defaults are the previous fixed values; projects created before keep
them without migration.
- Values are archived, never deleted: tickets, history and statistics keep
referring to them. Validated in the domain (ProjectSettingsChangedEvent).
- Releases, board, tracking and "my work" use categories, so custom statuses
keep working. Status changes carry name/category metadata for history.
- GraphQL: status/type/area are strings (breaking for clients sending enum
literals); Project.settings, updateProjectSettings, statusCategory,
myIssues(categories). REST: PUT /projects/{project}/settings, category filters.
- Read model: statusCategory on issues (backfilled at startup).
Statistics («Estadísticas» tab):
- New issue_timeline projection; pure functions compute created vs resolved,
cumulative flow, cycle/lead time (avg + p85), throughput per person, QA
pass/fail and release burnup. GraphQL Project.analytics(days),
Release.burnup; REST /projects/{project}/analytics, /releases/{id}/burnup.
- Web: SVG charts with validated light/dark palette, crosshair tooltip,
keyboard navigation, legend and data table.
Home "Mi trabajo": my open tickets across projects grouped by category (QA
failures first), tickets waiting for QA, upcoming releases and "Ir a…".
Tests: domain/application specs, e2e scenario for settings and analytics,
facade tests. Docs, READMEs, schema.gql/openapi.json and Word/PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
57 lines
1.6 KiB
TypeScript
57 lines
1.6 KiB
TypeScript
import { DynamicModule, Module, Type } from '@nestjs/common';
|
|
import { CqrsModule } from '@nestjs/cqrs';
|
|
import { TRACKER_FACTORIES } from '@task-stream/api/tracker/domain';
|
|
import { ChangesService } from './changes.service';
|
|
import { COMMAND_HANDLERS } from './commands/command-handlers';
|
|
import { WriteAccess } from './commands/write-access';
|
|
import { CommentsService } from './comments.service';
|
|
import {
|
|
EVENT_HANDLERS,
|
|
ReadModelNotifier,
|
|
} from './event-handlers/event-handlers';
|
|
import { IssuesService } from './issues.service';
|
|
import { ProjectsService } from './projects.service';
|
|
import { QUERY_HANDLERS } from './queries/query-handlers';
|
|
import { ReadAccess } from './queries/read-access';
|
|
import { ReleasesService } from './releases.service';
|
|
import { WorkflowsService } from './workflows.service';
|
|
|
|
const SERVICES = [
|
|
ProjectsService,
|
|
IssuesService,
|
|
CommentsService,
|
|
ReleasesService,
|
|
ChangesService,
|
|
WorkflowsService,
|
|
];
|
|
|
|
/**
|
|
* Use cases of the tracker context. The infrastructure module implementing
|
|
* its ports (lookups, read model, change feed, user directory) is plugged in
|
|
* by the composition root; the event store comes from the SharedModule.
|
|
*/
|
|
@Module({
|
|
imports: [CqrsModule],
|
|
providers: [
|
|
...SERVICES,
|
|
...TRACKER_FACTORIES,
|
|
WriteAccess,
|
|
ReadAccess,
|
|
ReadModelNotifier,
|
|
...COMMAND_HANDLERS,
|
|
...QUERY_HANDLERS,
|
|
...EVENT_HANDLERS,
|
|
],
|
|
exports: SERVICES,
|
|
})
|
|
export class TrackerApplicationModule {
|
|
static withInfrastructure(
|
|
infrastructureModule: Type | DynamicModule,
|
|
): DynamicModule {
|
|
return {
|
|
module: TrackerApplicationModule,
|
|
imports: [infrastructureModule],
|
|
};
|
|
}
|
|
}
|