feat: add TicketSummary block #357
Conversation
…for priority notifications
…s' in configuration files
…k for EN, DE, and PL
…ary and TicketList components
…for priority notifications
…priority notifications
…out for better responsiveness
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including You can disable this status message by setting the WalkthroughAdds two new blocks (NotificationSummary, TicketSummary) across API, frontend, SDK, CMS models, mocked integrations, mappings, packaging and tooling; registers and imports the blocks in apps; updates generator templates to use the Changes
Sequence Diagram(s)sequenceDiagram
participant Browser
participant NextServer as Next.js Server
participant FrontSDK as Frontend SDK
participant API as NestJS API
participant CMS as CMS Module
participant Store as Notifications/Tickets Service
Note over Browser,NextServer: User requests page with Summary renderer
Browser->>NextServer: Render SummaryRenderer(id, accessToken, routing)
NextServer->>FrontSDK: sdk.blocks.get*Summary*(query, headers)
FrontSDK->>API: HTTP GET /blocks/*-summary* (AppHeaders + optional Authorization)
API->>CMS: getCmsEntry(id, locale)
API->>Store: getNotifications / getTickets(locale)
CMS-->>API: cms block configuration
Store-->>API: data list
API->>API: map*Summary*(cms, data, locale)
API-->>FrontSDK: SummaryBlock
FrontSDK-->>NextServer: SummaryBlock
NextServer->>Browser: render client pure component with fetched SummaryBlock
Browser->>Browser: UI renders InfoCards (variant styling)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Areas needing extra attention:
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
Tip 📝 Customizable high-level summaries are now available in beta!You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.
Example instruction:
Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
♻️ Duplicate comments (1)
packages/blocks/notification-summary/eslint.config.mjs (1)
1-18: Same ESLint configuration syntax concern.This file uses the same
defineConfigimport andextendspattern aspackages/blocks/ticket-summary/eslint.config.mjs. Please ensure the verification from that file's review applies here as well.
🧹 Nitpick comments (13)
packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
3-8: TicketSummary CMS model matches existing patterns; specialized card type could be a later enhancementThe shape mirrors
NotificationSummaryBlock(status fields typed asInfoCard.InfoCardpluslayout), which keeps CMS models consistent. If TicketSummary cards evolve to need more specific fields (e.g. numeric value, color), consider introducing a dedicatedTicketSummaryInfoCardCMS model instead of overloadingInfoCard.InfoCard, but this is purely a future-proofing concern, not a blocker now.packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (1)
3-79: Locale‑specific mocks are fine; consider stricter locale typing if you expand usageThe three mocked
NotificationSummaryBlockvariants and themapNotificationSummaryBlockswitch are straightforward and match the CMS model. If this mapper starts being reused beyond simple mocks, you may want to (a) narrowlocalefromstringto a union (e.g.'en' | 'de' | 'pl'or a sharedLocaletype) and/or (b) centralize the mapping in a dictionary to reduce repetition, but it’s not necessary for the current scope.Also applies to: 81-92
packages/blocks/ticket-summary/src/frontend/TicketSummary.client.tsx (1)
15-25: Tidy up props handling and consider more stable keys for InfoCard listThe component wiring and layout logic look solid. Two small cleanups you might consider:
- You don’t need the intermediate spread into
component; you can destructure directly in the parameter list for clarity and to avoid an extra object copy.- If
infoCardsever becomes dynamic (insertions/reordering), an index key can hurt React reconciliation. If there’s any stable identifier on the card (e.g. anid), preferring that would be safer.For example:
-export const TicketSummaryPure: React.FC<TicketSummaryPureProps> = ({ ...component }) => { - const { infoCards, layout } = component; +export const TicketSummaryPure: React.FC<TicketSummaryPureProps> = ({ infoCards, layout }) => { @@ - {infoCards.map((infoCard, index) => ( + {infoCards.map((infoCard, index) => ( <InfoCard - key={index} + key={infoCard.title ?? index}If
titleisn’t unique/guaranteed, keeping the index key is acceptable given this is a simple summary block.apps/api-harmonization/src/modules/page/page.model.ts (1)
29-30: Comment markers suggest code generation.The
// BLOCK IMPORTand// BLOCK REGISTERmarkers (also on line 79) appear to be placeholders for automated code generation. If these are used by a code generator, consider adding a brief comment explaining their purpose for maintainability.packages/blocks/notification-summary/src/frontend/NotificationSummary.renderer.tsx (1)
17-26: Consider simplifying the fallback structure.The outer fragment wrapper around the fallback div is unnecessary. You can simplify the code slightly:
<Suspense key={id} fallback={ - <> <div className="w-full flex gap-6"> <Loading bars={0} /> <Loading bars={0} /> </div> - </> } >packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.mapper.ts (2)
20-46: Consider extracting hardcoded color values to a constant.The color values (
text-badge-default-background,text-badge-secondary-background,text-muted-foreground) are hardcoded in the mapper. Consider extracting these to a configuration constant or deriving them from a status-to-color mapping for better maintainability.Example refactor:
+const STATUS_COLORS = { + OPEN: 'text-badge-default-background', + IN_PROGRESS: 'text-badge-secondary-background', + CLOSED: 'text-muted-foreground', +} as const; + export const mapTicketSummary = ( cms: CMS.Model.TicketSummaryBlock.TicketSummaryBlock, tickets: Tickets.Model.Tickets, _locale: string, ): TicketSummaryBlock => { // ... statusCounts logic ... if (cms.open) { infoCards.push({ title: cms.open.title, icon: cms.open.icon, value: statusCounts.OPEN || 0, description: cms.open.message, - color: 'text-badge-default-background', + color: STATUS_COLORS.OPEN, }); } // ... similar changes for inProgress and closed
8-8: Unused parameter: Consider removing or using the locale parameter.The
_localeparameter is prefixed with an underscore indicating it's intentionally unused, but it's passed through the function chain. If locale is not needed for ticket summary mapping, consider removing it from the signature. If it might be needed in the future for localization, the current approach is acceptable.packages/blocks/ticket-summary/src/sdk/index.ts (1)
16-20: Address @ts-expect-error suppressions for logger configuration.The logger configuration uses
@ts-expect-errorto suppress type errors. While the comment mentions "missing types," this could hide actual type mismatches. Consider defining proper types for the logger configuration or validating that the environment variables match expected types.// Define proper logger config types type LogLevel = 'debug' | 'info' | 'warn' | 'error'; type LogFormat = 'json' | 'pretty'; const internalSdk = getSdk({ apiUrl: API_URL!, logger: { level: (process.env.NEXT_PUBLIC_LOG_LEVEL as LogLevel) || 'info', format: (process.env.NEXT_PUBLIC_LOG_FORMAT as LogFormat) || 'json', colorsEnabled: process.env.NEXT_PUBLIC_LOG_COLORS_ENABLED === 'true', }, });packages/blocks/notification-summary/src/frontend/NotificationSummary.client.tsx (2)
41-41: Consider using a stable key instead of array index.Using array index as the React
keyprop can cause issues if theinfoCardsarray order changes or items are added/removed. IfinfoCardhas a unique identifier (likeidor a combination oftitleandvariant), use that instead.{infoCards.map((infoCard, index) => { // ... return ( <InfoCard - key={index} + key={infoCard.id || `${infoCard.title}-${index}`} title={infoCard.title} // ... /> ); })}
33-37: Type assertion in variant mapping may hide type mismatches.The variant mapping uses a type assertion with
as keyof typeofwhich bypasses type checking. IfinfoCard.variantdoesn't match one of the expected keys innotificationSummaryVariants, the mapping will silently fail andcolorClasswill beundefined.const colorClass = infoCard.variant ? Mappings.NotificationSummary.notificationSummaryVariants[ infoCard.variant as keyof typeof Mappings.NotificationSummary.notificationSummaryVariants ] ?? 'text-foreground' // Fallback color : undefined;Or add runtime validation:
const getColorClass = (variant: string | undefined) => { if (!variant) return undefined; const variantKey = variant as keyof typeof Mappings.NotificationSummary.notificationSummaryVariants; if (!(variantKey in Mappings.NotificationSummary.notificationSummaryVariants)) { console.warn(`Unknown variant: ${variant}`); return undefined; } return Mappings.NotificationSummary.notificationSummaryVariants[variantKey]; };packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (1)
23-26: Silent error handling may degrade user experience.The error handling logs to console and returns
null, which provides no feedback to the user if the block fails to load. Consider:
- User feedback: Render an error message or fallback UI instead of
null- Monitoring: Log errors to a monitoring service (not just console) for production debugging
- Error propagation: Consider whether errors should bubble up to an error boundary
} catch (error) { // Log to monitoring service (e.g., Sentry) logger.error('Error fetching TicketSummary block', { error, id, locale }); // Provide user feedback return ( <div className="p-4 text-center text-muted-foreground"> <p>Unable to load ticket summary. Please try again later.</p> </div> ); }packages/blocks/notification-summary/src/sdk/index.ts (1)
9-14: Consider API_URL null safety.The non-null assertion
API_URL!on line 14 could cause runtime errors if all environment variables (NEXT_PUBLIC_API_URL_INTERNALandNEXT_PUBLIC_API_URL) are undefined. Consider adding a runtime check or providing a sensible default.Apply this diff:
const API_URL = (typeof window === 'undefined' ? process.env.NEXT_PUBLIC_API_URL_INTERNAL : process.env.NEXT_PUBLIC_API_URL) || - process.env.NEXT_PUBLIC_API_URL; + process.env.NEXT_PUBLIC_API_URL || + 'http://localhost:3000'; const internalSdk = getSdk({ - apiUrl: API_URL!, + apiUrl: API_URL,packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (1)
5-63: Mapper aggregation looks correct; consider minor type/title refinementsThe priority aggregation and infoCard construction look solid and match the CMS models; using
|| 0avoids issues when a given priority is absent in the data. Given the upstream service intentionally caps notifications at 1000 items, thereduce-based aggregation is reasonable for this use case. Based on learningsTwo optional refinements you might consider:
- If the notification priority type is broader than
'LOW' | 'MEDIUM' | 'HIGH' | 'CRITICAL', theRecord<...>cast could hide mismatches; tightening the notification type (or validating before incrementing) would make this safer.- The CMS
NotificationSummaryBlockmodel exposes atitle?property; if the harmonizedNotificationSummaryBlock(viaModels.Block.Block) also supportstitle, consider mappingtitle: cms.titlein the return object so the block doesn’t silently drop that metadata.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (68)
.changeset/cold-showers-camp.md(1 hunks)apps/api-harmonization/package.json(2 hunks)apps/api-harmonization/src/app.module.ts(3 hunks)apps/api-harmonization/src/modules/page/page.model.ts(3 hunks)apps/frontend/package.json(2 hunks)apps/frontend/src/blocks/renderBlocks.tsx(3 hunks)packages/blocks/notification-summary/.gitignore(1 hunks)packages/blocks/notification-summary/.prettierrc.mjs(1 hunks)packages/blocks/notification-summary/eslint.config.mjs(1 hunks)packages/blocks/notification-summary/lint-staged.config.mjs(1 hunks)packages/blocks/notification-summary/package.json(1 hunks)packages/blocks/notification-summary/src/api-harmonization/index.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.client.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.controller.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.module.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.request.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts(1 hunks)packages/blocks/notification-summary/src/frontend/NotificationSummary.client.stories.tsx(1 hunks)packages/blocks/notification-summary/src/frontend/NotificationSummary.client.tsx(1 hunks)packages/blocks/notification-summary/src/frontend/NotificationSummary.renderer.tsx(1 hunks)packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx(1 hunks)packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts(1 hunks)packages/blocks/notification-summary/src/frontend/index.ts(1 hunks)packages/blocks/notification-summary/src/sdk/index.ts(1 hunks)packages/blocks/notification-summary/src/sdk/notification-summary.ts(1 hunks)packages/blocks/notification-summary/tsconfig.api.json(1 hunks)packages/blocks/notification-summary/tsconfig.frontend.json(1 hunks)packages/blocks/notification-summary/tsconfig.json(1 hunks)packages/blocks/notification-summary/tsconfig.sdk.json(1 hunks)packages/blocks/ticket-list/src/frontend/TicketList.renderer.tsx(1 hunks)packages/blocks/ticket-summary/.gitignore(1 hunks)packages/blocks/ticket-summary/.prettierrc.mjs(1 hunks)packages/blocks/ticket-summary/eslint.config.mjs(1 hunks)packages/blocks/ticket-summary/lint-staged.config.mjs(1 hunks)packages/blocks/ticket-summary/package.json(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/index.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.client.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.controller.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.mapper.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.module.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.request.ts(1 hunks)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.service.ts(1 hunks)packages/blocks/ticket-summary/src/frontend/TicketSummary.client.stories.tsx(1 hunks)packages/blocks/ticket-summary/src/frontend/TicketSummary.client.tsx(1 hunks)packages/blocks/ticket-summary/src/frontend/TicketSummary.renderer.tsx(1 hunks)packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx(1 hunks)packages/blocks/ticket-summary/src/frontend/TicketSummary.types.ts(1 hunks)packages/blocks/ticket-summary/src/frontend/index.ts(1 hunks)packages/blocks/ticket-summary/src/sdk/index.ts(1 hunks)packages/blocks/ticket-summary/src/sdk/ticket-summary.ts(1 hunks)packages/blocks/ticket-summary/tsconfig.api.json(1 hunks)packages/blocks/ticket-summary/tsconfig.frontend.json(1 hunks)packages/blocks/ticket-summary/tsconfig.json(1 hunks)packages/blocks/ticket-summary/tsconfig.sdk.json(1 hunks)packages/framework/src/modules/cms/cms.model.ts(1 hunks)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts(1 hunks)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts(1 hunks)packages/integrations/mocked/src/modules/cms/cms.service.ts(4 hunks)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts(1 hunks)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.ticket-summary.mapper.ts(1 hunks)packages/integrations/mocked/src/modules/cms/mappers/mocks/pages/notification-list.page.ts(3 hunks)packages/integrations/mocked/src/modules/cms/mappers/mocks/pages/ticket-list.page.ts(3 hunks)packages/utils/frontend/src/mappings/index.ts(1 hunks)packages/utils/frontend/src/mappings/notification-summary.ts(1 hunks)turbo/generators/config.ts(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-13T15:35:13.276Z
Learnt from: marcinkrasowski
Repo: o2sdev/openselfservice PR: 348
File: packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts:23-27
Timestamp: 2025-11-13T15:35:13.276Z
Learning: In the notification-summary block service (packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts), the hardcoded limit of 1000 notifications when calling notificationService.getNotificationList() is intentional, as there is no server-side aggregation API available for fetching notification counts by priority.
Applied to files:
packages/framework/src/modules/cms/models/blocks/notification-summary.model.tspackages/blocks/notification-summary/src/sdk/notification-summary.tspackages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts.changeset/cold-showers-camp.mdpackages/blocks/notification-summary/src/api-harmonization/notification-summary.request.tspackages/blocks/notification-summary/src/api-harmonization/notification-summary.controller.tspackages/blocks/notification-summary/src/api-harmonization/notification-summary.module.tspackages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.tspackages/blocks/notification-summary/package.jsonpackages/blocks/notification-summary/src/api-harmonization/notification-summary.service.tspackages/integrations/mocked/src/modules/cms/cms.service.tspackages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsxpackages/blocks/notification-summary/src/api-harmonization/index.ts
🧬 Code graph analysis (35)
packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/utils/models/info-card.ts (1)
InfoCard(3-9)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.request.ts (2)
packages/integrations/strapi-cms/generated/strapi.ts (1)
Omit(14-14)packages/framework/src/modules/cms/cms.request.ts (1)
GetCmsEntryParams(1-4)
packages/blocks/notification-summary/src/sdk/notification-summary.ts (6)
packages/blocks/notification-summary/src/api-harmonization/index.ts (1)
URL(1-1)packages/blocks/notification-summary/src/api-harmonization/notification-summary.client.ts (1)
URL(1-1)packages/blocks/notification-summary/src/sdk/index.ts (1)
sdk(24-28)packages/blocks/notification-summary/src/api-harmonization/notification-summary.request.ts (1)
GetNotificationSummaryBlockQuery(3-5)packages/framework/src/utils/models/headers.ts (1)
AppHeaders(1-6)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.mapper.ts (2)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (2)
TicketSummaryBlock(11-15)TicketSummaryInfoCard(3-9)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)
packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (2)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/framework/src/utils/models/info-card.ts (1)
InfoCard(3-9)
packages/blocks/ticket-summary/src/sdk/index.ts (2)
packages/framework/src/sdk.ts (1)
extendSdk(140-148)packages/blocks/ticket-summary/src/sdk/ticket-summary.ts (1)
ticketSummary(10-32)
apps/frontend/src/blocks/renderBlocks.tsx (4)
packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx (1)
NotificationSummary(12-29)packages/blocks/notification-summary/src/frontend/index.ts (1)
NotificationSummary(2-2)packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (1)
TicketSummary(12-27)packages/blocks/ticket-summary/src/frontend/index.ts (1)
TicketSummary(2-2)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.client.ts (1)
packages/blocks/ticket-summary/src/api-harmonization/index.ts (1)
URL(1-1)
packages/blocks/ticket-summary/src/sdk/ticket-summary.ts (5)
packages/blocks/ticket-summary/src/api-harmonization/index.ts (1)
URL(1-1)packages/blocks/ticket-summary/src/sdk/index.ts (1)
sdk(24-28)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.request.ts (1)
GetTicketSummaryBlockQuery(3-5)packages/framework/src/utils/models/headers.ts (1)
AppHeaders(1-6)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)
packages/blocks/notification-summary/src/sdk/index.ts (2)
packages/framework/src/sdk.ts (1)
extendSdk(140-148)packages/blocks/notification-summary/src/sdk/notification-summary.ts (1)
notificationSummary(10-32)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.request.ts (2)
packages/integrations/strapi-cms/generated/strapi.ts (1)
Omit(14-14)packages/framework/src/modules/cms/cms.request.ts (1)
GetCmsEntryParams(1-4)
packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
packages/blocks/notification-summary/src/frontend/NotificationSummary.renderer.tsx (3)
packages/blocks/notification-summary/src/frontend/index.ts (2)
NotificationSummaryRenderer(3-3)NotificationSummary(2-2)packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts (1)
NotificationSummaryRendererProps(14-16)packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx (1)
NotificationSummary(12-29)
packages/framework/src/modules/cms/cms.model.ts (4)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)
packages/blocks/notification-summary/src/frontend/NotificationSummary.client.tsx (5)
packages/blocks/notification-summary/src/frontend/index.ts (1)
NotificationSummaryPure(1-1)packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts (1)
NotificationSummaryPureProps(12-12)packages/ui/src/lib/utils.ts (1)
cn(5-7)packages/ui/src/components/DynamicIcon/DynamicIcon.tsx (1)
DynamicIcon(8-38)packages/ui/src/components/DynamicIcon/DynamicIcon.types.ts (1)
DynamicIconProps(1-7)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.controller.ts (3)
packages/blocks/notification-summary/src/api-harmonization/index.ts (1)
URL(1-1)packages/framework/src/utils/logger.ts (1)
LoggerService(77-563)packages/blocks/notification-summary/src/api-harmonization/notification-summary.request.ts (1)
GetNotificationSummaryBlockQuery(3-5)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.module.ts (2)
apps/api-harmonization/src/app.module.ts (1)
Module(82-156)packages/blocks/notification-summary/src/api-harmonization/index.ts (3)
NotificationSummaryBlockModule(3-3)NotificationSummaryService(4-4)NotificationSummaryController(5-5)
apps/api-harmonization/src/app.module.ts (4)
packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx (1)
NotificationSummary(12-29)packages/blocks/notification-summary/src/frontend/index.ts (1)
NotificationSummary(2-2)packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (1)
TicketSummary(12-27)packages/blocks/ticket-summary/src/frontend/index.ts (1)
TicketSummary(2-2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (2)
NotificationSummaryBlock(11-15)NotificationSummaryInfoCard(3-9)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts (6)
packages/integrations/mocked/src/modules/cms/cms.service.ts (1)
Injectable(43-200)packages/blocks/notification-summary/src/api-harmonization/notification-summary.request.ts (1)
GetNotificationSummaryBlockQuery(3-5)packages/framework/src/utils/models/headers.ts (1)
AppHeaders(1-6)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (1)
mapNotificationSummary(5-63)
packages/blocks/ticket-summary/src/frontend/TicketSummary.renderer.tsx (4)
packages/blocks/ticket-summary/src/frontend/index.ts (2)
TicketSummaryRenderer(3-3)TicketSummary(2-2)packages/blocks/ticket-summary/src/frontend/TicketSummary.types.ts (1)
TicketSummaryRendererProps(14-16)packages/ui/src/components/Container/Container.tsx (1)
Container(42-62)packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (1)
TicketSummary(12-27)
packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.ticket-summary.mapper.ts (2)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.service.ts (7)
packages/integrations/mocked/src/modules/cms/cms.service.ts (1)
Injectable(43-200)packages/blocks/ticket-summary/src/api-harmonization/index.ts (1)
TicketSummaryService(4-4)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.request.ts (1)
GetTicketSummaryBlockQuery(3-5)packages/framework/src/utils/models/headers.ts (1)
AppHeaders(1-6)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.mapper.ts (1)
mapTicketSummary(5-54)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.module.ts (2)
apps/api-harmonization/src/app.module.ts (1)
Module(82-156)packages/blocks/ticket-summary/src/api-harmonization/index.ts (3)
TicketSummaryBlockModule(3-3)TicketSummaryService(4-4)TicketSummaryController(5-5)
packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts (3)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)packages/integrations/strapi-cms/generated/strapi.ts (1)
Omit(14-14)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.controller.ts (4)
packages/blocks/ticket-summary/src/api-harmonization/index.ts (1)
URL(1-1)packages/framework/src/utils/logger.ts (1)
LoggerService(77-563)packages/framework/src/utils/models/headers.ts (1)
AppHeaders(1-6)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.request.ts (1)
GetTicketSummaryBlockQuery(3-5)
packages/integrations/mocked/src/modules/cms/cms.service.ts (4)
packages/framework/src/modules/cms/cms.request.ts (1)
GetCmsEntryParams(1-4)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (1)
mapNotificationSummaryBlock(81-92)packages/integrations/mocked/src/utils/delay.ts (1)
responseDelay(4-7)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.ticket-summary.mapper.ts (1)
mapTicketSummaryBlock(66-75)
packages/blocks/ticket-summary/src/frontend/TicketSummary.types.ts (2)
packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/integrations/strapi-cms/generated/strapi.ts (1)
Omit(14-14)
apps/api-harmonization/src/modules/page/page.model.ts (6)
packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (1)
TicketSummary(12-27)packages/blocks/ticket-summary/src/api-harmonization/ticket-summary.model.ts (1)
TicketSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/ticket-summary.model.ts (1)
TicketSummaryBlock(3-9)packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx (1)
NotificationSummary(12-29)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(11-15)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx (2)
packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts (1)
NotificationSummaryProps(5-10)packages/blocks/notification-summary/src/sdk/index.ts (1)
sdk(24-28)
packages/blocks/ticket-summary/src/frontend/TicketSummary.client.tsx (5)
packages/blocks/ticket-summary/src/frontend/TicketSummary.types.ts (1)
TicketSummaryPureProps(12-12)packages/ui/src/lib/utils.ts (1)
cn(5-7)packages/framework/src/utils/models/info-card.ts (1)
InfoCard(3-9)packages/ui/src/components/DynamicIcon/DynamicIcon.tsx (1)
DynamicIcon(8-38)packages/ui/src/components/DynamicIcon/DynamicIcon.types.ts (1)
DynamicIconProps(1-7)
packages/blocks/ticket-summary/src/frontend/TicketSummary.server.tsx (2)
packages/blocks/ticket-summary/src/frontend/TicketSummary.types.ts (1)
TicketSummaryProps(5-10)packages/blocks/ticket-summary/src/sdk/index.ts (1)
sdk(24-28)
packages/blocks/notification-summary/src/frontend/NotificationSummary.client.stories.tsx (1)
packages/blocks/notification-summary/src/frontend/NotificationSummary.client.tsx (1)
NotificationSummaryPure(17-65)
🪛 Gitleaks (8.29.0)
packages/blocks/ticket-summary/src/frontend/TicketSummary.client.stories.tsx
[high] 54-54: Uncovered a JSON Web Token, which may lead to unauthorized access to web applications and sensitive user data.
(jwt)
packages/blocks/notification-summary/src/frontend/NotificationSummary.client.stories.tsx
[high] 47-47: Uncovered a JSON Web Token, which may lead to unauthorized access to web applications and sensitive user data.
(jwt)
packages/blocks/notification-summary/src/frontend/NotificationSummary.server.tsx
Show resolved
Hide resolved
packages/blocks/notification-summary/src/frontend/NotificationSummary.types.ts
Show resolved
Hide resolved
packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts
Show resolved
Hide resolved
|
@coderabbitai help |
ChatThere are 3 ways to chat with CodeRabbit:
CodeRabbit commands
Other keywords and placeholders
CodeRabbit configuration file (
|
|
Note Docstrings generation - SUCCESS |
Docstrings generation was requested by @michnowak. * #357 (comment) The following files were modified: * `turbo/generators/config.ts`
|
Note Unit test generation is an Early Access feature. Expect some limitations and changes as we gather feedback and continue to improve it. Generating unit tests... This may take up to 20 minutes. |
|
Caution The CodeRabbit agent failed during execution: Clone operation failed |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/blocks/ticket-summary/package.json (1)
41-54: Harmonize peer dependency version constraints.The peer dependencies show an inconsistency:
next-intlspecifies an exact version ("4.1.0"), while all other peer dependencies use caret ranges (^). Consider aligning the strategy:
- If this version is critical for compatibility, document why in a comment or CHANGELOG
- Otherwise, use
"^4.1.0"for consistency with other peersThis is a minor polish issue but helps maintain consistency across the package ecosystem.
- "next-intl": "^4.1.0" + "next-intl": "4.1.0"Or, if flexible:
- "next-intl": "4.1.0" + "next-intl": "^4.1.0"Align based on your versioning strategy and release cadence.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/blocks/ticket-summary/package.json(1 hunks)
🔇 Additional comments (1)
packages/blocks/ticket-summary/package.json (1)
3-3: Note: Initial version number.The package is initialized at
"0.0.1". This is appropriate for a new block feature. Ensure your release process and CHANGELOG document this initial version appropriately for consumers.
marcinkrasowski
left a comment
marcinkrasowski
left a comment
There was a problem hiding this comment.
I don't think the yellow on gray background is sufficient to meet the contrast ratio
packages/blocks/notification-summary/src/frontend/NotificationSummary.client.tsx
Show resolved
Hide resolved
… use NotificationPriority type
I replaced the yellow one with default muted color version. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/ui/src/components/Cards/InfoCard/InfoCard.tsx (1)
17-18: Replaceitems-topwithitems-startfor proper alignment
items-topis not a valid Tailwind utility class. Useitems-startto align flex/grid items to the top.<div className="flex flex-row justify-between items-start gap-2"> <Typography variant="subtitle">{title}</Typography>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
packages/ui/src/components/Cards/InfoCard/InfoCard.tsx(1 hunks)packages/utils/frontend/src/mappings/ticket-summary.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/utils/frontend/src/mappings/ticket-summary.ts
🔇 Additional comments (1)
packages/ui/src/components/Cards/InfoCard/InfoCard.tsx (1)
32-33: Conditional button wrapper change looks goodRendering the button container only when
buttonis provided avoids an empty flex child and better matches cards that legitimately have no action. The pattern{button && …}is appropriate here and should work cleanly with the new summary blocks.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.changeset/plain-moons-notice.md (1)
13-13: Expand the changelog entry to reflect the scope of changes.The description is too narrow. It only mentions the InfoCard button rendering, but this PR primarily introduces new
TicketSummaryandNotificationSummaryblocks with supporting infrastructure across multiple packages (API harmonization, frontend mappings, framework models, mocked integrations, etc.). The changelog entry should capture the core value proposition to users and maintainers.Consider revising to something like:
-conditionally render button in InfoCard for improved layout +Add TicketSummary and NotificationSummary blocks with dynamic rendering support; improve InfoCard layout by conditionally rendering buttonYou may also want to mention the accessibility fix if it's a user-facing improvement (though that can be secondary).
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (1)
20-42: Consider extracting the priorities constant for reusability.The priorities array is defined inline. If this priority list is used elsewhere in the notification-summary module, consider extracting it to a module-level constant for consistency and maintainability.
Example:
const NOTIFICATION_PRIORITIES: Notifications.Model.NotificationPriority[] = [ 'CRITICAL', 'HIGH', 'MEDIUM', 'LOW' ];Then reference it in the mapper:
- const priorities = ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW'] as Notifications.Model.NotificationPriority[]; + const priorities = NOTIFICATION_PRIORITIES;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
apps/api-harmonization/package.json(2 hunks)apps/frontend/package.json(2 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts(1 hunks)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/api-harmonization/package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-13T15:35:13.879Z
Learnt from: marcinkrasowski
Repo: o2sdev/openselfservice PR: 348
File: packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts:23-27
Timestamp: 2025-11-13T15:35:13.879Z
Learning: In the notification-summary block service (packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts), the hardcoded limit of 1000 notifications when calling notificationService.getNotificationList() is intentional, as there is no server-side aggregation API available for fetching notification counts by priority.
Applied to files:
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.tspackages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts
🧬 Code graph analysis (2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (2)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (2)
NotificationSummaryBlock(12-16)NotificationSummaryInfoCard(5-11)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(3-10)
🔇 Additional comments (10)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (2)
1-3: LGTM!The imports are clean and necessary for the class definitions below.
5-16: LGTM!The model definitions are well-structured:
- Appropriate use of definite assignment (
!) for required fields- Clear separation between info card metadata and block structure
- The array-based
infoCardsdesign provides flexibility compared to the CMS model's individual priority propertiesThis harmonization approach allows for dynamic priority handling and cleaner iteration logic in the mapper.
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts (5)
1-5: LGTM!All imports are properly referenced and necessary for the mapper implementation.
7-11: LGTM!The function signature correctly accepts the CMS configuration, notifications data, and locale parameter. The underscore prefix on
_localeappropriately indicates it's currently unused, likely reserved for future internationalization support.
12-18: LGTM!The priority counts aggregation logic is clean and correct. Using
reducewith a typed accumulator ensures type safety while building the notification counts by priority.
44-50: LGTM!The return statement correctly constructs the
NotificationSummaryBlockwith all required fields properly mapped from the CMS configuration and computed info cards.
24-42: No issues found. All field mappings are correct and properly typed.The verification confirms:
Line 38's
cmsPriorityData.messagemapping is valid — thedescriptionfield exists and is properly typed inNotificationSummaryInfoCard(line 9 of notification-summary.model.ts).
cms.titleis mapped — line 35 correctly assignscmsPriorityData.titleto thetitlefield, so it is not unused.All mapped properties are properly defined — the infoCards object (lines 34-40) maps all fields (
title,icon,value,description,variant) to valid properties in theNotificationSummaryInfoCardmodel.apps/frontend/package.json (3)
17-41: Lock file is already committed to the repository—the main concern in this review is already mitigated.The
package-lock.jsonis tracked in git and contains 49,836 lines capturing all pinned dependency versions. This ensures reproducible builds despite the"*"specifiers, which is a standard Turborepo monorepo pattern used consistently across all packages in this repository.The
"*"specifier for@o2s/*internal packages is intentional governance, not an oversight. Semantic versioning is managed through changesets (e.g.,.changeset/cold-showers-camp.mduses"minor"for versioning), and the lock file guarantees reproducibility. This approach differs from external dependencies like Next.js (^15.5.6) and React (^19.2.0), which use semantic version ranges and are subject to transitive dependency updates.No action is required on the code.
52-52: All async APIs have been properly migrated to useawait— no action needed.The codebase has been correctly updated for Next.js 15.5.6. All instances of
headers(),params, and related async APIs in the frontend already useawait:
await headers()in not-found.tsx, [[...slug]]/page.tsx, login/page.tsxawait paramsin layout.tsx, not-found.tsx, [[...slug]]/page.tsx, login/page.tsxsearchParamsin API routes correctly extracted fromnew URL(req.url).searchParams(not the async API)- No
cookies()ordraftMode()usage detectedThe migration is complete and compliant with Next.js 15.5.6 requirements.
62-62: Based on my verification, I can now provide the rewritten review comment:
Zod 4 is installed but not actively used in this codebase — no action needed.
While Zod 4 does introduce breaking changes to error handling and validation APIs (as documented in the migration guide), analysis shows that Zod is not directly imported or used in the apps/frontend source code. The dependency appears to be transitive (likely pulled in by the
aipackage), which explicitly supports both Zod v3 and v4 ranges. Your codebase uses Yup for validation instead.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (1)
6-34: Consider more realistic mock values for better demo/testing experience.All
infoCardshavevalue: 0, which is valid but could be more engaging for demos or frontend testing. Consider using varied values (e.g., 3, 7, 12, 5) to better represent realistic notification counts across priority levels.Also applies to: 41-69, 76-104
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts(1 hunks)packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts(1 hunks)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts
- packages/blocks/notification-summary/src/api-harmonization/notification-summary.mapper.ts
🧰 Additional context used
🧬 Code graph analysis (1)
packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (2)
packages/framework/src/modules/cms/models/blocks/notification-summary.model.ts (1)
NotificationSummaryBlock(13-16)packages/blocks/notification-summary/src/api-harmonization/notification-summary.model.ts (1)
NotificationSummaryBlock(12-16)
🔇 Additional comments (3)
packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (3)
1-2: LGTM!The import is clean and correctly references the framework module.
108-119: LGTM!The mapper function is well-structured with a clear switch statement and sensible default fallback to English for unrecognized locales. The explicit return type provides good type safety.
3-106: Shared ID across locale variants follows the established codebase pattern and is intentional—no issue found.The notification summary block correctly uses
'notification-summary-1'across all three locale variants (EN, DE, PL). This matches the pattern used consistently throughout the codebase (category-list, quick-links, ticket-summary, payments-summary, etc.). ThemapNotificationSummaryBlock()getter function returns one block at a time based on locale, never storing them together, so shared IDs pose no collision risk.Mock values of 0 are acceptable and consistent with other mocked blocks in the codebase; no action required.
…and streamline mapping logic
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/integrations/mocked/src/modules/cms/cms.service.ts (2)
105-107: Notification summary getter correctly mirrors existing block getters
getNotificationSummaryBlockuses the locale, delegates tomapNotificationSummaryBlock, and appliesresponseDelay(), matching the conventions of other*Blockmethods. No functional concerns here.Minor nit only: consider renaming
_optionstooptionsfor clarity, since it is actually used (unlike typical “intentionally unused” underscore parameters), but this is purely stylistic.
197-199: Ticket summary getter is correctly implemented and consistent
getTicketSummaryBlockfollows the same structure asgetOrdersSummaryBlockandgetPaymentsSummaryBlock: it readsoptions.locale, calls the mapper, and appliesresponseDelay(). This should integrate smoothly with the existing CMS.Service API.Same minor nit as above: if you want to keep naming uniform, you could either:
- rename this param to
_options(to mirrorgetTicketDetailsBlock), or- rename the underscore-params elsewhere to
options.Not required, just for consistency.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (6)
apps/api-harmonization/package.json(2 hunks)apps/api-harmonization/src/app.module.ts(3 hunks)apps/frontend/package.json(2 hunks)apps/frontend/src/blocks/renderBlocks.tsx(3 hunks)packages/blocks/ticket-list/src/frontend/TicketList.renderer.tsx(1 hunks)packages/integrations/mocked/src/modules/cms/cms.service.ts(4 hunks)
🚧 Files skipped from review as they are similar to previous changes (4)
- apps/api-harmonization/src/app.module.ts
- apps/api-harmonization/package.json
- apps/frontend/src/blocks/renderBlocks.tsx
- apps/frontend/package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-13T15:35:13.879Z
Learnt from: marcinkrasowski
Repo: o2sdev/openselfservice PR: 348
File: packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts:23-27
Timestamp: 2025-11-13T15:35:13.879Z
Learning: In the notification-summary block service (packages/blocks/notification-summary/src/api-harmonization/notification-summary.service.ts), the hardcoded limit of 1000 notifications when calling notificationService.getNotificationList() is intentional, as there is no server-side aggregation API available for fetching notification counts by priority.
Applied to files:
packages/integrations/mocked/src/modules/cms/cms.service.ts
🧬 Code graph analysis (1)
packages/integrations/mocked/src/modules/cms/cms.service.ts (4)
packages/framework/src/modules/cms/cms.request.ts (1)
GetCmsEntryParams(5-8)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.notification-summary.mapper.ts (1)
mapNotificationSummaryBlock(108-119)packages/integrations/mocked/src/utils/delay.ts (1)
responseDelay(4-7)packages/integrations/mocked/src/modules/cms/mappers/blocks/cms.ticket-summary.mapper.ts (1)
mapTicketSummaryBlock(87-96)
🔇 Additional comments (3)
packages/blocks/ticket-list/src/frontend/TicketList.renderer.tsx (1)
22-24: Suspense fallback simplification looks goodUsing a single
Loadinginside aw-full flexcontainer keeps behavior intact while simplifying the fallback layout; this is a safe, purely presentational change.packages/integrations/mocked/src/modules/cms/cms.service.ts (2)
15-15: Notification summary mapper import is consistentImport path and naming match existing block mappers; this cleanly wires the new notification summary block into the mocked CMS layer.
29-29: Ticket summary mapper import aligns with existing patternThis mirrors other ticket-related block mapper imports and keeps the CMS service wiring consistent.
What does this PR do?
Related Ticket(s)
Key Changes
How to test
Media (Loom or gif)
Summary by CodeRabbit
New Features
Style / Mappings
Bug Fixes
Chores
✏️ Tip: You can customize this high-level summary in your review settings.