feat(native-app): update vehicle list query in app #16824
Conversation
thoreyjona
changed the title
thoreyjona
changed the title
thoreyjona
force-pushed
the
feat/update-vehicle-list-app
branch
from
982d1f5 to
983478b
Compare
WalkthroughThe pull request introduces significant updates to the vehicle-related GraphQL queries and fragments in the application. The Changes
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)apps/native/app/src/graphql/fragments/vehicle.fragment.graphql (1)Pattern
🔇 Additional comments (3)apps/native/app/src/graphql/fragments/vehicle.fragment.graphql (3)
The field
The fragment type has changed from ✅ Verification successfulFragment type change is safe to proceed The verification shows that the fragment type change from
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Find all GraphQL operations using this fragment to ensure they're compatible with the new type
# Search for GraphQL operations using VehicleFragment
rg -t graphql "\.\.\.VehicleFragment" apps/
Length of output: 77 Script: #!/bin/bash
# Search for files containing VehicleFragment without file type restriction
rg "\.\.\.VehicleFragment" apps/
Length of output: 112 Script: #!/bin/bash
# Find all GraphQL files in the apps directory
fd "\.(graphql|gql)$" apps/
Length of output: 5821 Script: #!/bin/bash
# Search for any references to VehiclesVehicle (old type) or VehicleListed (new type)
rg "Vehicle(sVehicle|Listed)" apps/
Length of output: 300 Script: #!/bin/bash
# Check the vehicles.graphql query to understand how the fragment is being used
cat apps/native/app/src/graphql/queries/vehicles.graphql
# Check the client.ts file to understand the type handling
cat apps/native/app/src/graphql/client.ts
Length of output: 8553
The fragment has been significantly simplified by removing many fields. Please confirm that the removed fields (e.g., ✅ Verification successfulThe removal of fields from VehicleFragment appears safe Based on the codebase analysis:
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Description: Search for any usage of removed fields in the codebase
# Search for references to removed fields in TypeScript/JavaScript files
echo "Searching for references to removed fields..."
rg -t typescript -t javascript "vin|firstRegDate|productYear|registrationType|role|operatorStartDate|operatorEndDate|outOfUse|otherOwners|termination|buyerPersidno|ownerPersidno|vehicleStatus|useGroup|vehGroup|plateStatus" apps/native/
Length of output: 373 Script: #!/bin/bash
# Search for references to removed fields in all text files within native app
echo "Searching for references to removed fields..."
rg "vin|firstRegDate|productYear|registrationType|role|operatorStartDate|operatorEndDate|outOfUse|otherOwners|termination|buyerPersidno|ownerPersidno|vehicleStatus|useGroup|vehGroup|plateStatus" apps/native/
# Also check for any other GraphQL fragments or queries that might be using VehicleFragment
echo -e "\nSearching for VehicleFragment usage..."
rg "VehicleFragment" apps/native/
Length of output: 8514 Script: #!/bin/bash
# Let's check the vehicles.graphql query to see what fields it's actually using
echo "Content of vehicles.graphql query:"
cat apps/native/app/src/graphql/queries/vehicles.graphql
# Let's also check any TypeScript interfaces or types that might be using these fields
echo -e "\nChecking for VehicleListed type definitions:"
rg "VehicleListed" apps/native/
Length of output: 2629 Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (5)
apps/native/app/src/screens/vehicles/components/vehicle-item.tsx (2)
9-12: Consider using a date utility library for more robust date handlingThe custom
differenceInMonthsfunction could be replaced with a more robust solution likedate-fnswhich handles edge cases better.Example implementation using date-fns:
import { differenceInMonths } from 'date-fns'
Line range hint
23-85: Well-structured component with good optimizationThe component follows React Native best practices with:
- Proper use of React.memo for performance optimization
- Styled components for consistent styling
- Clear separation of concerns between display and data handling
However, consider breaking down the component further to improve maintainability:
- Extract the inspection deadline logic into a custom hook
- Move the styled components to a separate file
- Create a separate component for the inspection label
Example hook extraction:
function useInspectionStatus(nextMainInspection: string | null, requiresMileageRegistration: boolean) { const nextInspection = useMemo(() => { return nextMainInspection && !isNaN(Date.parse(nextMainInspection)) ? new Date(nextMainInspection) : null }, [nextMainInspection]) const isInspectionDeadline = useMemo(() => { return nextInspection ? differenceInMonths(new Date(nextInspection), new Date()) < 0 : false }, [nextInspection]) return { nextInspection, isInspectionDeadline, requiresMileageRegistration } }apps/native/app/src/screens/home/vehicles-module.tsx (2)
62-62: Consider extracting the sorting logic into a utility function.The vehicle sorting logic could be moved to a separate utility function to improve maintainability and testability. This would also make the component more focused on its primary responsibility of rendering.
Example:
const sortVehiclesByMileageRegistration = (vehicles: Vehicle[]) => vehicles.sort((a, b) => { if (a.requiresMileageRegistration && !b.requiresMileageRegistration) return -1; if (!a.requiresMileageRegistration && b.requiresMileageRegistration) return 1; return 0; });
Line range hint
1-173: Consider splitting the component for better separation of concerns.The VehiclesModule component currently handles multiple responsibilities:
- Data transformation (sorting vehicles)
- Conditional rendering logic
- Layout and styling
Consider splitting this into smaller, more focused components:
- VehiclesList (handling the list rendering)
- VehiclesSorter (handling the sorting logic)
- VehiclesHeader (handling the header with "See All" button)
This would improve maintainability, testability, and reusability.
apps/native/app/src/screens/vehicles/vehicles.tsx (1)
35-35: Simplify type definition by removing redundantNonNullableThe type definition of
VehicleListItemuses redundantNonNullablewrappers. Simplifying it can improve readability without affecting type safety.Apply this diff to simplify the type:
-type VehicleListItem = NonNullable< - NonNullable<ListVehiclesV2Query['vehiclesListV2']>['vehicleList'] ->[0] +type VehicleListItem = NonNullable< + ListVehiclesV2Query['vehiclesListV2']['vehicleList'] +>[0]
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (6)
apps/native/app/src/graphql/fragments/vehicle.fragment.graphql(1 hunks)apps/native/app/src/graphql/queries/vehicles.graphql(1 hunks)apps/native/app/src/screens/home/home.tsx(2 hunks)apps/native/app/src/screens/home/vehicles-module.tsx(5 hunks)apps/native/app/src/screens/vehicles/components/vehicle-item.tsx(3 hunks)apps/native/app/src/screens/vehicles/vehicles.tsx(7 hunks)
🧰 Additional context used
📓 Path-based instructions (6)
apps/native/app/src/graphql/fragments/vehicle.fragment.graphql (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/native/app/src/graphql/queries/vehicles.graphql (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/native/app/src/screens/home/home.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/native/app/src/screens/home/vehicles-module.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/native/app/src/screens/vehicles/components/vehicle-item.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
apps/native/app/src/screens/vehicles/vehicles.tsx (1)
Pattern apps/**/*: "Confirm that the code adheres to the following:
- NextJS best practices, including file structure, API routes, and static generation methods.
- Efficient state management and server-side rendering techniques.
- Optimal use of TypeScript for component and utility type safety."
🔇 Additional comments (16)
apps/native/app/src/graphql/fragments/vehicle.fragment.graphql (2)
1-9: Verify the impact of removed fields on dependent components
The fragment has undergone significant changes, switching from VehiclesVehicle to VehicleListed type and removing many fields. This could potentially break components that depend on the removed fields.
Let's verify the usage of removed fields in the codebase:
✅ Verification successful
Fragment changes appear safe to proceed
The codebase analysis shows that the removed fields from the VehicleFragment are not actively used in the application code. The only references found are:
nextInspectionwhich has been replaced withnextMainInspection(already handled in vehicle-item.tsx)useGroupandplateStatusonly appear in a separate vehicles query- The old type
VehiclesVehicleis only referenced in the Apollo client for caching purposes
The migration to VehicleListed type appears to be a coordinated change as part of the vehicleListV2 endpoint update, with proper handling of the new fields in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage of removed fields in TypeScript/JavaScript files
rg -t typescript -t javascript "vin|firstRegDate|productYear|registrationType|role|operatorStartDate|operatorEndDate|outOfUse|otherOwners|termination|buyerPersidno|ownerPersidno|vehicleStatus|useGroup|vehGroup|plateStatus|nextInspection" apps/native/app/src/
Length of output: 295
Script:
#!/bin/bash
# Search for usage of removed fields in all files within the app directory
rg "vin|firstRegDate|productYear|registrationType|role|operatorStartDate|operatorEndDate|outOfUse|otherOwners|termination|buyerPersidno|ownerPersidno|vehicleStatus|useGroup|vehGroup|plateStatus|nextInspection" apps/native/app/src/
# Also check for any other GraphQL operations using the old VehiclesVehicle type
rg "VehiclesVehicle" apps/native/app/src/
# Let's also check for any components that import and use this fragment
rg "VehicleFragment" apps/native/app/src/
Length of output: 9718
1-1: Verify schema compatibility
Need to verify that the VehicleListed type and its new fields exist in the schema to prevent runtime errors.
Let's verify the schema compatibility:
✅ Verification successful
Schema compatibility verified
The VehicleListed type exists in the schema and includes all the necessary fields. The type is properly defined in libs/api/domains/vehicles/src/lib/models/usersVehicles.model.ts with the fields make, colorName, and nextMainInspection all properly declared as nullable fields using the @Field decorator.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for VehicleListed type definition in schema files
rg -t graphql "type VehicleListed"
# Search for field definitions
ast-grep --pattern 'type VehicleListed {
$$$
make: $_
colorName: $_
nextMainInspection: $_
$$$
}'
Length of output: 178
Script:
#!/bin/bash
# Search for schema files with common extensions
fd "\.(graphql|gql|schema)$"
# Then search for VehicleListed in all files
rg "VehicleListed"
# Also search specifically in schema directory if it exists
fd -t f . schema/ || true
Length of output: 20712
Script:
#!/bin/bash
# Let's examine the VehicleListed model definition
cat libs/api/domains/vehicles/src/lib/models/usersVehicles.model.ts
Length of output: 5584
apps/native/app/src/graphql/queries/vehicles.graphql (3)
Line range hint 13-143: Verify GetVehicle query compatibility
While this query remains unchanged, we should verify that none of its fields are affected by the backend changes to the vehicle list endpoint.
✅ Verification successful
No compatibility issues found with GetVehicle query
Based on the codebase analysis, the GetVehicle query and its associated types remain stable and consistent. The query is used across multiple parts of the application with the same structure, and there are no conflicting type definitions or breaking changes in the schema that would affect the fields being queried.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any changes to the vehicle detail types in the schema
ast-grep --pattern 'type GetVehicleDetailInput'
ast-grep --pattern 'type VehicleDetail'
Length of output: 91
Script:
#!/bin/bash
# Let's try searching for GraphQL schema files and type definitions
fd -e graphql -e gql . --exec cat {} \; | grep -A 5 "type.*Vehicle"
# Also search for any recent changes to vehicle-related files
fd -e graphql -e gql -e ts -e tsx . | grep -i "vehicle" | xargs cat 2>/dev/null | grep -A 5 "type.*Vehicle\|input.*Vehicle"
# Let's also check for any fragments used in the query
fd -e graphql -e gql . --exec cat {} \; | grep -A 5 "fragment VehicleMileageDetailFragment"
Length of output: 24591
1-2:
Breaking Changes Alert: Coordinate deployment with backend
This introduces breaking changes in the query name, input type, and field name. Ensure this change is coordinated with the backend deployment and the November 26th release timeline.
Let's verify the fragment compatibility and usage:
✅ Verification successful
Breaking changes verified - Fragment compatibility confirmed
The VehicleFragment is correctly used in the ListVehiclesV2 query and all references to the query have been updated to use the V2 version in the codebase. The fragment's type VehicleListed remains compatible with the new query structure. Key findings:
- Fragment is properly referenced in the new query using
...VehicleFragment - All TypeScript files are using the updated
ListVehiclesV2QueryanduseListVehiclesV2Query - No legacy query usage found in the codebase
The only remaining consideration is the deployment timing coordination with the backend for November 26th.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if the VehicleFragment is updated to match the new schema
ast-grep --pattern 'fragment VehicleFragment on $_'
# Check for any remaining usage of the old query
rg 'ListVehicles\(' --type ts
Length of output: 85
Script:
#!/bin/bash
# Let's try a broader search for fragments and query usage
# Search for fragment definitions
rg -l 'fragment.*Vehicle' --type graphql
# Search for any GraphQL fragments used in the vehicles query
rg -A 5 'query ListVehiclesV2' --type graphql
# Search for old and new query usages in TypeScript files
rg -l 'useListVehicles|ListVehicles' --type ts
Length of output: 413
Script:
#!/bin/bash
# Let's check the content of files using the query to understand the impact
rg -B2 -A2 'ListVehicles' apps/native/app/src/screens/vehicles/vehicles.tsx apps/native/app/src/screens/home/home.tsx apps/native/app/src/screens/home/vehicles-module.tsx
# Let's also check the fragments by removing the file type restriction
rg -l 'fragment.*Vehicle'
Length of output: 3993
Script:
#!/bin/bash
# Let's check the vehicle fragment content
cat apps/native/app/src/graphql/fragments/vehicle.fragment.graphql
# Check if the fragment is used in the vehicles query
cat apps/native/app/src/graphql/queries/vehicles.graphql
Length of output: 2540
Line range hint 1-12: Verify pagination implementation
The query structure maintains the same pagination fields. However, we should verify that the pagination implementation in the UI components has been updated to work with the new query.
✅ Verification successful
Let me search for the vehicle-related pagination implementation to verify if it needs updates.
Let me try again with the correct file type flag.
Let me try one more time with just searching through TypeScript files.
Based on the search results, I can now provide a final response:
Pagination implementation is correctly handled in the UI components
The pagination implementation in the UI components is already compatible with the new query structure. The code shows that:
- In
apps/native/app/src/screens/vehicles/vehicles.tsx, the pagination is correctly implemented usingpageNumberandtotalPagesfrom thevehiclesListV2response - The pagination data is properly handled for infinite scrolling in the native app
- The query response structure matches the expected format with
pagingobject containingpageNumber,totalPages, and other pagination fields
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Look for pagination-related code that might need updates
rg -A 5 'pageNumber|pageSize|totalPages|totalRecords' --type ts
Length of output: 101545
Script:
#!/bin/bash
# Look for vehicle-related components that use pagination
rg -A 5 "vehiclesListV2|vehiclesList" --type tsx
Length of output: 78
Script:
#!/bin/bash
# Look for vehicle-related components that use pagination
rg -A 5 "vehiclesListV2|vehiclesList" --type ts --type tsx
Length of output: 88
Script:
#!/bin/bash
# Look for vehicle-related components that use pagination
rg -A 5 "vehiclesListV2|vehiclesList" --type ts
# Also search for any files that might be importing this query
rg -A 2 "import.*vehicles\.graphql" --type ts
Length of output: 14098
apps/native/app/src/screens/vehicles/components/vehicle-item.tsx (2)
6-6: LGTM! Type definitions properly updated for the new V2 query
The type changes correctly reflect the new data structure from vehicleListV2 endpoint while maintaining type safety through proper use of NonNullable.
Also applies to: 14-14
54-54: Verify consistent usage of make and colorName across the app
The changes from type to make and color to colorName look good, but let's ensure these new fields are consistently used across other components.
Also applies to: 60-61
apps/native/app/src/screens/home/vehicles-module.tsx (3)
52-52: LGTM! Props interface is properly typed.
The interface update correctly reflects the V2 query type changes.
173-173: Verify the usage of exported items.
The exports have been updated correctly for V2. Let's verify their usage across the codebase.
✅ Verification successful
All exported items are being used appropriately in the codebase
The verification shows that both useListVehiclesV2Query and validateVehiclesInitialData are actively used:
useListVehiclesV2Queryis used inhome.tsxandvehicles.tsxvalidateVehiclesInitialDatais used inhome.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the usage of exported items
# Check for usage of the exported hook and validation function
rg "useListVehiclesV2Query|validateVehiclesInitialData" -g '!*.{md,txt,graphql}'
Length of output: 891
20-21: Verify the V2 query implementation and types.
The transition to V2 query looks good. However, let's ensure the new query is properly implemented.
✅ Verification successful
Migration to ListVehiclesV2Query is properly implemented
The verification shows that:
- The V2 query is properly defined in
vehicles.graphqlwith correct schema and types - All references to the query in the codebase use the V2 version
- The implementation in
vehicles-module.tsxcorrectly uses the new types and query hook
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the V2 query implementation and types
# Check if the query is properly defined in the schema
ast-grep --pattern 'query ListVehiclesV2'
# Check if there are any remaining references to the old query
rg 'ListVehiclesQuery|useListVehiclesQuery' -g '!*.{md,txt}'
Length of output: 106
Script:
#!/bin/bash
# Let's try a different approach to verify the GraphQL queries
# Search for GraphQL query definitions and usages
rg -t graphql -t typescript "ListVehiclesV2" -A 5
# Check for any GraphQL schema files
fd -e graphql
# Look for generated types related to vehicles
fd -g "*vehicle*.ts" -g "*vehicle*.tsx" --exec grep -l "ListVehicles"
# Check for any remaining old query references in the codebase
rg "useListVehicles(?!V2)" -g "*.{ts,tsx}"
Length of output: 20438
Script:
#!/bin/bash
# Let's check the GraphQL query definitions and usages with a simpler approach
# Check the vehicles.graphql file content
cat apps/native/app/src/graphql/queries/vehicles.graphql
# Look for any references to ListVehicles in typescript files
rg "ListVehicles" -g "*.{ts,tsx}" -A 2
# Check the specific module file
cat "apps/native/app/src/screens/home/vehicles-module.tsx"
Length of output: 9908
apps/native/app/src/screens/home/home.tsx (2)
58-58: LGTM! Import statement updated correctly.
The import statement has been updated to use the new V2 query hook while maintaining consistency with other module imports.
177-184: Verify removal of query parameters.
The query implementation looks good, but we should verify the impact of removing showDeregeristered and showHistory parameters from the input object.
Let's verify the changes in the GraphQL schema and related components:
✅ Verification successful
Parameters can be safely removed
Based on the search results, the removal of showDeregeristered and showHistory parameters from the ListVehiclesV2Query input is safe because:
- The new query implementation in
apps/native/app/src/graphql/queries/vehicles.graphqldoesn't include these parameters in its schema. - The only remaining references to these parameters in the native app are in the vehicle history screen (
libs/portals/my-pages/assets/src/screens/VehicleHistory/), which uses a different query. - The parameters were previously used in the vehicles API (
libs/api/domains/vehicles/), but the V2 version of the query has been updated to not require these parameters.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the impact of removing query parameters
# Check if any components still reference the old parameters
rg -l "showDeregeristered|showHistory" "apps/native"
# Check GraphQL schema changes
ast-grep --pattern 'type ListVehiclesV2Input {
$$$
}'
Length of output: 110
Script:
#!/bin/bash
# Let's try a different approach to verify the schema and usage
# Check GraphQL schema files for ListVehiclesV2Input
fd -e graphql -e gql | xargs rg -l "ListVehiclesV2Input"
# Search for any references to these parameters in TypeScript/JavaScript files
rg "showDeregeristered|showHistory" --type=ts --type=tsx -C 3
# Look for the query definition
rg "useListVehiclesV2Query|ListVehiclesV2Query" --type=ts --type=tsx -C 3
Length of output: 252
Script:
#!/bin/bash
# Let's try without file type specifications since tsx isn't recognized
# Find GraphQL schema files
fd -e graphql -e gql
# Search for any references to these parameters
rg "showDeregeristered|showHistory"
# Look for the query definition and its usage
rg "ListVehiclesV2" -C 3
Length of output: 29780
apps/native/app/src/screens/vehicles/vehicles.tsx (4)
17-18: Updated imports to use ListVehiclesV2
The imports have been correctly updated to use ListVehiclesV2Query and useListVehiclesV2Query, aligning with the new GraphQL schema.
78-80: Correctly initialized useListVehiclesV2Query hook
The query hook useListVehiclesV2Query is properly initialized with the correct variables, ensuring data is fetched using the updated GraphQL query.
150-150: Data mapping updated to new query structure
The data mapping has been appropriately updated to use vehiclesListV2.vehicleList, correctly reflecting the new data structure from the GraphQL query.
203-207: Correctly merging previous and new vehicle lists
The updateQuery function combines the previous and new vehicleList arrays correctly, ensuring that data from multiple pages is concatenated properly for infinite scrolling.
thoreyjona
changed the title
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #16824 +/- ##
==========================================
+ Coverage 35.75% 35.77% +0.02%
==========================================
Files 6925 6929 +4
Lines 147603 148590 +987
Branches 42022 42496 +474
==========================================
+ Hits 52772 53159 +387
- Misses 94831 95431 +600
Flags with carried forward coverage won't be shown. Click here to find out more. see 427 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Datadog ReportAll test runs ✅ 17 Total Test Services: 0 Failed, 14 Passed Test ServicesThis report shows up to 10 services
🔻 Code Coverage Decreases vs Default Branch (2) |
* feat: update vehicleList endpoint to V2 * fix: remove comment * fix: update typo after fix from Hugsmidjan --------- Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
What
Use vehicleListV2 endpoint for app like service portal is using.
NOTE
Don't merge until after next release (26th of November)
Checklist:
Summary by CodeRabbit
New Features
ListVehiclesV2) for improved data retrieval.make,colorName,nextMainInspection) and removed outdated fields.Bug Fixes
Documentation