[Research]: Graph API integration #1958
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Implements Phase 1 of Microsoft Graph API integration for Teams for Linux,
enabling access to Microsoft Graph API endpoints using existing Teams
authentication infrastructure.
## Key Features
### 1. Graph API Client Module (app/graphApi/)
- New GraphApiClient class for Microsoft Graph API integration
- Token acquisition via existing Teams authentication provider
- Support for multiple Graph API endpoints:
- User profile (/me)
- Calendar events and calendar view
- Mail messages
- Presence information
- Calendar event creation/updates
- Automatic token caching with 5-minute expiry buffer
- Comprehensive error handling and logging
### 2. ReactHandler Token Acquisition
- Added `acquireToken()` method to ReactHandler
- Supports arbitrary resource URLs (Graph API, SharePoint, etc.)
- Leverages existing Teams authentication service
- Configurable token acquisition options (forceRenew, forceRefresh, etc.)
- Properly exposed to browser context via window.teamsForLinuxReactHandler
### 3. Configuration Support
- Added `graphApi` configuration option to config system
- Disabled by default (opt-in feature)
- Simple enable/disable flag in config.json
### 4. IPC Integration
- 7 new IPC handlers for Graph API operations:
- graph-api-get-user-profile
- graph-api-get-calendar-events
- graph-api-get-calendar-view
- graph-api-create-calendar-event
- graph-api-get-mail-messages
- graph-api-get-presence
- graph-api-get-diagnostics
- All channels added to IPC security allowlist
- Proper validation and error handling
### 5. Browser Integration
- ReactHandler properly initialized in preload.js
- Window exposure for JavaScript access
- Seamless integration with existing module loading pattern
## Implementation Details
- Uses existing Teams authentication tokens (no separate auth required)
- Graceful fallback when Graph API is disabled
- Follows existing project patterns (module structure, error handling, logging)
- Zero impact when feature is disabled
- No external dependencies added
## Usage
Enable in config.json:
```json
{
"graphApi": {
"enabled": true
}
}
```
Then access via IPC from renderer or use GraphApiClient from main process.
## Technical Architecture
```
Teams Auth Provider (Browser)
↓ (acquireToken via ReactHandler)
Graph API Client (Main Process)
↓ (HTTP requests with Bearer token)
Microsoft Graph API (graph.microsoft.com)
```
## Testing
- All code passes ESLint validation
- Follows existing Teams for Linux patterns
- Ready for integration testing
## Future Enhancements
This implements Phase 1 foundation. Future phases can add:
- Enhanced features (Phase 2): Email notifications, meeting scheduling
- Authentication improvements (Phase 3): Token refresh mechanisms
- UI components for Graph API features
- Additional Graph API endpoints as needed
Addresses issue #1832
Contributor
Summary of ChangesHello @IsmaelMartinez, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces the foundational Phase 1 integration of the Microsoft Graph API into Teams for Linux. The primary goal is to enable access to various Microsoft Graph API endpoints, such as user profiles, calendar, mail, and presence, by leveraging the application's existing authentication infrastructure. This provides a secure and configurable mechanism for future enhancements that will utilize these new capabilities, while ensuring minimal impact when the feature is disabled. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a significant new feature by integrating the Microsoft Graph API. The implementation is well-structured, with a clear separation of concerns between the main process API client (GraphApiClient) and the renderer-side token acquisition logic (ReactHandler). The changes are gated behind a configuration flag, which is a good practice for new features.
My review focuses on improving the robustness of the API client, reducing code duplication, and enhancing maintainability. I've suggested changes to handle API responses more gracefully and to refactor repetitive code blocks in both the API client and the IPC handler registration.
Based on code review feedback, this commit makes several improvements to the Graph API integration: ## 1. Robust JSON Response Handling The makeRequest method now properly handles: - Empty responses (204 No Content) - Non-JSON responses - Content-Type validation before parsing - Graceful error messages when JSON parsing fails This prevents crashes when Graph API returns empty or non-JSON responses (e.g., successful DELETE operations). ## 2. DRY Query String Building - Added _buildODataQuery() helper method - Supports common OData parameters: $top, $select, $filter, $orderby, $skip, $count, $search, $expand - Eliminates duplicated code in getCalendarEvents and getMailMessages - Makes it easier to add more OData endpoints in the future ## 3. Reduced IPC Handler Boilerplate Refactored Graph API IPC handlers using loop-based registration: - Reduced ~40 lines of duplicated code to ~15 lines - Easier to add new Graph API endpoints - Consistent error handling across all handlers - Cleaner, more maintainable code ## 4. Cross-Environment Window Access Changed window to globalThis.window in reactHandler.js for better compatibility across different JavaScript environments. ## Benefits - More robust error handling (no crashes on edge cases) - Better code maintainability (less duplication) - Easier extensibility (adding new endpoints is simpler) - Follows JavaScript best practices All changes pass ESLint validation.
Owner
Author
|
blocked by #1959 |
IsmaelMartinez
pushed a commit
that referenced
this pull request
Nov 17, 2025
Phase 1 successfully completed with outstanding results: - All 4 extractions complete - 416 lines removed from index.js (111% of 374 target) - 55% reduction achieved (target was 49%) - index.js: 755 → 339 lines Completed extractions: 1. Command line logic (96 lines) - #1955 2. Notification system (82 lines) - #1962 3. Screen sharing handlers (166 lines) - #1966 4. Partitions & idle state (68 lines) - #1968 New modules created: - app/startup/commandLine.js - app/notifications/service.js - app/screenSharing/service.js - app/partitions/manager.js - app/idle/monitor.js Next steps: Documentation consolidation (#1957), then evaluate Phase 2 (testability) vs feature implementation sprint. All previously blocked work is now unblocked: - #1935 (notification modal) - #1937 (config options) - #1958 (Graph API)
4 tasks
IsmaelMartinez
added a commit
that referenced
this pull request
Nov 18, 2025
… 2 Reassessment (#1970) * docs: update incremental refactoring plan with Phase 1 progress Update progress tracking to reflect completed extractions: - Extraction 1: Command line (96 lines) ✓ - Extraction 2: Notifications (82 lines) ✓ - Extraction 3: Screen sharing (166 lines) ✓ - Extraction 4: Partitions/idle (in progress) Current: 407 LOC in index.js (348 lines removed, 93% complete) Target: 381 LOC (374 lines removed) Updated next steps to reflect current plan: 1. Complete Extraction 4 2. Documentation work (#1957) 3. Evaluate next direction (MQTT, Phase 2, or features) * docs: mark Phase 1 refactoring as COMPLETE Phase 1 successfully completed with outstanding results: - All 4 extractions complete - 416 lines removed from index.js (111% of 374 target) - 55% reduction achieved (target was 49%) - index.js: 755 → 339 lines Completed extractions: 1. Command line logic (96 lines) - #1955 2. Notification system (82 lines) - #1962 3. Screen sharing handlers (166 lines) - #1966 4. Partitions & idle state (68 lines) - #1968 New modules created: - app/startup/commandLine.js - app/notifications/service.js - app/screenSharing/service.js - app/partitions/manager.js - app/idle/monitor.js Next steps: Documentation consolidation (#1957), then evaluate Phase 2 (testability) vs feature implementation sprint. All previously blocked work is now unblocked: - #1935 (notification modal) - #1937 (config options) - #1958 (Graph API) * docs: reassess Phase 2 testing goals with realistic constraints Updated Phase 2 plan to reflect Microsoft authentication limitations: Testing Challenges: - MS authentication blocks automated login (bot detection) - Current E2E tests only verify app startup, no actual flows - Cannot test: login, notifications, screen sharing, presence - Full E2E testing not achievable or worth the effort Revised Phase 2 Approach: - Focus on achievable items: singleton refactoring, IPC patterns, documentation automation - Realistic testing target: 5-10 unit tests (not 20+ E2E tests) - Expected coverage: 15-20% (not 40%+) - Manual testing for Teams-dependent features Updated Recommendations: - Option A: Selective Phase 2 (achievable items only) - Option B: Feature implementation sprint (recommended) - Option C: Hybrid (doc automation + features) Skip extensive automated testing due to external blockers. Focus on high-value, achievable improvements instead. * docs: remove conversation-specific Next Steps section The 'Phase 1 Complete - Decision Point Reached' section was specific to the planning conversation and doesn't belong in the repository documentation. Removed: - Decision point reached announcement - Path A/B/C options and recommendations - Unblocked work tracking - Current focus priorities These are conversation artifacts, not permanent documentation. * chore: add changelog entry for PR #1970 * docs: fix screen sharing filename inconsistency Updated Week 3 section to reflect actual filename: - app/screenSharing/ipcHandlers.js → app/screenSharing/service.js The actual implementation uses service.js (as shown in the 'New Modules Created' section). Updated plan document to be consistent throughout. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Aligns with #1959 architectural modernization effort by extracting IPC handlers from app/index.js into a separate module. ## Changes ### 1. Created app/graphApi/ipcHandlers.js - Extracted all Graph API IPC handlers to dedicated module - Uses loop-based registration pattern for maintainability - Consistent error handling for disabled Graph API - Proper logging of handler registration ### 2. Updated app/index.js - Import and use registerGraphApiHandlers function - Removed ~20 lines of IPC handler code from main file - Cleaner separation of concerns - Supports #1959 goal of reducing index.js complexity ### 3. Merged changes from main - Resolved merge conflicts - Updated comments for navigation IPC handlers ## Benefits - **Aligns with #1959**: Follows modular extraction pattern - **Reduces index.js size**: Moves IPC handlers out of main file - **Better maintainability**: Graph API handlers in logical location - **Easier testing**: Isolated handlers can be tested independently - **Consistent pattern**: Can serve as template for other extractions This unblocks the Graph API integration by aligning with the ongoing architectural modernization effort. All changes pass ESLint validation.
Contributor
|
✅ Changelog entry generated and committed to this PR: The file You can edit it directly in this PR if needed. |
Contributor
📦 PR Build Artifacts✅ Build successful! Download artifacts:
|
* docs: deduplicate and clean up development documentation - Remove redundant research files: - ui-system-strategic-analysis.md (unimplemented proposal) - changelog-generator-setup.md (redundant with ADR-005) - release-pr-workflow-plan.md (unimplemented future automation) - documentation-improvement-recommendations.md (info in issues/code) - Simplify architecture-modernization-research.md to brief summary - Update release-info.md to focus on technical details, remove outdated workflow sections that duplicated manual-release-process.md - Update all references to point to correct documentation - Simplify sidebars.ts research section structure - Update research/README.md with cleaner organization This reduces documentation from 65 to 61 files and eliminates duplication between release process docs. * chore: add changelog entry for PR #1975 --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Simplify docs homepage and screen sharing guide - Reduce index.md by removing individual ADR links, referencing landing pages instead - Simplify architecture diagram to show high-level overview - Remove quick-reference.md to avoid duplicate information - Streamline screen-sharing.md by removing developer-focused sections (How it Works, Security Considerations, Development Information, Best Practices) This makes documentation more maintainable and user-focused. * chore: add changelog entry for PR #1976 * Remove quick-reference from sidebar --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* Add comprehensive research documentation for custom notification system This research document captures the investigation into creating an alternative notification modal system for Teams for Linux to address cross-platform reliability issues with OS-level notifications. Key findings: - Current OS notifications unreliable on Linux (daemon freezing, inconsistencies) - Existing npm libraries too old (5-9 years) and incompatible with modern Electron - React toast libraries incompatible due to Electron wrapper architecture - Custom BrowserWindow implementation recommended following IncomingCallToast pattern Decisions documented: - UI Design: Follow Microsoft Teams design language - Actions: Start simple (View, Dismiss), iterate based on feedback - Shortcuts: None initially - Sounds: Reuse existing notification sounds - Tray: No integration needed - DND: Phase 2 feature linked to existing status detection Implementation approach: - Two-component system: NotificationToast (popups) + NotificationCenter (history) - IndexedDB for persistent storage (last 100 notifications, 7-day auto-cleanup) - Vanilla JavaScript/HTML/CSS (no React dependency) - Security-first: contextIsolation enabled, IPC validation - Timeline: 2-3 weeks for MVP Document includes: - Comprehensive library evaluation - Architectural constraints analysis - Complete implementation plan with phases - Risk assessment and mitigation strategies - Alternatives considered and rejected - Migration/rollout strategy (opt-in → beta → stable) Related: Investigation for custom notification modal alternative * Fix research document MDX compilation and code issues Fixes for custom-notification-system-research.md: 1. MDX Compilation Error (line 704): - Changed `<50ms` to `<50ms` to escape HTML entity - Prevents MDX from interpreting as invalid JSX tag 2. NotificationStore Class Issues: - Added EventEmitter import and extension - Added super() call in constructor - Added missing getUnreadCount() method used in IPC handler example 3. CSS Syntax Error (line 454): - Fixed invalid font-size property - Changed to valid CSS comment format 4. NotificationCenter Class: - Added missing updateBadge() method called in IPC handler example All code examples now compile correctly with Docusaurus MDX parser and match the implementation patterns used in the document. * Fix broken link in research documentation The IncomingCallToast reference was linking to a source code directory (../../incomingCallToast/) which doesn't exist in the documentation site, causing Docusaurus build to fail. Changed from: - **[IncomingCallToast Implementation](../../incomingCallToast/)** To: - **IncomingCallToast Implementation** (`app/incomingCallToast/`) This clarifies that we're referencing source code patterns, not documentation, and resolves the Docusaurus broken link error. * Refine custom notification research based on feedback Major updates to simplify MVP and clarify this is an opt-in alternative: Formatting & Clarity: - Fix "What We CAN Do" and "What We CANNOT Do" sections as proper lists - Fix Security Considerations section (6.3) as proper list - Update #1921 references to indicate closed/fixed issue Simplified MVP Approach: - Remove IndexedDB persistence from MVP (move to Phase 2) - Use in-memory notification storage for simplicity - Remove toast queue management from MVP (Phase 2 feature) - Remove maxVisible config option (add if users request it) - Timeline reduced from 3 weeks to 2 weeks Configuration Redesign: - Unified notification method: "web" | "electron" | "custom" - Group custom notification options into customNotification object - Align with existing notificationMethod pattern for consistency - Default remains "web" - no breaking changes - Explicit opt-in via notificationMethod: "custom" - Document backward compatibility strategy Rollout Strategy Changes: - This is an ALTERNATIVE, not a replacement - Keep all three notification methods fully supported - No deprecation of existing web/electron methods - Users choose based on their needs - Opt-in only - default unchanged Future Enhancements Updated: - Move storage/persistence to Phase 2 - Add toast queue management to Phase 2 - Add incoming call command integration to Phase 3 - Emphasize starting simple, iterate based on feedback - Only add complexity if users need it Success Criteria Updated: - Remove "persist across restarts" requirement - Change to "session-based" notification history - Focus on core functionality working reliably Conclusion Revised: - Emphasize this as third option for users with OS notification issues - Clarify no disruption to existing users - Highlight simplified MVP approach (2 weeks, basic features) - Key principle: Start simple, iterate based on actual user feedback * Simplify custom notification system research to ultra-minimal MVP Major simplifications based on "start simple" principle: MVP Scope Changes: - Remove notification center entirely from MVP - Remove notification history/storage (no NotificationStore) - Remove all action buttons (View, Dismiss, etc.) - Remove toast queue management - Focus on single feature: show toast and auto-dismiss Architecture Updates: - Phase 1: Toast notifications only - Phase 2+: Everything else (center, history, actions, etc.) - Timeline reduced from 2-3 weeks to ~1 week Component Design: - Keep: NotificationToast only - Remove: NotificationCenter and NotificationStore from MVP - Simplified data model (just id, timestamp, title, body, icon) Configuration: - Remove showHistory option (not needed for MVP) - Simplified customNotification config object File Structure: - Flat structure (no center/ or store/ subdirectories) - Just 4 files: index.js, NotificationToast.js, .html, .preload.js IPC: - Single channel: 'notification-show-toast' - No complex handlers, just basic validation Future Enhancements: - Clearly separated all deferred features into Phase 2+ - Emphasized "add only if users request" philosophy This ultra-minimal MVP validates core functionality with minimal risk, development time, and maintenance burden. * Simplify config approach - reuse existing notificationMethod Changes: - Remove deprecated webNotification/electronNotification placeholders - Just extend existing notificationMethod with "custom" choice - Simplify customNotification config (remove "enabled" field) - Use notificationMethod value to determine if custom is active - Add note about ongoing config reorganization project This aligns with the project's existing config management strategy and avoids introducing deprecated options that will be migrated by the ongoing config reorganization work. * chore: add changelog entry for PR #1935 * Update custom notification research for Phase 1 refactoring integration Major updates to align with completed Incremental Refactoring Plan Phase 1: Architecture Integration: - Add prerequisite: Phase 1 Extraction 2 (NotificationService) complete - Integrate with existing NotificationService rather than replacing it - CustomNotificationManager coexists with NotificationService - Clear separation: Native (NotificationService) vs Custom (CustomNotificationManager) IPC Channel Updates: - Document existing channels: show-notification, play-notification-sound - Add new channel: notification-show-toast (for custom toasts) - Show integration pattern in app/index.js File Structure Updates: - New module: app/notificationSystem/ (custom toasts) - Existing module: app/notifications/ (native notifications from Phase 1) - Modified files: index.js, preload.js, ipcValidator.js - Clear distinction between native and custom notification systems Benefits from Refactoring: - Cleaner integration (not adding to 755-line index.js, now 339 lines) - Follows established NotificationService pattern - Reduced complexity by leveraging refactored architecture - Timeline unchanged (~1 week for MVP) Related Documentation: - Link to Incremental Refactoring Plan as prerequisite - Reference NotificationService implementation - Update next steps to reflect integration with existing service The research plan remains fundamentally sound - just better integration points thanks to the completed refactoring work. * Fix broken links after documentation consolidation Update custom notification research to fix broken links after the documentation consolidation in #1957: - Replace incremental-refactoring-plan.md link with contributing.md (plan was consolidated into contributing guide) - Update Related Documentation section references - Update Impact of Phase 1 Refactoring section references The incremental refactoring plan content is now part of the Architecture section in the Contributing Guide. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
* [Feature]: Implement custom notifications modal MVP (#1977) Add custom in-app toast notification system as an alternative to OS-level notifications for users experiencing reliability issues (especially on Linux). **MVP Features:** - Custom BrowserWindow-based toast notifications - Auto-dismiss after 5 seconds (configurable) - Click-to-focus main window - Teams design language styling - Multi-monitor support via electron-positioner - Sound integration with existing audio system **Files Added:** - app/notificationSystem/ module with: - CustomNotificationManager: Main IPC handler - NotificationToast: BrowserWindow wrapper per notification - notificationToast.html: Teams-styled UI - notificationToastPreload.js: Secure IPC bridge - README.md: Module documentation **Files Modified:** - app/config/index.js: Added "custom" notification method option - app/security/ipcValidator.js: Added notification-show-toast IPC channel - app/index.js: Integrated CustomNotificationManager initialization - app/browser/preload.js: Route custom notifications via new path **Configuration:** Users can enable via: notificationMethod: "custom" This is an opt-in MVP implementation with plans for Phase 2+ enhancements: - Notification center with history - Action buttons (View, Dismiss, Reply) - Queue management and toast stacking - DND mode integration Follows established IncomingCallToast pattern for consistency. All code passes ESLint validation. * chore: add changelog entry for PR #1979 * Fix custom notifications: Add click handler and improve toast lifecycle management - Add missing 'notification-toast-click' IPC channel to allowlist - Implement proper IPC listener for click events in NotificationToast - Track active toasts in manager to prevent garbage collection - Remove unused #config parameter from CustomNotificationManager - Fix race condition in toast window initialization - #handleClick method now properly called via IPC event - Improve cleanup of IPC handlers when toasts close Fixes SonarQube code smell warnings about unused code. * Improve notification toast UI design and layout - Increase icon size from 24x24px to 48x48px for better visibility - Add Teams purple gradient background to icon container - Improve typography: larger title (14px, 600 weight) and body text - Enhance visual hierarchy with better spacing and alignment - Larger window size: 380x140px to accommodate improved layout - Better color scheme: lighter background (#2D2D2D), improved contrast - Add subtle border and enhanced shadow for modern appearance - Improve hover/active states with smooth transitions - Better footer styling with reduced opacity for subtlety The notification now displays with a professional Teams-like appearance with proper avatar icon sizing and improved readability. * Simplify notification toast UI by removing avatar icon - Remove problematic user avatar icon from header - Keep Teams icon in footer only - Simplified layout focused on title and message - Adjust window size to 360x110px (compact layout) - Icon placeholder for future enhancements (meeting, message, etc.) The notification now displays cleanly without complex icon handling. Icons can be added later to indicate notification type (message/meeting/etc). * Improve code clarity and add IPC documentation **Documentation:** - Add 'Notifications (Custom)' category to IPC script - Generate IPC docs including notification-show-toast channel - Simplify README.md: concise, focused on general concepts **Code Quality:** - Remove unnecessary comments explaining 'what' (code is self-documenting) - Keep only 'why' comments for non-obvious logic - Simplify NotificationToast: remove verbose JSDoc, clean up comments - Simplify CustomNotificationManager: remove class documentation, streamline - Simplify HTML/JS in notification toast UI - Update IPC registration comment for documentation generator **Principles Applied:** - Code should document itself through clear naming - Comments should explain 'why', not 'how' - Documentation generation integrated with IPC channels * Remove speculative language from module documentation - Remove 'MVP' references from README - Remove 'Future Enhancements' section - Remove 'Phase 2' references - Focus documentation on what the code DOES, not what it might do Documentation should describe the current implementation, not speculate about features that may never be implemented. Future plans belong in research/planning documents, not in code documentation. * Remove speculative language from configuration description - Remove 'MVP' reference from customNotification config description - Config description should describe what it does, not what phase it's in * Refactor notification system: centralize click handling and improve consistency - Fix sendNotificationToast return type: throw synchronously instead of returning Promise.reject() - Centralize click event handling in CustomNotificationManager instead of per-toast - Remove redundant onClickCallback parameter from NotificationToast - Add getWebContents() method to identify source window for click events - Remove per-toast ipcMain.once listener in favor of manager's centralized handler - Clean up unused imports and private fields in NotificationToast This improves code architecture by consolidating IPC event handling in the manager and ensures consistent synchronous error handling in the sendNotificationToast API. * Remove unused #handleClick method from NotificationToast The method is no longer needed after centralizing click handling in CustomNotificationManager. The manager now calls toast.close() directly. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Use cleaner text-first approach for parsing API responses: - Read response as text first - Parse JSON only if text is not empty - Handles 204 No Content and non-JSON responses gracefully - Include raw response text in error messages for better debugging Also merged latest changes from main.
- Use direct undefined comparison instead of typeof - Document intentional exception handling and use parseError in logging
reactHandler is already required by settings.js, theme.js, and others, so it's automatically loaded and exposed to window. Adding it to the modules list was redundant.
Prefer clean self-documenting code over verbose JSDoc comments in internal modules. Kept only comments for non-obvious decisions: - 5-minute token cache buffer for race condition prevention - Intentional exception handling for non-JSON responses
…docs - Remove getPresence endpoint (returns 403 Forbidden due to token scope) - Add graphApi configuration to docs-site/docs/configuration.md - Add Graph API module to module-index.md - Update research doc with endpoint restrictions - Regenerate IPC documentation (5 channels)
|
IsmaelMartinez
deleted the
claude/implement-issue-1832-011CV3QCy76dYdJ1MsqV8Din
branch
IsmaelMartinez
added a commit
that referenced
this pull request
Nov 21, 2025
* feat: Add Microsoft Graph API integration (#1832) Implements Phase 1 of Microsoft Graph API integration for Teams for Linux, enabling access to Microsoft Graph API endpoints using existing Teams authentication infrastructure. ## Key Features ### 1. Graph API Client Module (app/graphApi/) - New GraphApiClient class for Microsoft Graph API integration - Token acquisition via existing Teams authentication provider - Support for multiple Graph API endpoints: - User profile (/me) - Calendar events and calendar view - Mail messages - Presence information - Calendar event creation/updates - Automatic token caching with 5-minute expiry buffer - Comprehensive error handling and logging ### 2. ReactHandler Token Acquisition - Added `acquireToken()` method to ReactHandler - Supports arbitrary resource URLs (Graph API, SharePoint, etc.) - Leverages existing Teams authentication service - Configurable token acquisition options (forceRenew, forceRefresh, etc.) - Properly exposed to browser context via window.teamsForLinuxReactHandler ### 3. Configuration Support - Added `graphApi` configuration option to config system - Disabled by default (opt-in feature) - Simple enable/disable flag in config.json ### 4. IPC Integration - 7 new IPC handlers for Graph API operations: - graph-api-get-user-profile - graph-api-get-calendar-events - graph-api-get-calendar-view - graph-api-create-calendar-event - graph-api-get-mail-messages - graph-api-get-presence - graph-api-get-diagnostics - All channels added to IPC security allowlist - Proper validation and error handling ### 5. Browser Integration - ReactHandler properly initialized in preload.js - Window exposure for JavaScript access - Seamless integration with existing module loading pattern ## Implementation Details - Uses existing Teams authentication tokens (no separate auth required) - Graceful fallback when Graph API is disabled - Follows existing project patterns (module structure, error handling, logging) - Zero impact when feature is disabled - No external dependencies added ## Usage Enable in config.json: ```json { "graphApi": { "enabled": true } } ``` Then access via IPC from renderer or use GraphApiClient from main process. ## Technical Architecture ``` Teams Auth Provider (Browser) ↓ (acquireToken via ReactHandler) Graph API Client (Main Process) ↓ (HTTP requests with Bearer token) Microsoft Graph API (graph.microsoft.com) ``` ## Testing - All code passes ESLint validation - Follows existing Teams for Linux patterns - Ready for integration testing ## Future Enhancements This implements Phase 1 foundation. Future phases can add: - Enhanced features (Phase 2): Email notifications, meeting scheduling - Authentication improvements (Phase 3): Token refresh mechanisms - UI components for Graph API features - Additional Graph API endpoints as needed Addresses issue #1832 * refactor: Improve Graph API implementation robustness Based on code review feedback, this commit makes several improvements to the Graph API integration: ## 1. Robust JSON Response Handling The makeRequest method now properly handles: - Empty responses (204 No Content) - Non-JSON responses - Content-Type validation before parsing - Graceful error messages when JSON parsing fails This prevents crashes when Graph API returns empty or non-JSON responses (e.g., successful DELETE operations). ## 2. DRY Query String Building - Added _buildODataQuery() helper method - Supports common OData parameters: $top, $select, $filter, $orderby, $skip, $count, $search, $expand - Eliminates duplicated code in getCalendarEvents and getMailMessages - Makes it easier to add more OData endpoints in the future ## 3. Reduced IPC Handler Boilerplate Refactored Graph API IPC handlers using loop-based registration: - Reduced ~40 lines of duplicated code to ~15 lines - Easier to add new Graph API endpoints - Consistent error handling across all handlers - Cleaner, more maintainable code ## 4. Cross-Environment Window Access Changed window to globalThis.window in reactHandler.js for better compatibility across different JavaScript environments. ## Benefits - More robust error handling (no crashes on edge cases) - Better code maintainability (less duplication) - Easier extensibility (adding new endpoints is simpler) - Follows JavaScript best practices All changes pass ESLint validation. * chore: add changelog entry for PR #1958 * Review and reduce duplication in development docs (#1975) * docs: deduplicate and clean up development documentation - Remove redundant research files: - ui-system-strategic-analysis.md (unimplemented proposal) - changelog-generator-setup.md (redundant with ADR-005) - release-pr-workflow-plan.md (unimplemented future automation) - documentation-improvement-recommendations.md (info in issues/code) - Simplify architecture-modernization-research.md to brief summary - Update release-info.md to focus on technical details, remove outdated workflow sections that duplicated manual-release-process.md - Update all references to point to correct documentation - Simplify sidebars.ts research section structure - Update research/README.md with cleaner organization This reduces documentation from 65 to 61 files and eliminates duplication between release process docs. * chore: add changelog entry for PR #1975 --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> * Simplify docs homepage and quick reference (#1976) * Simplify docs homepage and screen sharing guide - Reduce index.md by removing individual ADR links, referencing landing pages instead - Simplify architecture diagram to show high-level overview - Remove quick-reference.md to avoid duplicate information - Streamline screen-sharing.md by removing developer-focused sections (How it Works, Security Considerations, Development Information, Best Practices) This makes documentation more maintainable and user-focused. * chore: add changelog entry for PR #1976 * Remove quick-reference from sidebar --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> * [Research]: Build notification modal component (#1935) * Add comprehensive research documentation for custom notification system This research document captures the investigation into creating an alternative notification modal system for Teams for Linux to address cross-platform reliability issues with OS-level notifications. Key findings: - Current OS notifications unreliable on Linux (daemon freezing, inconsistencies) - Existing npm libraries too old (5-9 years) and incompatible with modern Electron - React toast libraries incompatible due to Electron wrapper architecture - Custom BrowserWindow implementation recommended following IncomingCallToast pattern Decisions documented: - UI Design: Follow Microsoft Teams design language - Actions: Start simple (View, Dismiss), iterate based on feedback - Shortcuts: None initially - Sounds: Reuse existing notification sounds - Tray: No integration needed - DND: Phase 2 feature linked to existing status detection Implementation approach: - Two-component system: NotificationToast (popups) + NotificationCenter (history) - IndexedDB for persistent storage (last 100 notifications, 7-day auto-cleanup) - Vanilla JavaScript/HTML/CSS (no React dependency) - Security-first: contextIsolation enabled, IPC validation - Timeline: 2-3 weeks for MVP Document includes: - Comprehensive library evaluation - Architectural constraints analysis - Complete implementation plan with phases - Risk assessment and mitigation strategies - Alternatives considered and rejected - Migration/rollout strategy (opt-in → beta → stable) Related: Investigation for custom notification modal alternative * Fix research document MDX compilation and code issues Fixes for custom-notification-system-research.md: 1. MDX Compilation Error (line 704): - Changed `<50ms` to `<50ms` to escape HTML entity - Prevents MDX from interpreting as invalid JSX tag 2. NotificationStore Class Issues: - Added EventEmitter import and extension - Added super() call in constructor - Added missing getUnreadCount() method used in IPC handler example 3. CSS Syntax Error (line 454): - Fixed invalid font-size property - Changed to valid CSS comment format 4. NotificationCenter Class: - Added missing updateBadge() method called in IPC handler example All code examples now compile correctly with Docusaurus MDX parser and match the implementation patterns used in the document. * Fix broken link in research documentation The IncomingCallToast reference was linking to a source code directory (../../incomingCallToast/) which doesn't exist in the documentation site, causing Docusaurus build to fail. Changed from: - **[IncomingCallToast Implementation](../../incomingCallToast/)** To: - **IncomingCallToast Implementation** (`app/incomingCallToast/`) This clarifies that we're referencing source code patterns, not documentation, and resolves the Docusaurus broken link error. * Refine custom notification research based on feedback Major updates to simplify MVP and clarify this is an opt-in alternative: Formatting & Clarity: - Fix "What We CAN Do" and "What We CANNOT Do" sections as proper lists - Fix Security Considerations section (6.3) as proper list - Update #1921 references to indicate closed/fixed issue Simplified MVP Approach: - Remove IndexedDB persistence from MVP (move to Phase 2) - Use in-memory notification storage for simplicity - Remove toast queue management from MVP (Phase 2 feature) - Remove maxVisible config option (add if users request it) - Timeline reduced from 3 weeks to 2 weeks Configuration Redesign: - Unified notification method: "web" | "electron" | "custom" - Group custom notification options into customNotification object - Align with existing notificationMethod pattern for consistency - Default remains "web" - no breaking changes - Explicit opt-in via notificationMethod: "custom" - Document backward compatibility strategy Rollout Strategy Changes: - This is an ALTERNATIVE, not a replacement - Keep all three notification methods fully supported - No deprecation of existing web/electron methods - Users choose based on their needs - Opt-in only - default unchanged Future Enhancements Updated: - Move storage/persistence to Phase 2 - Add toast queue management to Phase 2 - Add incoming call command integration to Phase 3 - Emphasize starting simple, iterate based on feedback - Only add complexity if users need it Success Criteria Updated: - Remove "persist across restarts" requirement - Change to "session-based" notification history - Focus on core functionality working reliably Conclusion Revised: - Emphasize this as third option for users with OS notification issues - Clarify no disruption to existing users - Highlight simplified MVP approach (2 weeks, basic features) - Key principle: Start simple, iterate based on actual user feedback * Simplify custom notification system research to ultra-minimal MVP Major simplifications based on "start simple" principle: MVP Scope Changes: - Remove notification center entirely from MVP - Remove notification history/storage (no NotificationStore) - Remove all action buttons (View, Dismiss, etc.) - Remove toast queue management - Focus on single feature: show toast and auto-dismiss Architecture Updates: - Phase 1: Toast notifications only - Phase 2+: Everything else (center, history, actions, etc.) - Timeline reduced from 2-3 weeks to ~1 week Component Design: - Keep: NotificationToast only - Remove: NotificationCenter and NotificationStore from MVP - Simplified data model (just id, timestamp, title, body, icon) Configuration: - Remove showHistory option (not needed for MVP) - Simplified customNotification config object File Structure: - Flat structure (no center/ or store/ subdirectories) - Just 4 files: index.js, NotificationToast.js, .html, .preload.js IPC: - Single channel: 'notification-show-toast' - No complex handlers, just basic validation Future Enhancements: - Clearly separated all deferred features into Phase 2+ - Emphasized "add only if users request" philosophy This ultra-minimal MVP validates core functionality with minimal risk, development time, and maintenance burden. * Simplify config approach - reuse existing notificationMethod Changes: - Remove deprecated webNotification/electronNotification placeholders - Just extend existing notificationMethod with "custom" choice - Simplify customNotification config (remove "enabled" field) - Use notificationMethod value to determine if custom is active - Add note about ongoing config reorganization project This aligns with the project's existing config management strategy and avoids introducing deprecated options that will be migrated by the ongoing config reorganization work. * chore: add changelog entry for PR #1935 * Update custom notification research for Phase 1 refactoring integration Major updates to align with completed Incremental Refactoring Plan Phase 1: Architecture Integration: - Add prerequisite: Phase 1 Extraction 2 (NotificationService) complete - Integrate with existing NotificationService rather than replacing it - CustomNotificationManager coexists with NotificationService - Clear separation: Native (NotificationService) vs Custom (CustomNotificationManager) IPC Channel Updates: - Document existing channels: show-notification, play-notification-sound - Add new channel: notification-show-toast (for custom toasts) - Show integration pattern in app/index.js File Structure Updates: - New module: app/notificationSystem/ (custom toasts) - Existing module: app/notifications/ (native notifications from Phase 1) - Modified files: index.js, preload.js, ipcValidator.js - Clear distinction between native and custom notification systems Benefits from Refactoring: - Cleaner integration (not adding to 755-line index.js, now 339 lines) - Follows established NotificationService pattern - Reduced complexity by leveraging refactored architecture - Timeline unchanged (~1 week for MVP) Related Documentation: - Link to Incremental Refactoring Plan as prerequisite - Reference NotificationService implementation - Update next steps to reflect integration with existing service The research plan remains fundamentally sound - just better integration points thanks to the completed refactoring work. * Fix broken links after documentation consolidation Update custom notification research to fix broken links after the documentation consolidation in #1957: - Replace incremental-refactoring-plan.md link with contributing.md (plan was consolidated into contributing guide) - Update Related Documentation section references - Update Impact of Phase 1 Refactoring section references The incremental refactoring plan content is now part of the Architecture section in the Contributing Guide. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> * Implement notifications modal MVP (#1979) * [Feature]: Implement custom notifications modal MVP (#1977) Add custom in-app toast notification system as an alternative to OS-level notifications for users experiencing reliability issues (especially on Linux). **MVP Features:** - Custom BrowserWindow-based toast notifications - Auto-dismiss after 5 seconds (configurable) - Click-to-focus main window - Teams design language styling - Multi-monitor support via electron-positioner - Sound integration with existing audio system **Files Added:** - app/notificationSystem/ module with: - CustomNotificationManager: Main IPC handler - NotificationToast: BrowserWindow wrapper per notification - notificationToast.html: Teams-styled UI - notificationToastPreload.js: Secure IPC bridge - README.md: Module documentation **Files Modified:** - app/config/index.js: Added "custom" notification method option - app/security/ipcValidator.js: Added notification-show-toast IPC channel - app/index.js: Integrated CustomNotificationManager initialization - app/browser/preload.js: Route custom notifications via new path **Configuration:** Users can enable via: notificationMethod: "custom" This is an opt-in MVP implementation with plans for Phase 2+ enhancements: - Notification center with history - Action buttons (View, Dismiss, Reply) - Queue management and toast stacking - DND mode integration Follows established IncomingCallToast pattern for consistency. All code passes ESLint validation. * chore: add changelog entry for PR #1979 * Fix custom notifications: Add click handler and improve toast lifecycle management - Add missing 'notification-toast-click' IPC channel to allowlist - Implement proper IPC listener for click events in NotificationToast - Track active toasts in manager to prevent garbage collection - Remove unused #config parameter from CustomNotificationManager - Fix race condition in toast window initialization - #handleClick method now properly called via IPC event - Improve cleanup of IPC handlers when toasts close Fixes SonarQube code smell warnings about unused code. * Improve notification toast UI design and layout - Increase icon size from 24x24px to 48x48px for better visibility - Add Teams purple gradient background to icon container - Improve typography: larger title (14px, 600 weight) and body text - Enhance visual hierarchy with better spacing and alignment - Larger window size: 380x140px to accommodate improved layout - Better color scheme: lighter background (#2D2D2D), improved contrast - Add subtle border and enhanced shadow for modern appearance - Improve hover/active states with smooth transitions - Better footer styling with reduced opacity for subtlety The notification now displays with a professional Teams-like appearance with proper avatar icon sizing and improved readability. * Simplify notification toast UI by removing avatar icon - Remove problematic user avatar icon from header - Keep Teams icon in footer only - Simplified layout focused on title and message - Adjust window size to 360x110px (compact layout) - Icon placeholder for future enhancements (meeting, message, etc.) The notification now displays cleanly without complex icon handling. Icons can be added later to indicate notification type (message/meeting/etc). * Improve code clarity and add IPC documentation **Documentation:** - Add 'Notifications (Custom)' category to IPC script - Generate IPC docs including notification-show-toast channel - Simplify README.md: concise, focused on general concepts **Code Quality:** - Remove unnecessary comments explaining 'what' (code is self-documenting) - Keep only 'why' comments for non-obvious logic - Simplify NotificationToast: remove verbose JSDoc, clean up comments - Simplify CustomNotificationManager: remove class documentation, streamline - Simplify HTML/JS in notification toast UI - Update IPC registration comment for documentation generator **Principles Applied:** - Code should document itself through clear naming - Comments should explain 'why', not 'how' - Documentation generation integrated with IPC channels * Remove speculative language from module documentation - Remove 'MVP' references from README - Remove 'Future Enhancements' section - Remove 'Phase 2' references - Focus documentation on what the code DOES, not what it might do Documentation should describe the current implementation, not speculate about features that may never be implemented. Future plans belong in research/planning documents, not in code documentation. * Remove speculative language from configuration description - Remove 'MVP' reference from customNotification config description - Config description should describe what it does, not what phase it's in * Refactor notification system: centralize click handling and improve consistency - Fix sendNotificationToast return type: throw synchronously instead of returning Promise.reject() - Centralize click event handling in CustomNotificationManager instead of per-toast - Remove redundant onClickCallback parameter from NotificationToast - Add getWebContents() method to identify source window for click events - Remove per-toast ipcMain.once listener in favor of manager's centralized handler - Clean up unused imports and private fields in NotificationToast This improves code architecture by consolidating IPC event handling in the manager and ensures consistent synchronous error handling in the sendNotificationToast API. * Remove unused #handleClick method from NotificationToast The method is no longer needed after centralizing click handling in CustomNotificationManager. The manager now calls toast.close() directly. --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> * chore: release v2.6.16 (#1980) * refactor: Simplify makeRequest JSON parsing Use cleaner text-first approach for parsing API responses: - Read response as text first - Parse JSON only if text is not empty - Handles 204 No Content and non-JSON responses gracefully - Include raw response text in error messages for better debugging Also merged latest changes from main. * fix: Address SonarQube code smells - Use direct undefined comparison instead of typeof - Document intentional exception handling and use parseError in logging * fix: Remove unnecessary reactHandler from modules list reactHandler is already required by settings.js, theme.js, and others, so it's automatically loaded and exposed to window. Adding it to the modules list was redundant. * refactor: Remove excessive comments from GraphApiClient Prefer clean self-documenting code over verbose JSDoc comments in internal modules. Kept only comments for non-obvious decisions: - 5-minute token cache buffer for race condition prevention - Intentional exception handling for non-JSON responses * docs: Add concise JSDoc for Graph API public methods * refactor: Simplify GraphApiClient - remove getDiagnostics, inline fetch options * refactor: Use explicit IPC handler registration for doc generation * fix: Remove incorrectly added screen sharing handlers from index.js * docs: Add Graph API integration research document * fix: Add Graph API to preload and fix initialization timing * docs: Document Graph API endpoint access restrictions * feat: Complete Graph API Phase 1 - remove forbidden endpoint, update docs - Remove getPresence endpoint (returns 403 Forbidden due to token scope) - Add graphApi configuration to docs-site/docs/configuration.md - Add Graph API module to module-index.md - Update research doc with endpoint restrictions - Regenerate IPC documentation (5 channels) --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
IsmaelMartinez
pushed a commit
that referenced
this pull request
Nov 25, 2025
- Updated option count from 64 to 65 (new graphApi config) - Added Graph API integration (PR #1958) to recent improvements - Added graphApi to conditional options and good nested objects examples - Referenced new MQTT enhancement research and ADRs (006, 007) - Updated all line counts and totals throughout document The graphApi option follows the same conditional pattern as customNotification - only relevant when enabled, reinforcing finding #3 about not all implementations needing all features.
Merged
IsmaelMartinez
added a commit
that referenced
this pull request
Nov 28, 2025
* Add comprehensive configuration organization research - Document analysis of all 53 configuration options - Identify issues: scattered options, missing MQTT docs, deprecated options - Propose three-phase migration plan from flat to nested structure - Include detailed migration mapping and backward compatibility strategy - Add research document to Strategic Analysis section Key findings: - MQTT config exists but undocumented - Related options scattered (notifications: 9 opts, idle: 4 opts) - Naming inconsistencies (disable* vs *Enabled) - Recommend gradual migration with auto-conversion for v2.x See docs-site/docs/development/research/configuration-organization-research.md * Fix configuration research document issues - Sort Strategic Analysis section alphabetically in README.md - Correct option counts: Notifications & UI (8→10), Screen Sharing (6→7), System Integration (9→10) - Fix Authentication & SSO formatting: use nested lists instead of h4 headers - Fix migration table: appTitle note should be "Moved" not "Renamed" - Fix broken Docusaurus link: use GitHub URL for MQTT README instead of relative path Addresses feedback from Gemini and fixes Docusaurus build error. * Update configuration research to reflect MQTT documentation completion MQTT documentation was added in PR #1939 after this research began, addressing one of the key findings. Updated the research document to reflect this progress: Changes: - Mark MQTT documentation as RESOLVED in Executive Summary - Update Key Finding #1 to show completion status - Mark Problem 1 as RESOLVED with solution details - Update Phase 1 changes to mark MQTT as completed - Update Phase 1 roadmap checklist to mark MQTT task done - Update success criteria to mark MQTT as completed - Reduce remaining Phase 1 effort estimate (4-6h → 2-4h) - Update conclusion with Phase 1 status - Add MQTT documentation PR #1939 to Related Issues The research remains valid - MQTT was one of several issues identified. Remaining work includes documentation reorganization and deprecated option migration guide. * Fix configuration research document issues Remove deprecated configuration options and update research document Changes: - Remove contextIsolation option from app/config/index.js (lines 185-192) - Remove sandbox option from app/config/index.js (lines 388-395) - Both options were deprecated and never actually used in the code - Users with these in config.json will have them safely ignored (no breaking change) - Reduces total configuration options from 53 to 51 Research document updates: - Mark Problem 3 (deprecated options) as RESOLVED - Update executive summary: 53 → 51 options - Update inventory section to show options as removed - Update Key Finding #3 as resolved - Update Phase 1 deliverables to mark deprecated options as completed - Update Phase 1 roadmap checklist - Update success criteria - Update conclusion and next steps - Reduce remaining Phase 1 effort: 2-4h → 1-2h (MQTT done, deprecated options done) Phase 1 progress: 2 of 3 deliverables complete (MQTT ✅, deprecated options ✅) Remaining: Documentation reorganization (1-2 hours) * Update configuration research to reflect current state and area-by-area approach Corrections based on feedback: 1. Update option count: 53 → 51 active options after deprecation removal 2. Update yargs config block size: ~484 lines → ~395 lines 3. Remove Phase 1 items that are no longer applicable: - "Document deprecated options" (we removed them instead) - "Add migration guide section" (not needed for Phase 1) 4. Simplify Phase 1 to just documentation reorganization 5. Update Phase 2 to reflect incremental area-by-area migration strategy: - Can align with feature work (e.g., notifications refactoring) - Use yargs' built-in deprecated field for user warnings - Auto-migration logic converts old → new structure - Test each area thoroughly before moving to next 6. Update examples to show yargs deprecated field usage This approach is more practical and can be done incrementally as features are refactored, rather than all at once. * Improve config migration approach with dedicated module and auto-fix Update Phase 2 implementation strategy based on feedback: 1. Dedicated Migration Module (app/config/migration.js): - Cleaner architecture - separate migration logic from main config - Easier to maintain and test - Area-specific migration functions (notifications, window, auth) - Clear documentation with JSDoc 2. Auto-Fix Strategy (not just warnings): - Automatically converts old keys to new structure in-memory - Users get informed via console but don't need to do anything - Old config.json remains untouched (no write operations) - Works transparently every app launch 3. Cross-Platform Compatibility: - Works with Vanilla, Snap, and Flatpak installations - In-memory only migration avoids sandbox write permission issues - Config files read from platform-specific locations but migration is universal - Users can migrate to new format at their own pace Benefits: - Zero user action required - migration happens automatically - No breaking changes - old configs keep working - Clean separation of concerns - Testable migration logic - Works across all platforms without special handling * Add optional auto-fix feature to config migration with user consent Extend migration strategy to include optional disk-write capability based on user feedback: New Feature: Auto-Fix Config File - Shows one-time dialog prompting user to update their config.json - Three options: "Update Now", "Keep Current", "Ask Me Later" - Creates backup (config.json.backup) before any changes - Removes old keys and adds new nested structure - Uses marker file (.config-auto-fix-offered) to avoid nagging Benefits: 1. Faster deprecation timeline - users migrate voluntarily 2. Reduced long-term maintenance burden 3. User has full control - explicit opt-in required 4. Safe - automatic backup before changes 5. Works cross-platform - user config dirs are writable in snap/flatpak Accelerated Deprecation Timeline: - v2.x (Phase 2a): Nested options + migration + auto-fix prompt - v2.x+1 (Phase 2b): Deprecate old keys (yargs warnings) - v2.x+2 (Phase 2c): After 6mo, old keys migration-only - v3.0 (Phase 3): Remove old keys completely This allows us to clean up old options much sooner while still providing a smooth migration path for users who prefer manual migration. * Simplify auto-fix dialog to two options: Update Now and Ask Later Removed "Keep Current" option from migration prompt based on feedback: Changes: - Dialog now has only two buttons: "Update Now" and "Ask Me Later" - Removed "Keep Current" option that would permanently decline migration - Users who want to keep in-memory migration can click "Ask Me Later" repeatedly - Simpler UX that gently encourages migration without being pushy - Updated benefits list to reflect new two-option approach Rationale: - Two options are clearer and less overwhelming - Encourages gradual migration without forcing it - Users who truly don't want to migrate will just keep postponing - No permanent "decline" option means more users will eventually migrate * Complete zero-breakage strategy for config migration Updated Implementation Roadmap and Risk Assessment sections to ensure consistency with the automatic migration approach: - Phase 3: Changed from "Breaking Changes" to "Automatic Migration" - Automatic disk-write in v3.0 without user prompt - Migration logic kept indefinitely (only removed in v4.0+ when usage drops) - Updated risk assessment from MEDIUM-HIGH to LOW-MEDIUM - Updated success criteria to focus on automatic migration - Zero breaking changes - all existing configs continue working This completes the comprehensive zero-breakage strategy that ensures no user configurations will ever break, while still achieving a clean config structure for new installations. * Update config research with notification modal changes - Updated option count from 51 to 64 (new customNotification system) - Added finding #3 about conditional options (customNotification only relevant when notificationMethod is "custom") - Updated notification count to 11 options - Added customNotification to good nested objects examples - Referenced PR #1979 for custom notification system This addresses the key insight that not all implementations need all features - some options are only relevant based on other option values. * chore: add changelog entry for PR #1937 * Add future consideration for sensitive data security * Update config research: Graph API, MQTT enhancements, option count - Updated option count from 64 to 65 (new graphApi config) - Added Graph API integration (PR #1958) to recent improvements - Added graphApi to conditional options and good nested objects examples - Referenced new MQTT enhancement research and ADRs (006, 007) - Updated all line counts and totals throughout document The graphApi option follows the same conditional pattern as customNotification - only relevant when enabled, reinforcing finding #3 about not all implementations needing all features. * Add config research to sidebars and update with latest changes - Updated option count from 65 to 66 (new disableBadgeCount option) - Added MQTT commands implementation (PR #1986) to recent improvements - Added disableBadgeCount option (PR #1994) to recent improvements - Added configuration-organization-research to sidebars in alphabetical order - Updated all line counts and option references throughout document The configuration research is now visible in the documentation site's Research & Analysis section alongside other research documents. * Fix broken links in research README Removed references to non-existent files: - documentation-improvement-recommendations.md - ui-system-strategic-analysis.md These files were removed in earlier cleanup but references remained, causing Docusaurus build failures. * Improve configuration research document quality - Add explicit conditional option dependencies (7 items documented) - Clarify 66 option count with detailed breakdown - Separate research findings from implementation status - Add Phase 3 edge cases section (5 scenarios documented) - Standardize checkmark usage ([x] for completed, [ ] for pending) - Move implementation tracking to conclusion section Quality improvements based on documentation review. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]> --------- Co-authored-by: Claude <[email protected]> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements Phase 1 of Microsoft Graph API integration for Teams for Linux, enabling access to Microsoft Graph API endpoints using existing Teams authentication infrastructure.
Key Features
1. Graph API Client Module (app/graphApi/)
2. ReactHandler Token Acquisition
acquireToken()method to ReactHandler3. Configuration Support
graphApiconfiguration option to config system4. IPC Integration
5. Browser Integration
Implementation Details
Usage
Enable in config.json:
{ "graphApi": { "enabled": true } }Then access via IPC from renderer or use GraphApiClient from main process.
Technical Architecture
Testing
Future Enhancements
This implements Phase 1 foundation. Future phases can add:
Addresses issue #1832