feat: App launcher modification

[alokmore-awts]

What

• App launcher configuration & modification
• The App Launcher’s JSON will be stored in the database. If it exists for a specific organization, use that JSON. If it does not exist in the database, then use the default appLauncher.json file.
• CSS changes for the billing page

---

Important

App launcher now uses organization-specific JSON from the database if available, with CSS updates for the billing page and organization slice modifications.

• App Launcher:
  • AppLauncher.tsx: Uses organization-specific JSON from the database if available, otherwise defaults to appLauncher.json.
  • Filters out the current app from the launcher list.
• Organization Slice:
  • orgSlice.ts: Adds appLaunchDetails to OrgInfo interface.
• CSS Changes:
  • Billing.tsx: Updates button CSS class for the billing page.

^{This description was created by for ef1f06d. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed everything up to b840d8e in 1 minute and 30 seconds. Click for details.

• Reviewed 87 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 3 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/layout/header.tsx:45

• Draft comment:
  Ensure that defaultOrg.appLaunchDetails is defined and its type matches the OrgInfo interface for consistency.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. src/features/profile/components/Billing.tsx:72

• Draft comment:
  Verify that the 'text-primary-foreground' utility class is defined and provides the intended text contrast.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. src/lib/orgSlice.ts:14

• Draft comment:
  Consider using a more specific type than 'object[]' for appLaunchDetails (e.g., AppLauncherInterface[]) to improve type safety and clarity.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment makes a valid point about type safety - using object[] is very generic and loses TypeScript's benefits. However, without seeing the actual shape of the appLaunchDetails data or related files, we can't be certain what the correct type should be. The comment doesn't provide specific guidance on what the type should look like. I might be too harsh - even a vague suggestion to improve type safety could be valuable. The author might know exactly what type to use. While the suggestion has merit, without concrete guidance on the expected type, the comment isn't actionable enough. The author would need to guess or investigate further. The comment should be deleted because it doesn't provide specific enough guidance to be actionable, and we don't have enough context to know the correct type.

Workflow ID: wflow_LIZQ3yzIWJGc094u

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed ef1f06d in 52 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/components/AppLauncher.tsx:48

• Draft comment:
  Direct cast to AppLauncherInterface[] is used here now; ensure that selectedOrg.appLaunchDetails is indeed of this type. If the data structure isn’t guaranteed, consider validating it before casting.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The code already has runtime checks for array type and length. The type cast was simplified, which is actually an improvement. The comment suggests adding validation, but doesn't specify what validation would be needed. The interface is simple and the properties would be validated when used later in the code anyway. The comment could be right that runtime validation of the object properties would add safety. We don't know if appLaunchDetails could contain malformed data. The comment violates rules by asking for verification ("ensure that...") and being speculative. Any malformed data would be caught when the properties are actually used in the render. Delete the comment. It asks for verification, is speculative, and any real issues would be caught at runtime when the properties are used.

Workflow ID: wflow_MJzanqZ80fcagUu7

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}