- Rename $getSettings to $getMasterSettings for clarity
- Remove unused account-specific logic (never called with accountDid)
- Simplify method signature by removing unused key parameter
- Update all 8 call sites and interface definitions
- Maintain backward compatibility for all existing functionality
All calls to $getSettings used MASTER_SETTINGS_KEY, so the complex
branching logic for account-specific settings was unnecessary.
- Change server switching logs from info to debug level
- Implement structured error logging for profile CRUD operations
- Handle HTTP status codes 400, 401, 403, 404, 409 gracefully
- Suppress full error stack traces for expected API responses
- Maintain user notifications while improving console readability
- Add timestamp and context to all profile-related error logs
Improves developer experience by reducing console noise while preserving
debugging information and user-facing error handling.
- Change server switching logs to debug level
- Implement structured error logging for profile operations
- Handle common HTTP status codes gracefully
- Maintain user notifications while cleaning console output
- Replaced all instances of "Unnamed Member" with "Someone Unnamed"
- Removed unused UNNAMED_MEMBER constant
- Renamed UNNAMED_PERSON to THAT_UNNAMED_PERSON to match its value
- Renamed UNNAMED_USER to UNNAMED_PERSON and changed the value to "unnamed person"
Removes over-engineered ProfileService and ServiceInitializationManager
classes that were only used in one place. Inlines all profile logic
directly into AccountViewView.vue to reduce complexity and improve
maintainability.
- Deletes ProfileService.ts (325 lines)
- Deletes ServiceInitializationManager.ts (207 lines)
- Inlines ProfileData interface and methods into AccountViewView
- Maintains all existing functionality while reducing code footprint
perf(logging): convert excessive info logs to debug level
Reduces console noise by converting high-frequency, low-value logging
from info to debug level across navigation, API calls, and component
lifecycle operations. Improves performance and reduces log verbosity
for normal application flow.
- Router navigation guards: info → debug
- Plan loading operations: info → debug
- User registration checks: info → debug
- Image server rate limits: info → debug
- Component lifecycle events: info → debug
- Settings loading operations: info → debug
Maintains warn/error levels for actual issues while reducing noise
from expected application behavior.
- Revert ProfileService from broken /api/partner/userProfile endpoint to working /api/partner/userProfileForIssuer/${did}
- Fix location data display by restoring single profile object response parsing
- Remove complex array handling logic that was unnecessary for current user profiles
- Restore original working functionality that was broken by recent refactoring
Problem: Recent ProfileService creation changed endpoint from working userProfileForIssuer/${did}
to broken userProfile (list endpoint), causing location data to not display properly.
Solution: Revert to original working endpoint and response parsing logic that returns
single profile objects with location data instead of arrays of all profiles.
Files changed:
- src/services/ProfileService.ts: Restore working endpoint and simplify response parsing
Testing: Profile loading now works correctly for both existing and new profiles,
location data is properly extracted and displayed, maps render correctly.
- Add unique request IDs for claim submission tracking
- Add unique request IDs for plan loading tracking
- Include comprehensive request context (endpoint, server, timestamp)
- Enhance error logging with specific error codes and messages
- Improve debugging capabilities for server operations
Testing: TypeScript compilation passes, no linting errors
Impact: Better debugging and monitoring of API operations
- Remove forced production server override in PlatformServiceMixin.()
- Remove forced production server override in PlatformServiceMixin.()
- Remove forced production server override in HomeView.ensureCorrectApiServer()
- Fix type error in HomeView.latLongInAnySearchBox coordinates
Testing: TypeScript compilation passes, no linting errors
Impact: Users can now switch API servers freely without forced overrides
- Fix PlatformServiceMixin.() ambiguous OR condition
- Use specific queries for master settings (id) vs account settings (accountDid)
- Resolve settings priority conflicts affecting server switching
- Maintain backward compatibility with existing settings structure
Testing: TypeScript compilation passes, no linting errors
Impact: Settings now load correctly without query ambiguity
- Fix fetchImageRateLimits to accept configurable imageServer parameter instead
of hardcoded DEFAULT_IMAGE_API_SERVER
- Add enhanced diagnostic logging for image server operations with server
context, error tracking, and user registration status
- Update AccountViewView.vue to pass correct image server parameter
- Ensure consistent server switching behavior across all API endpoints
- Prevent similar server configuration issues in image operations
Fixes server switching not applying to image rate limit checks and provides
complete visibility into image server operations for debugging and monitoring.
- Enhanced user registration diagnostics with detailed error context
- Server switching flow logging with before/after values
- Improved error handling with server context
- Fixed type safety issues
Confirms server switching fix is working perfectly while providing
comprehensive debugging for user migration and environment issues.
- Fix database query logic in PlatformServiceMixin.$getSettings() to properly
distinguish between master settings (ID) and account settings (DID)
- Add comprehensive logging for settings debugging with request IDs and
component tracking
- Fix ProfileService initialization order in AccountViewView to use correct
partnerApiServer after settings load
- Add URL flow testing interface in TestView for debugging server switching
- Enhance settings consistency validation and error handling
Resolves issue where profile server changes were saved but not applied due to
incorrect database query logic and settings priority handling.
Files changed: PlatformServiceMixin.ts, AccountViewView.vue, TestView.vue,
TopMessage.vue, main.ts, router/index.ts
Testing: Added comprehensive URL flow testing interface for validation
- Add @capacitor/status-bar dependency for safe area detection
- Implement SafeAreaPlugin for Android with proper inset calculation
- Create safeAreaInset.js utility for CSS custom property injection
- Update Android manifest and build configuration for plugin
- Integrate safe area handling across Vue components and views
- Update iOS Podfile and Android gradle configurations
- Add commitlint and husky for commit message validation
Technical changes:
- SafeAreaPlugin uses WindowInsets API for Android R+ devices
- Fallback detection for navigation bar and gesture bar heights
- CSS custom properties: --safe-area-inset-{top,bottom,left,right}
- Platform-specific detection (Android WebView only)
- StatusBar plugin integration for top inset calculation
- Replace custom onboarding button with RegistrationNotice component
- Maintain v-else conditional rendering for unregistered users
- Remove unused methods and imports related to custom registration flow
- Use contextual message "To announce a project, get someone to onboard you."
- Remove unnecessary wrapping div in RegistrationNotice
Completes registration UI standardization across all main views.
- Centralize all registration notice logic within upgraded RegistrationNotice component
- Clean up unused methods and imports in HomeView and AccountViewView
- Customizable message to maintain original contextual wordings unique to each view
Component is now more focused and follows Vue.js best practices
for conditional rendering.
- Add DID validation using isDid() function to prevent invalid DIDs from loading current user's info
- Show error message and redirect to HomeView for invalid DID formats (e.g., /did/0)
- Import NOTIFY_CONTACT_INVALID_DID constant for consistent error messaging
Resolves: DIDView loading current user's info for invalid DID parameters
- Replace unsafe (error as any).config patterns with proper type guards
- Add hasConfigProperty() type guard for safe error property checking
- Add getConfigProperty() method for type-safe config extraction
- Eliminate @typescript-eslint/no-explicit-any violations
Problem: ProfileService had unsafe type casting with (error as any).config
that violated TypeScript type safety guidelines and caused linting errors.
Solution: Implement proper type guards following established patterns:
- hasConfigProperty() safely checks if error has config property
- getConfigProperty() extracts config without type casting
- Maintains exact same functionality while ensuring type safety
Files changed:
- src/services/ProfileService.ts: Replace any types with type guards
Testing: Linting passes, type-check passes, functionality preserved.
Fix iOS deep link "Invalid Deep Link" error by updating parseDeepLink
to use correct parameter keys from ROUTE_MAP instead of always using 'id'.
- Replace hardcoded 'id' parameter assignment with dynamic lookup
- Use routeConfig.paramKey for route-specific parameter names (e.g., groupId for onboard-meeting-members)
- Maintain backward compatibility with fallback to 'id' for routes without explicit paramKey
- Add src/main.ts as dynamic entry point that loads platform-specific code
- Update index.html to use dynamic main.ts instead of hardcoded main.web.ts
- Remove external capacitor config from vite.config.common.mts to ensure proper bundling
- Enables consistent platform detection across all build targets
- Use proper logger utility instead of console.log for platform detection logging
