Reviewing files that changed from the base of the PR and between c5a394e and 843aed0.

• .cursor/rules/api-rules.mdc (1 hunks)
• api/dev/Unraid.net/myservers.cfg (1 hunks)
• api/dev/ident.cfg (1 hunks)
• api/src/__test__/store/modules/paths.test.ts (2 hunks)
• api/src/customization/activation-code.dto.ts (1 hunks)
• api/src/store/modules/paths.ts (2 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.dto.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/.login.php (14 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/.login.php.last-download-time (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/DefaultPageLayout.php (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/DefaultPageLayout.php.last-download-time (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/Notifications.page.last-download-time (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/auth-request.php.last-download-time (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/generic-modification.spec.ts (2 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/.login.php.modified.snapshot.php (14 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/DefaultPageLayout.php.modified.snapshot.php (2 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/case-model-copier.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/default-page-layout.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/log-rotate.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/log-viewer.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/partner-logo-copier.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/patches/default-page-layout.patch (4 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/patches/sso.patch (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/set-password-modal.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/unraid-file-modifier.service.ts (1 hunks)

• GitHub Check: Build Web App
• GitHub Check: Cloudflare Pages

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/auth-request.php.last-download-time (1)

1-1: Approve fixture timestamp update.
The timestamp was bumped to reflect the latest download snapshot. No action needed.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/Notifications.page.last-download-time (1)

1-1: Approve fixture timestamp update.
Updated notification fixture timestamp to match the new UI changes. All good.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/DefaultPageLayout.php.last-download-time (1)

1-1: Approve fixture timestamp update.
The DefaultPageLayout fixture timestamp is updated to align with UI customization tests. Looks good.

api/dev/Unraid.net/myservers.cfg (1)

2-2: Verify version change.
[api].version was downgraded from "4.6.6" to "4.4.1". Please confirm this is intentional and compatible with downstream systems.

api/src/unraid-api/unraid-file-modifier/modifications/log-rotate.modification.ts (1)

10-10: Export style changed to default export

The change from named export to default export aligns with the broader refactoring mentioned in the summary, where modification classes are now dynamically imported using import.meta.glob.

api/dev/ident.cfg (1)

1-36: Configuration file looks good

This new configuration file contains appropriate default values for system and network settings. It will be used by the CustomizationService to modify identity parameters based on activation data.

api/src/__test__/store/modules/paths.test.ts (1)

19-36: Test updated to include new path keys

The snapshot test has been correctly updated to include the new path keys added to the store.

api/src/unraid-api/graph/resolvers/customization/activation-code.dto.ts (1)

12-76: Well-structured DTO with appropriate validations

The DTO is well-designed with proper validations for each field. The use of @IsOptional() for all fields makes sense for a configuration where not all fields may be provided. The string sanitization ensures that potentially harmful characters are removed.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/.login.php.last-download-time (1)

1-1: Timestamp updated for login.php fixture.

This timestamp update indicates the login.php test fixture was refreshed, likely reflecting the broader authentication system changes mentioned in the summary.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/generic-modification.spec.ts (2)

11-11: Import style aligned with module export change.

The import statement has been updated to use a default import for LogRotateModification, reflecting changes in the export style of that class.

---

39-39: Property order adjusted for consistency.

The order of properties in the SSOFileModification test case has been adjusted for better readability, with the class definition now appearing before the file URL.

api/src/unraid-api/unraid-file-modifier/modifications/log-viewer.modification.ts (1)

10-10: Changed to default export for consistency.

The export has been changed from a named export to a default export to align with a broader pattern change in file modification classes. This supports the dynamic loading of modifications implemented in the unraid-file-modifier.service.ts file.

.cursor/rules/api-rules.mdc (2)

3-3: Expanded glob pattern to include nested directories.

The glob pattern has been broadened from api/* to api/**/*,api/* to include all files recursively within the api directory, ensuring new nested files are properly covered by these rules.

---

11-11: Added new guideline for dependency mocking.

Added a sensible guideline to prefer not mocking simple dependencies, which should lead to more robust tests.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/DefaultPageLayout.php (3)

695-695: Partner logo replacement implemented correctly

The static Unraid logo link has been replaced with a PHP include for a partner logo. This is a good implementation that enables dynamic partner branding.

---

1294-1299: Improved page refresh behavior for extended viewing

The visibility change handler now conditionally checks if $myPage['Load'] is set and reloads the page when necessary, rather than always calling nchanFocusStart(). This provides better control over page reloading behavior for extended viewing sessions.

---

1325-1325: Modern notification component added

A new web component <uui-toaster> has been added to replace the legacy jGrowl notification system. This component properly inherits the notification position configuration from the existing settings.

api/src/unraid-api/unraid-file-modifier/unraid-file-modifier.service.ts (1)

39-49: Improved modification loading with dynamic imports

The implementation now uses import.meta.glob to dynamically load all modification files, making the codebase more maintainable and extendable. This follows the open/closed principle - new modifications can be added without changing this service.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/DefaultPageLayout.php.modified.snapshot.php (1)

695-695: Snapshot reflects partner logo replacement

The snapshot correctly reflects the partner logo PHP include replacement, ensuring tests will pass with the new implementation.

api/src/unraid-api/unraid-file-modifier/modifications/default-page-layout.modification.ts (2)

35-45: Well-implemented partner logo injection method

The injectPartnerLogo method correctly handles the replacement of the Unraid logo with a partner logo from the dynamix.my.servers plugin. The method includes proper checks to prevent duplicate replacements.

---

52-52: Transformation pipeline properly updated

The injectPartnerLogo method has been correctly added to the transformation pipeline in the applyToSource method.

api/src/unraid-api/unraid-file-modifier/modifications/patches/sso.patch (1)

20-21: Re-evaluate the 800-character threshold

Hard-coding strlen($password) > 800 risks rejecting valid (shorter) JWTs and accepting junk that simply exceeds the limit. Consider dropping the length gate altogether or using a far smaller sanity check (e.g. > 200) informed by real-world token sizes.

api/src/unraid-api/unraid-file-modifier/modifications/patches/default-page-layout.patch (2)

92-93: Verify $notify['position'] is always defined

<uui-toaster … position="<?= ($notify['position'] === 'center') ? 'top-center' : $notify['position'] ?>">

If $notify isn’t in scope at this point, PHP will emit a notice and default to null, producing an empty attribute. Please confirm the variable is set earlier or guard with isset($notify['position']) ? … : 'top-center'.

---

70-78: Residual JS may still reference the removed bell icon

The patch removes the #bell element and part of its update logic, but other scripts (e.g. openNotifier()) might still touch #bell or .nav-user. Scan the page scripts to ensure all references are gone to prevent runtime errors.

api/src/unraid-api/unraid-file-modifier/modifications/__test__/__fixtures__/downloaded/.login.php (8)

5-10: Improved session management logic.

The session initialization code has been refactored with proper formatting and explicit checks, making it more robust when verifying if an existing session is present.

---

20-54: Improved file handling functions with type hints.

The file utility functions have been enhanced with proper PHP return type hints and consistent formatting, making the code more maintainable and providing better IDE support.

---

64-88: Enhanced cleanupFails function with better formatting.

The function has been improved with consistent formatting while maintaining its original logic for cleaning up failed login attempts.

---

114-116: Simplified credential input fields.

The input fields have been simplified to only capture username and password, aligning with the removal of 2FA functionality.

---

125-135: Simplified login verification flow.

The login verification now only checks username and password credentials, with improved error handling and formatting.

---

427-438: Updated login form markup.

The login form has been simplified to remove 2FA-related elements while improving formatting and error message display.

---

446-459: Added cookie validation checks.

New JavaScript code has been added to verify that cookies are enabled in the browser, with a clear error message for users when cookies are disabled.

---

90-102:

Details

❌ Incorrect review comment

Security impact: Two-factor authentication has been removed.

The authentication function has been simplified to only verify username and password, removing the previous two-factor authentication capability. This is a significant change to the security model.

---

🏁 Script executed:

#!/bin/bash
# Check if there are any references to two-factor authentication in the codebase
# that might be affected by this change

echo "Checking for 2FA references in the codebase..."
rg -i "two-?factor|2fa|totp|authenticator" --type php

echo "Checking for SSO implementation that might replace 2FA..."
rg -i "sso|single sign-?on" --type php

Length of output: 4264

---

Test fixture only – no impact on production 2FA

The file you’re looking at lives under modifications/__test__/__fixtures__/downloaded/ and represents the raw, downloaded login script used in tests. Removing two-factor logic here does not alter any production authentication code or security model. You can safely ignore this fixture change—production 2FA remains untouched.

Likely an incorrect or invalid review comment.

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (9)

31-44: Well-implemented first boot setup check.

The method creates or checks for a flag file to determine if first boot setup has already run, with proper error handling and logging.

---

46-67: Path initialization with proper error handling.

The service properly initializes path properties with dynamic imports and includes error checking for critical paths.

---

103-141: Well-implemented activation data retrieval and validation.

The service properly retrieves and validates activation data using class-transformer and class-validator, with comprehensive error handling.

---

143-176: Comprehensive customization application workflow.

The method orchestrates the application of all customizations with proper error handling and logging.

---

178-201: Partner banner setup with proper file handling.

The method correctly copies the partner banner file with appropriate existence checks and error handling.

---

203-246: Display settings application using Redux store data.

The service properly retrieves current settings from the Redux store and applies new settings from activation data.

---

248-300: Case model configuration with proper error handling.

The method properly sets up a custom case model based on activation data, with appropriate file existence checks.

---

302-351: Server identity updates with proper API integration.

The service updates server identity settings and properly triggers system updates using the emcmd utility.

---

354-407: Generic INI configuration file update helper.

A well-implemented helper method for updating INI configuration files, with proper handling of missing files, section creation, and value updates.

Reviewing files that changed from the base of the PR and between 843aed0 and 6684f88.

• api/dev/activation/assets/case-model.png is excluded by !**/*.png
• api/dev/activation/assets/logo.svg is excluded by !**/*.svg
• api/src/__test__/store/modules/__snapshots__/paths.test.ts.snap is excluded by !**/*.snap
• api/src/unraid-api/graph/resolvers/customization/__snapshots__/customization.service.spec.ts.snap is excluded by !**/*.snap

• .cursor/rules/api-rules.mdc (1 hunks)
• .cursor/rules/default.mdc (1 hunks)
• api/.env.development (1 hunks)
• api/.env.test (1 hunks)
• api/dev/activation/.done (1 hunks)
• api/dev/activation/activation_code_12345.activationcode (1 hunks)
• api/generated-schema.graphql (4 hunks)
• api/src/__test__/store/modules/paths.test.ts (1 hunks)
• api/src/store/modules/paths.ts (2 hunks)
• api/src/unraid-api/auth/authentication.guard.ts (4 hunks)
• api/src/unraid-api/auth/public.decorator.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/base.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.dto.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.module.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/docker/docker.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/resolvers.module.ts (2 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/case-model-copier.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/partner-logo-copier.modification.ts (1 hunks)

• .cursor/rules/default.mdc
• api/src/unraid-api/graph/resolvers/docker/docker.model.ts
• api/dev/activation/.done
• api/.env.test
• api/src/unraid-api/auth/public.decorator.ts
• api/src/unraid-api/graph/resolvers/resolvers.module.ts
• api/src/unraid-api/graph/resolvers/customization/customization.module.ts
• api/.env.development
• api/dev/activation/activation_code_12345.activationcode
• api/src/unraid-api/graph/resolvers/base.model.ts
• api/src/unraid-api/unraid-file-modifier/modifications/partner-logo-copier.modification.ts

• .cursor/rules/api-rules.mdc
• api/src/unraid-api/unraid-file-modifier/modifications/case-model-copier.modification.ts
• api/src/store/modules/paths.ts

• GitHub Check: Test API
• GitHub Check: Build Web App
• GitHub Check: Cloudflare Pages

api/src/__test__/store/modules/paths.test.ts (1)

21-30: Use stringContaining for every dynamically-resolved dev path

'myservers-keepalive' is asserted against the literal string ./dev/Unraid.net/fb_keepalive, while most siblings use expect.stringContaining(...).
Should the base directory ever change (e.g., api/dev vs ./dev), this single hard-coded check will break. Align it with the other flexible assertions:

-        'myservers-keepalive': './dev/Unraid.net/fb_keepalive',
+        'myservers-keepalive': expect.stringContaining('Unraid.net/fb_keepalive'),

api/src/unraid-api/auth/authentication.guard.ts (1)

44-46: Constructor injection looks good

Injecting Reflector and calling super() is the recommended NestJS pattern; no issues spotted here.

api/generated-schema.graphql (4)

759-759: Appropriate addition of ACTIVATION_CODE to Resource enum

The new ACTIVATION_CODE resource type has been correctly added to the Resource enum, which will enable permission-based access control for activation code features.

---

1209-1209: Good addition of specification reference

Adding the @specifiedBy directive to the JSONObject scalar improves documentation by providing a reference to the official ECMA-404 specification.

---

1392-1424: Well-structured DTOs for activation code features

The three new object types (PublicPartnerInfoDto, ActivationCodeDto, and Customization) are properly defined with appropriate fields, types, and descriptions. The structure adequately supports the activation code and partner branding features.

---

1457-1458: Appropriate query endpoints for activation data

The two new query fields getActivationData and partnerInfo provide logical access points for retrieving customization data and partner information, respectively.

api/src/unraid-api/graph/resolvers/customization/activation-code.dto.ts (4)

7-7: Simple but effective hex color validation

This helper function correctly validates standard hex color formats with the # prefix.

---

32-40: Clean DTO for partner info

This DTO is correctly structured with appropriate field types and nullability settings.

---

42-103: Well-organized ActivationCodeDto with validation

The DTO implements thorough validation and sanitization for all fields. The use of class-validator decorators and transformation functions ensures that data is properly validated and cleansed.

The color fields correctly use the sanitization helper, and the theme/banner fields have appropriate enum validation.

---

105-129: Well-structured Customization class

Good organization with clear field descriptions and appropriate validation. The relative path approach for assets is a clean solution.

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (8)

30-43: Good implementation of boot setup flag mechanism

The method correctly creates and checks for the first boot setup flag, with appropriate logging and error handling.

---

101-119: Effective activation JSON file detection

The method properly handles directory access and file finding with good error handling.

---

121-141: Well-implemented activation data retrieval

The method correctly retrieves, parses, and validates the activation data, with proper error handling and documentation.

---

159-192: Comprehensive customization application orchestration

The method cleanly coordinates the application of all customization types with appropriate checks and error handling.

---

194-218: Partner banner setup with safe file operations

The method correctly handles file existence checks and copying with appropriate error handling and logging.

---

220-276: Display settings application with color formatting

The method correctly handles display settings application, including proper color format conversion (removing # from hex colors as required by the config).

---

278-329: Case model configuration with fallback options

The method intelligently handles different sources for the case model, with appropriate file checks and fallback options.

---

331-380: Server identity application with emcmd integration

The method correctly updates both the config file and triggers the emcmd utility to apply changes. Good state retrieval from the store and parameter preparation.

Reviewing files that changed from the base of the PR and between 6684f88 and 3f71df9.

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• web/__test__/store/activationCode.test.ts (1 hunks)
• web/components/Activation/ActivationModal.vue (2 hunks)
• web/components/Activation/ActivationPartnerLogo.vue (1 hunks)
• web/components/Activation/ActivationPartnerLogoImg.vue (1 hunks)
• web/components/Activation/WelcomeModal.ce.vue (4 hunks)
• web/components/Activation/graphql/activationCode.query.ts (1 hunks)
• web/components/Activation/store/activationCodeData.ts (1 hunks)
• web/components/Activation/store/activationCodeModal.ts (1 hunks)
• web/composables/gql/gql.ts (3 hunks)
• web/composables/gql/graphql.ts (17 hunks)
• web/store/activationCode.ts (0 hunks)
• web/store/server.ts (1 hunks)
• web/types/server.ts (1 hunks)

• web/store/activationCode.ts

• web/types/server.ts
• web/components/Activation/graphql/activationCode.query.ts

• api/generated-schema.graphql

• GitHub Check: Cloudflare Pages

web/components/Activation/ActivationPartnerLogoImg.vue (1)

8-8: Import path updated to match new modular store structure.

The import path has been updated to use the new dedicated activation code modal store location, which aligns with the broader architectural changes where activation code functionality has been modularized.

web/store/server.ts (2)

48-48: Import path updated to match new modular store structure.

The import path has been updated to use the new dedicated activation code modal store location, which aligns with the broader architectural changes where activation code functionality has been modularized.

---

1116-1119:

Details

❌ Incorrect review comment

Code still references activation code store but not activationCodeData.

The setServer function still attempts to set activation code data using the old pattern, even though according to the AI summary, this data structure has been refactored. Consider whether this activation code data setting logic is still needed or should be updated to use the new store structure.

---

🏁 Script executed:

#!/bin/bash
# Verify if activationCodeData is still being set elsewhere in the codebase
rg "activationCodeData" --type ts --type vue

Length of output: 72

---

Let’s rerun the search without restricting file types to ensure we catch any occurrences:

---

🏁 Script executed:

#!/bin/bash
# Search for all references to activationCodeData across the repo
rg "activationCodeData" -n .

Length of output: 1752

---

Let’s check where useActivationCodeStore comes from and inspect the surrounding code in web/store/server.ts:

---

🏁 Script executed:

#!/bin/bash
# Locate any definitions or references to useActivationCodeStore
rg "useActivationCodeStore" -n .

# Show imports and top of server.ts to see where activationCodeStore is coming from
sed -n '1,50p' web/store/server.ts

# Show context around lines 1110–1130 in server.ts
sed -n '1100,1130p' web/store/server.ts

Length of output: 3697

---

Ignore outdated activation code refactor suggestion

The call to

useActivationCodeStore().setData(data.activationCodeData)

in web/store/server.ts is valid:

• ActivationCodeData remains defined in web/types/server.ts
• useActivationCodeStore (from activationCodeModal.ts) still exposes setData and delegates to the underlying activationCodeData store
• tests in web/__test__/store/activationCode.test.ts cover this behavior

No changes are needed here.

Likely an incorrect or invalid review comment.

web/components/Activation/store/activationCodeData.ts (1)

9-19: The store implements clean reactive access to activation code data

The store correctly uses Apollo's useQuery to fetch data and exposes computed properties for activation code and fresh installation status. This is a good approach for making this data reactively available to components.

web/components/Activation/ActivationModal.vue (4)

3-3: Good refactoring to use GraphQL instead of store-based data

The imports have been updated to use Apollo's useQuery for data fetching and the new modal store for visibility management, which is a cleaner separation of concerns.

Also applies to: 11-14

---

22-22: Correctly migrated to the new modal store

The component now uses the dedicated activation code modal store, which follows better separation of concerns.

---

25-32: Good implementation of reactive partner data

The component now fetches partner info via GraphQL and handles loading/error states gracefully with fallback values, which is a more robust approach than the previous implementation.

---

70-70: Template correctly uses computed partner data

The template updates properly use the computed partner data properties for conditional rendering and prop passing.

Also applies to: 78-79

web/components/Activation/WelcomeModal.ce.vue (3)

21-31: Good error handling for the GraphQL query

The component properly handles the query execution and includes error logging, which is important for debugging.

---

33-34: Well-structured computed properties

The computed properties correctly extract and provide fallback values for partner data.

---

98-102: Good UX consideration with disabled button

Disabling the button while partner info is loading prevents user interaction with incomplete data.

web/components/Activation/store/activationCodeModal.ts (4)

1-11: Review module-level Pinia initialization

As noted in the activationCodeData.ts review, there are conflicting approaches to Pinia initialization in web component contexts. Verify this is the intended approach for your architecture.

Since this is the same pattern used in activationCodeData.ts, the same verification applies.

---

13-33: Good implementation of modal visibility logic

The store correctly implements the modal visibility logic based on multiple conditions with clear comments explaining the requirements. Using session storage for persistence is appropriate for this use case.

---

65-71: Good lifecycle management for event listeners

The event listeners are properly added on mount and removed on unmount, following best practices for resource management.

---

73-77: Clean API with minimal exports

The store exports only what's needed - the visibility state and a method to update it. This follows good encapsulation principles.

api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (4)

18-45: Well-structured resolver with clear separation of concerns

The CustomizationResolver class has a clean design, delegating complex operations to the CustomizationService. The empty object return in the customization() query with separate field resolvers is a good approach for GraphQL performance, allowing each field to be resolved only when requested.

---

47-55: Good use of @public() decorator for unauthenticated access

The publicPartnerInfo query properly implements a public endpoint with conditional access based on password presence. This allows for exposing minimal branding information without requiring authentication when appropriate.

---

64-72: Appropriate permission control for sensitive data

The activationCode field resolver correctly uses @UsePermissions to restrict access to activation code data based on user permissions. The resource type and action verb are clearly defined.

---

74-84: Well-designed public access for UI assets

Making the caseIcon and partnerLogo resolvers public allows the UI to display branding elements without requiring authentication, which is appropriate for these visual elements.

api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (3)

303-321: Good validation test for hex color transformation

This test effectively verifies that invalid hex colors are transformed to empty strings rather than causing validation failures. This helps ensure robustness in handling potentially malformed input data.

---

323-339: Comprehensive test for hex color normalization

The test for prepending '#' to valid hex colors ensures the transformer correctly normalizes different input formats. This is important for maintaining consistent color representation in the system.

---

358-589: Well-organized test suite with thorough edge case coverage

The customization methods tests cover a wide range of scenarios including:

• Asset presence/absence
• Error handling during file operations
• Various combinations of customization data
• Edge cases in hex color handling

This comprehensive coverage helps ensure the service behaves correctly across different inputs and system states.

api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (5)

7-14: Good input sanitization implementation

The helper function to sanitize strings removes potentially dangerous characters like backslashes and quotes, which helps prevent injection attacks and ensures data integrity.

---

16-30: Robust hex color validation and normalization

The sanitizeAndValidateHexColor function handles multiple formats (with or without '#') and provides graceful fallback to empty string for invalid inputs. This ensures consistent data representation and prevents validation errors.

---

32-40: PublicPartnerInfo has proper access control design

The PublicPartnerInfo class exposes only minimal information (partner name and logo flag) which is appropriate for public access. The @IsBoolean() validation ensures type safety.

---

42-103: Comprehensive validation for ActivationCode fields

The ActivationCode class properly:

1. Validates and sanitizes all fields
2. Uses @IsIn constraints for enum-like fields
3. Provides sensible default for showBannerGradient
4. Applies the custom hex color transformation to color fields

This ensures that only valid, sanitized data enters the system.

---

105-132: Well-designed Customization container class

The Customization class effectively aggregates related data (activation code, partner info, file paths) with clear field descriptions. The @Transform decorators ensure input sanitization for all string fields.

web/composables/gql/gql.ts (4)

16-18: Added PartnerInfo query to Documents type

This new entry correctly adds the PartnerInfo query to the Documents type, allowing type-safe access to partner information.

---

44-46: Added PartnerInfo to documents object

The query document is properly added to the documents object for runtime usage.

---

87-90: New graphql function overload for PartnerInfo query

The function overload provides type-safe access to the PartnerInfo query, ensuring proper type checking at compile time.

---

17-18: Complete and correct integration of ActivationCode query

The ActivationCode query is properly integrated into:

1. The Documents type
2. The documents object
3. The graphql function overloads

This provides complete type safety for accessing activation code data from the GraphQL API.

Also applies to: 45-46, 91-94

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (5)

28-29: Remove the no-op constructor

The class does not declare any dependencies and the body is empty, so the constructor can be safely removed to satisfy noUselessConstructor linting and keep the class lean.
[ suggest_nitpick ]

-    constructor() {}
+
+    // No constructor needed – Nest will create an instance automatically

🧰 Tools

🪛 Biome (1.9.4)

[error] 28-28: This constructor is unnecessary.

Unsafe fix: Remove the unnecessary constructor.

(lint/complexity/noUselessConstructor)

---

49-60: Guard against missing path values to avoid early-crash scenarios

paths.activationBase (and other path look-ups) may return undefined if the store is mis-configured. Attempting fs.access(undefined) later will throw an opaque ENOENT. Fail fast with a descriptive error (or a sane default) to aid troubleshooting.
[ flag_critical_issue ]

-        this.activationDir = paths.activationBase;
+        this.activationDir = paths.activationBase;
+        if (!this.activationDir) {
+            throw new Error(
+                "Store did not provide 'activationBase'. CustomizationService cannot continue."
+            );
+        }

---

237-246: Drop the redundant dynamic import of getters

getters is already imported at module scope (line 11). Re-importing it on every call adds overhead and shadows the earlier binding. Use the existing reference instead.
[ suggest_optional_refactor ]

-        const { getters } = await import('@app/store/index.js');
+        // `getters` is already in scope – reuse it to avoid an extra dynamic import.

---

256-261: Preserve explicit “falsey” values for showBannerGradient

The current truthy check will ignore valid values such as "0" or "false". Test for undefined/null instead so that the caller can explicitly disable the gradient.
[ suggest_essential_refactor ]

-        if (showBannerGradient) settingsToUpdate['showBannerGradient'] = showBannerGradient;
+        if (showBannerGradient !== undefined && showBannerGradient !== null) {
+            settingsToUpdate['showBannerGradient'] = showBannerGradient;
+        }

---

343-349: Reuse the existing getters import in applyServerIdentity

As with applyDisplaySettings, the extra dynamic import is unnecessary. It can also lead to subtle bugs if the two imports diverge (e.g., during hot-reload in tests).
[ suggest_optional_refactor ]

-        const { getters } = await import('@app/store/index.js');
+        // `getters` already imported at module scope

web/composables/gql/graphql.ts (1)

421-425: Consider enforcing non-nullability for container port numbers

privatePort / publicPort now use the custom Port scalar but remain nullable. If a port is always present when the container exposes it, consider marking the fields as non-nullable to improve type-safety throughout the UI.
[ suggest_nitpick ]

Reviewing files that changed from the base of the PR and between 3f71df9 and d50839d.

• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)
• web/__test__/store/activationCode.test.ts (0 hunks)
• web/components/Activation/ActivationPartnerLogo.vue (1 hunks)
• web/components/Activation/ActivationPartnerLogoImg.vue (1 hunks)
• web/components/Activation/WelcomeModal.ce.vue (4 hunks)
• web/components/Activation/graphql/activationCode.query.ts (1 hunks)
• web/components/Activation/store/activationCodeData.ts (1 hunks)
• web/components/Activation/store/activationCodeModal.ts (1 hunks)
• web/composables/gql/gql.ts (3 hunks)
• web/composables/gql/graphql.ts (17 hunks)

• web/test/store/activationCode.test.ts

• web/components/Activation/ActivationPartnerLogo.vue

• web/components/Activation/graphql/activationCode.query.ts
• web/components/Activation/store/activationCodeData.ts
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts
• web/components/Activation/store/activationCodeModal.ts
• web/components/Activation/ActivationPartnerLogoImg.vue
• api/generated-schema.graphql
• web/composables/gql/gql.ts
• web/composables/gql/graphql.ts

• GitHub Check: Cloudflare Pages

web/components/Activation/WelcomeModal.ce.vue (2)

6-8: Good refactoring to use central activation store

The imports reflect the architectural shift to use a centralized GraphQL-based activation store, which aligns with the PR objective of moving activation logic into the API.

---

76-76: Improved UX with loading state

Using the loading state to disable the button during API operations is a good practice that prevents multiple submissions and provides visual feedback to users.

Reviewing files that changed from the base of the PR and between d50839d and ceda719.

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

• .cursor/rules/default.mdc (1 hunks)
• api/dev/Unraid.net/myservers.cfg (1 hunks)
• api/dev/states/var.ini (1 hunks)
• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)
• package.json (1 hunks)
• web/__test__/store/server.test.ts (0 hunks)
• web/components/Activation/ActivationModal.vue (3 hunks)
• web/components/Activation/store/activationCodeData.ts (1 hunks)
• web/components/Activation/store/activationCodeModal.ts (1 hunks)
• web/components/DummyServerSwitcher.vue (1 hunks)
• web/helpers/create-apollo-client.ts (2 hunks)
• web/layouts/default.vue (2 hunks)
• web/nuxt.config.ts (1 hunks)
• web/pages/welcome.vue (1 hunks)
• web/store/server.ts (3 hunks)

• web/test/store/server.test.ts

• package.json
• web/nuxt.config.ts
• api/dev/Unraid.net/myservers.cfg
• api/dev/states/var.ini
• web/components/DummyServerSwitcher.vue
• web/layouts/default.vue

• .cursor/rules/default.mdc
• web/components/Activation/store/activationCodeData.ts
• web/components/Activation/ActivationModal.vue
• web/components/Activation/store/activationCodeModal.ts
• api/generated-schema.graphql
• web/store/server.ts

• GitHub Check: Build API
• GitHub Check: Cloudflare Pages

web/pages/welcome.vue (3)

3-8: Imports look good and align with PR objectives.

These imports properly bring in the necessary activation-related stores and components that support moving activation logic to the API.

---

12-16: Good store initialization with proper reactivity handling.

Using storeToRefs is the correct approach to maintain reactivity when destructuring properties from Pinia stores.

---

28-28: Good addition of the ModalsCe component.

This integrates well with the overall activation system refactor mentioned in the PR summary.

web/helpers/create-apollo-client.ts (2)

1-1: Import cleanup improves code hygiene.

The removal of ApolloLink and Observable imports aligns with the elimination of the disableClientLink functionality, keeping imports to only what's needed.

---

82-82:

Details

✅ Verification successful

Apollo link chain simplified.

The Apollo client link chain has been streamlined by removing the disableClientLink from the composition. This change aligns with moving activation code logic to the API as stated in the PR objectives.

---

🏁 Script executed:

#!/bin/bash
# Verify that no code in the codebase still relies on the removed disableClientLink
rg "disableClientLink" --type ts

Length of output: 32

---

🏁 Script executed:

#!/bin/bash
# Re-verify that no code references disableClientLink across all file types
rg -n "disableClientLink"

Length of output: 25

---

Link chain simplification verified
No remaining references to disableClientLink were found across the codebase. The Apollo link chain removal is safe and aligns with the PR objectives.

api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (4)

95-105: LGTM: Well-structured mock activation data

The mock activation data is well-structured and matches the expected ActivationCode interface. This makes the tests more realistic and improves their value.

---

337-453: LGTM: Comprehensive tests for getActivationData

The test suite for the getActivationData method is well-designed and covers all important scenarios:

• Missing activation directory
• No activation code file
• Directory access errors
• File read errors
• Invalid JSON
• Hex color handling (both with and without # prefix)
• Successfully validating and returning the DTO

This comprehensive approach significantly increases confidence in the code's reliability.

---

726-941: LGTM: Thorough error handling tests

The separate test suite for applyActivationCustomizations specifically focuses on error handling scenarios, which is excellent practice. The tests verify that:

1. The service gracefully handles a missing activation directory
2. Errors in one customization step don't prevent other steps from running
3. Each method properly logs its specific errors

This approach ensures the service remains resilient even when parts of the customization process fail.

---

943-1096: LGTM: Excellent unit tests for updateCfgFile utility

The tests for the updateCfgFile utility function are particularly well-designed, covering:

1. Creating a new file with/without sections
2. Merging updates with existing content
3. Adding new sections to existing files
4. Handling read/write errors

This thorough testing of a utility function demonstrates good attention to detail and will prevent regressions.

Reviewing files that changed from the base of the PR and between ceda719 and 7b73737.

• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• web/_data/serverState.ts (2 hunks)
• web/store/server.ts (4 hunks)
• web/types/server.ts (0 hunks)

• web/types/server.ts

• web/store/server.ts

• GitHub Check: Build Web App
• GitHub Check: Build API
• GitHub Check: Cloudflare Pages

web/_data/serverState.ts (3)

9-10: Improved import organization.

Moving the Pinia import to its own line at the top of the file follows best practices for import organization.

---

200-206: Removal of activation code data from server state.

The removal of activation code data from the OEM activation object aligns with the PR objective of moving activation code logic into the API. This is a good architectural change that promotes separation of concerns by transferring this data management to dedicated stores with GraphQL queries.

---

208-212: Improved Pinia store formatting.

The formatting changes to the useDummyServerStore make the code more consistent and readable while maintaining the same functionality.

api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (4)

9-14: Well-implemented string sanitization.

The sanitizeString function effectively removes potentially dangerous characters (backslashes and quotes) from string values, which helps prevent injection attacks.

---

17-30: Good implementation of hex color validation.

The sanitizeAndValidateHexColor function properly:

1. Sanitizes input with existing sanitizeString
2. Adds a leading # if missing
3. Validates the hex color format
4. Returns empty string for invalid inputs

This robustly handles different formats of hex color input.

---

96-122: Comprehensive color handling for header and background.

The color fields are properly:

1. Nullable in GraphQL
2. Optional in validation
3. Validated as strings
4. Transformed using the custom sanitizeAndValidateHexColor function

The implementation ensures proper hex color format while gracefully handling invalid inputs.

---

123-128: Good theme constraint using IsIn validator.

The theme field is properly constrained to a set of allowed values using the @IsIn() validator, preventing invalid theme values.

api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (3)

404-422: Comprehensive test for hex color prepending.

Good test case that verifies the system correctly prepends # to hex colors that are provided without it, ensuring display settings are consistently applied regardless of input format.

---

599-622: Good test for handling empty color strings.

This test ensures that empty strings resulting from invalid hex colors are properly filtered out when applying display settings, preventing errors from propagating through the system.

---

943-1096: Excellent standalone tests for updateCfgFile utility.

These tests comprehensively verify the behavior of the private utility method, covering:

1. Creating new files with and without sections
2. Merging updates with existing content
3. Adding new sections to existing files
4. Error handling for both read and write operations

This approach of testing private methods in isolation is valuable for complex utilities.

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (3)

126-157: Well-implemented activation data retrieval with caching.

The getActivationData() method effectively:

1. Returns cached data if available
2. Locates JSON files with the correct extension
3. Parses and validates the data using class-transformer and class-validator
4. Gracefully handles errors with appropriate logging
5. Only caches valid data

This provides a robust foundation for the activation features.

---

236-316: Thorough display settings application with edge case handling.

The applyDisplaySettings() method:

1. Checks for activation data availability
2. Maps properties with custom transformations (removing # from colors)
3. Verifies banner file existence before setting banner=image
4. Skips empty fields
5. Handles errors gracefully
6. Provides detailed debug logging

The structured approach makes the code maintainable and robust.

---

417-472: Well-implemented INI file update utility.

The updateCfgFile helper method:

1. Handles both section-based and root-level updates
2. Creates files if they don't exist
3. Preserves existing settings not being updated
4. Properly stringifies INI format with trailing newline
5. Includes comprehensive error handling and logging

This reusable utility provides a solid foundation for all configuration file updates.

Reviewing files that changed from the base of the PR and between 7b73737 and 3c401be.

• api/src/__test__/store/modules/__snapshots__/paths.test.ts.snap is excluded by !**/*.snap

• api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1 hunks)

• GitHub Check: Test API
• GitHub Check: Build Web App
• GitHub Check: Build API
• GitHub Check: Cloudflare Pages

api/src/unraid-api/graph/resolvers/customization/customization.service.spec.ts (1)

992-1006: Test for updateCfgFile with sections is thorough and well-designed

The test effectively verifies the method correctly merges updates with existing content while preserving other sections and unmodified keys.

Reviewing files that changed from the base of the PR and between f58272e and 65efd6d.

• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• web/components/Activation/WelcomeModal.ce.vue (3 hunks)

• web/components/Activation/WelcomeModal.ce.vue

• GitHub Check: Cloudflare Pages

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (3)

1-15: The overall architecture looks good.

The service is well-structured with clear responsibilities for managing system customizations based on activation data. The code is organized logically with appropriate use of NestJS patterns and dependency management.

---

121-152: Great implementation of the activation data retrieval.

The caching strategy and error handling in this method are well implemented. The use of class-transformer and class-validator ensures that the activation data is properly validated before use.

---

251-285: Good use of typed mappings for configuration transformation.

The type-safe approach to mapping activation data properties to configuration keys is well-designed. The transformation functions and optional value handling make the code robust and maintainable.

Reviewing files that changed from the base of the PR and between adc4b3d and 0655092.

• api/dev/webGui/images/UN-logotype-gradient.svg is excluded by !**/*.svg

• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/DefaultPageLayout.php.modified.snapshot.php (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/case-model-copier.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/default-page-layout.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/partner-logo-copier.modification.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/patches/default-page-layout.patch (4 hunks)
• api/src/unraid-api/unraid-file-modifier/unraid-file-modifier.service.ts (1 hunks)
• plugin/plugins/dynamix.unraid.net.plg (0 hunks)
• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/activation-code-extractor.php (0 hunks)
• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/partner-logo.php (0 hunks)
• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/state.php (0 hunks)
• web/components/Activation/ActivationModal.vue (2 hunks)
• web/components/HeaderOsVersion.ce.vue (2 hunks)
• web/nuxt.config.ts (3 hunks)
• web/pages/index.vue (2 hunks)

• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/partner-logo.php
• plugin/plugins/dynamix.unraid.net.plg
• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/activation-code-extractor.php
• plugin/source/dynamix.unraid.net/usr/local/emhttp/plugins/dynamix.my.servers/include/state.php

• api/src/unraid-api/unraid-file-modifier/modifications/case-model-copier.modification.ts

• api/src/unraid-api/unraid-file-modifier/unraid-file-modifier.service.ts
• web/components/Activation/ActivationModal.vue
• web/nuxt.config.ts
• api/src/unraid-api/unraid-file-modifier/modifications/test/snapshots/DefaultPageLayout.php.modified.snapshot.php
• api/src/unraid-api/unraid-file-modifier/modifications/partner-logo-copier.modification.ts
• api/src/unraid-api/unraid-file-modifier/modifications/patches/default-page-layout.patch
• api/generated-schema.graphql

• GitHub Check: Build Web App
• GitHub Check: Cloudflare Pages

web/pages/index.vue (2)

3-3: Logo component import removed to support the dynamic partner branding.

The removal of BrandLogo from imports aligns with the broader changes moving to dynamic partner branding handled via the new activation code system.

---

114-116: Logo element removed from header.

The static logo and link have been removed, which corresponds with the import changes. The container class was also updated to remove horizontal padding (px-4). This change streamlines the UI to support dynamic partner branding implemented elsewhere.

web/components/HeaderOsVersion.ce.vue (5)

12-12: Added import for the new activation code data store.

This import adds support for dynamic partner information through the activation code system.

---

20-20: Added access to partner information from the new store.

The partnerInfo reactive reference is destructured from the new activation code data store.

---

25-30: Added computed property for partner URL.

Good implementation of the logoUrl computed property with proper fallback to the default Unraid URL when partner URL is not available.

---

73-76: Added dynamic logo link in the header.

The logo now links to either the partner URL or the default Unraid URL based on the activation code data. The image source still points to the Unraid logo image with responsive width classes.

---

77-115: Restructured OS version and update status badges.

The existing OS version badge and update status controls are now contained within a flex container below the logo. The functionality remains unchanged, but the visual organization is improved.

api/src/unraid-api/unraid-file-modifier/modifications/default-page-layout.modification.ts (1)

49-49: Added logo injection step to transformation pipeline.

The injectPartnerLogo method has been incorporated into the transformation pipeline in applyToSource.

Reviewing files that changed from the base of the PR and between 6b7639e and 450a03e.

• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• web/components/Activation/WelcomeModal.ce.vue (3 hunks)

• web/components/Activation/WelcomeModal.ce.vue

• GitHub Check: Build and Deploy Plugin / Build and Deploy Plugin
• GitHub Check: Cloudflare Pages

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (2)

119-123: LGTM! Good use of caching for activation data.

The caching implementation for activation data is well-executed and will help performance.

---

419-473: Well-implemented INI file updating function.

The updateCfgFile method is well-structured and includes thorough error handling for file operations. The comments explaining the INI library's behavior are particularly helpful.

Reviewing files that changed from the base of the PR and between 450a03e and 303541e.

• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• web/components/Activation/ActivationPartnerLogoImg.vue (1 hunks)
• web/components/Activation/WelcomeModal.ce.vue (3 hunks)
• web/components/Activation/graphql/activationCode.query.ts (1 hunks)
• web/composables/gql/gql.ts (3 hunks)
• web/composables/gql/graphql.ts (17 hunks)
• web/store/theme.ts (1 hunks)

• web/components/Activation/ActivationPartnerLogoImg.vue
• web/components/Activation/WelcomeModal.ce.vue
• web/components/Activation/graphql/activationCode.query.ts
• api/generated-schema.graphql
• web/composables/gql/gql.ts

• GitHub Check: Build Web App
• GitHub Check: Cloudflare Pages

web/store/theme.ts (1)

127-127: Good addition - exposes the setCssVars function for external use.

This change makes the setCssVars function accessible outside the store, which supports the new activation code-driven theming features. The function was previously only used internally (triggered by the watcher on line 115), but now external components can trigger CSS variable updates directly when needed.

api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (4)

25-36: LGTM! Well-structured method for partner info retrieval.

The method efficiently combines partner logo existence check and activation data into a single PublicPartnerInfo object.

🧰 Tools

🪛 GitHub Check: Test API

[failure] 34-34:
Replace await·this.customizationService.getPartnerLogoRaw( with (await·this.customizationService.getPartnerLogoRaw()

🪛 GitHub Check: Build API

[failure] 34-34:
Replace await·this.customizationService.getPartnerLogoRaw( with (await·this.customizationService.getPartnerLogoRaw()

---

51-54: Good implementation of authenticated query.

The resolver properly returns an empty object and relies on field resolvers for population, which follows GraphQL best practices.

---

56-64: Well-designed public endpoint with security check.

Good use of the @public() decorator combined with password check to conditionally expose partner info only when no password is set.

---

66-79: Appropriate authorization handling for different fields.

The implementation correctly applies permissions to the sensitive activationCode field while leaving partnerInfo accessible, matching the security requirements.

api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (5)

7-14: Good security practice with string sanitization.

The sanitizeString function properly removes potential injection vectors by filtering out quotes and backslashes.

---

17-30: Well-implemented hex color validation and normalization.

The function handles different color formats well, ensuring consistent output with proper validation.

---

32-66: LGTM! Robust model design with proper validation.

The PublicPartnerInfo class uses appropriate decorators for validation and transformation, ensuring data safety.

---

124-131: Nice handling of boolean transformation.

Good approach for handling boolean values that might come in different formats (boolean or string).

---

133-137: Good use of enum validation.

The @isin decorator ensures the theme value is restricted to valid options.

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (2)

58-91: Well-structured initialization logic.

Good pattern for handling potential directory existence issues and appropriately applying customizations only on first boot.

---

377-430: LGTM! Thorough implementation of server identity updates.

The method handles all necessary updates including configuration files, emhttp updates, and system services.

web/composables/gql/graphql.ts (6)

25-26: Good addition of Port scalar type.

Adding a specific scalar for TCP ports improves type safety and documentation.

---

46-59: Well-structured ActivationCode type.

The type includes all necessary fields for customization with appropriate nullability.

---

279-292: Good practice using enums for authorization verbs and possession.

Using enums provides better type safety and documentation than string literals.

---

1043-1061: Improved organization with ParityCheckMutations.

Grouping related mutations into a dedicated type improves API organization and maintainability.

---

1089-1099: Well-documented PublicPartnerInfo type.

Good use of field descriptions to document the purpose and format of each field.

---

1720-1728: LGTM! Well-structured GraphQL queries.

The queries properly fetch the data needed for the activation code features.

Reviewing files that changed from the base of the PR and between 303541e and 90b59a0.

• api/generated-schema.graphql (4 hunks)
• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts (1 hunks)
• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/auth-request.php.modified.snapshot.php (1 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/auth-request.modification.ts (2 hunks)
• api/src/unraid-api/unraid-file-modifier/modifications/patches/auth-request.patch (1 hunks)
• api/src/utils.ts (2 hunks)
• web/components/Activation/ActivationPartnerLogoImg.vue (1 hunks)
• web/components/Activation/graphql/activationCode.query.ts (1 hunks)
• web/composables/gql/gql.ts (3 hunks)
• web/composables/gql/graphql.ts (17 hunks)

• api/src/unraid-api/unraid-file-modifier/modifications/patches/auth-request.patch

• web/components/Activation/ActivationPartnerLogoImg.vue
• api/src/unraid-api/graph/resolvers/customization/customization.resolver.ts
• web/components/Activation/graphql/activationCode.query.ts
• api/generated-schema.graphql
• web/composables/gql/gql.ts
• api/src/unraid-api/graph/resolvers/customization/activation-code.model.ts

• GitHub Check: Build Web App
• GitHub Check: Cloudflare Pages

api/src/unraid-api/unraid-file-modifier/modifications/__test__/snapshots/auth-request.php.modified.snapshot.php (1)

18-18: LGTM! Updated whitelist entry matches expected changes.

The whitelist entry has been correctly updated from partner-logo.svg to UN-logotype-gradient.svg, aligning with the changes to use dynamic path resolution in the auth-request modification.

api/src/unraid-api/unraid-file-modifier/modifications/auth-request.modification.ts (1)

9-9: Good approach using dynamic path resolution.

The changes convert a hardcoded path to a dynamic, store-driven approach using the new utility function. This enhances maintainability and flexibility for managing partner logo paths.

Also applies to: 43-47

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1)

1-470: Well-structured service with good separation of concerns.

The CustomizationService is well-organized with clear separation between initialization, data retrieval, and applying different types of customizations. The error handling is comprehensive and the logging is thorough.

🧰 Tools

🪛 GitHub Check: Build API

[failure] 152-152:
Delete ⏎

---

[failure] 152-152:
More than 1 blank line not allowed

🪛 GitHub Check: Test API

[failure] 152-152:
Delete ⏎

---

[failure] 152-152:
More than 1 blank line not allowed

web/composables/gql/graphql.ts (11)

25-26: Well-defined Port scalar type.

This new scalar type for TCP ports correctly defines the input and output types as numbers, providing better type safety for port-related operations.

---

39-44: Good replacement for direct URL usage.

The new AccessUrlInput type provides a more structured approach than directly using the URL scalar, with appropriate nullable fields for flexibility.

---

46-59: Clear activation code type structure.

The new ActivationCode type has well-named fields that clearly represent the customization options available through activation codes.

---

279-292: Well-documented authentication enums.

The new authentication-related enums have good documentation and clear, descriptive values.

---

424-425: Improved type safety for ContainerPort.

Making these fields nullable and utilizing the new Port scalar type improves the type safety of the API.

---

572-579: Added cache control capability.

The new skipCache parameter gives clients better control over Docker data retrieval behavior.

---

448-452: Coherent customization structure.

The new Customization and PublicPartnerInfo types, along with their associated query fields, create a logical structure for accessing activation code data and partner information.

Also applies to: 1089-1097, 1107-1107, 1126-1126

---

1218-1218: Resource enum extension.

Adding ACTIVATION_CODE to the Resource enum aligns with the new activation code feature.

---

1718-1726: Well-defined TypeScript query types.

The new TypeScript type definitions for PartnerInfo and ActivationCode queries match the schema changes and are properly structured.

---

1114-1115: New utility endpoints.

The addition of getDemo and health endpoints provides useful functionality for testing and monitoring.

---

823-823:

Details

✅ Verification successful

Verify potential breaking changes in mutation restructuring.

The VM and parity check mutations have been restructured from direct fields on the Mutation type to grouped types. While this improves organization, it's a potential breaking change for existing clients.

Run the following script to check for client code that might be affected:

Also applies to: 835-835, 1043-1061, 1624-1675

---

🏁 Script executed:

#!/bin/bash
# Look for any code that directly references VM or parity check mutations at the top level

# Check for references to VM mutations
echo "Checking for VM mutation references that might be affected:"
rg -i "mutation.*\b(start|stop|pause|resume|reset|reboot|forceStop)(Vm|VirtualMachine)" --type ts

# Check for references to parity check mutations
echo -e "\nChecking for parity check mutation references that might be affected:"
rg -i "mutation.*\b(start|pause|resume|cancel)(ParityCheck)" --type ts

Length of output: 456

---

No internal usage of legacy root-level VM or parityCheck mutations detected. The grep scan for direct references (e.g. startVm, stopVm, cancelParityCheck) returned no matches, so this restructuring won’t break internal code.

• Affected file: web/composables/gql/graphql.ts (lines 823, 835, 1043–1061, 1624–1675) now exposes mutations under vm and parityCheck groups.
• No TypeScript or GraphQL documents in this repo reference the old top-level mutation fields.
• External clients should be notified to update their GraphQL calls to the new grouped fields and documentation/CHANGELOG updated accordingly.

Reviewing files that changed from the base of the PR and between 90b59a0 and 1765b89.

• api/src/unraid-api/graph/resolvers/customization/customization.service.ts (1 hunks)
• api/src/utils.ts (1 hunks)

• api/src/utils.ts

• GitHub Check: Test API
• GitHub Check: Build API
• GitHub Check: Cloudflare Pages

api/src/unraid-api/graph/resolvers/customization/customization.service.ts (11)

1-27: Well-organized imports and class setup.

The imports are logically grouped and the class is well-structured with proper type definitions for member variables.

---

28-37: LGTM! First boot setup flag implementation is robust.

The method correctly creates the activation directory if needed, checks for the existence of the flag file, and appropriately creates it if missing.

---

54-92: Robust initialization and activation directory handling.

The initialization process correctly sets up paths, checks for directory existence, and handles the first boot setup flag. The error handling is comprehensive with appropriate logging.

---

94-112: Good path resolution with proper error handling.

The method correctly finds the activation JSON file with appropriate error handling and logging.

---

146-150: Comprehensive error handling in activation data processing.

The error handling for the activation data processing is well-implemented with appropriate logging and return values.

---

168-201: Robust customization application flow.

The method appropriately checks for activation data, verifies directory existence, and applies customizations in a logical sequence with comprehensive error handling.

---

203-227: Well-implemented partner banner setup.

The banner setup correctly handles file existence checks, copying, and error handling.

---

307-309: Good error handling for display settings.

The error handling for display settings is appropriate with informative error logging.

---

311-357: Well-implemented case model configuration.

The method effectively manages the case model configuration with appropriate checks, error handling, and logging.

---

359-412: Comprehensive server identity implementation.

The server identity is properly applied with appropriate error handling, emcmd execution, and nginx/DNS updates.

---

414-468: Well-designed config file update utility.

The updateCfgFile utility method is well-designed to handle both section-specific and root-level updates to INI files with proper error handling.