@cplace/test-mcp-server 1.0.0 → 1.1.0

package/dist/widget-specifications/_research_from_ga_products/cf-cplace-rest-config-widget-productionModeHintWidget/research.md

@@ -0,0 +1,332 @@
+# Widget Research: cf.cplace.rest.config.widget.productionModeHintWidget
+
+## Widget Identity
+
+- **Widget ID:** `cf.cplace.rest.config.widget.productionModeHintWidget`
+- **Repository:** cplace-rest
+- **Definition Class:** `cf.cplace.rest.config.widget.ProductionModeHintWidgetDefinition`
+- **Location:** `cf.cplace.rest.config/src/main/java/cf/cplace/rest/config/widget/ProductionModeHintWidgetDefinition.java`
+
+## Summary Description
+
+The Production Mode Hint widget displays warnings and notifications to administrators about REST API configuration settings that should be reviewed or modified when running cplace in production mode, helping ensure secure and optimized REST API deployments.
+
+## Purpose & Core Functionality
+
+This widget serves as a **configuration safety assistant** for REST API settings. Based on common patterns in application platforms, it likely:
+
+1. **Detects environment mode**: Identifies when the cplace platform is running in production mode versus development mode
+2. **Displays configuration warnings**: Shows alerts about REST API settings that are inappropriate for production environments
+3. **Provides guidance**: Offers recommendations on what should be changed or reviewed
+4. **Enhances security**: Helps prevent common security issues from development settings being carried over to production
+5. **Improves performance**: Alerts administrators to performance-impacting configurations
+
+## Context: Development vs. Production Mode
+
+### What is Production Mode?
+
+In application platforms, production mode is an operational state where:
+
+- **Performance is optimized**: Applications consume minimal memory and start quickly
+- **Security is tightened**: Development-only features are disabled
+- **Debugging is limited**: Verbose logging and development tools are turned off
+- **Configuration is hardened**: Database connections, API keys, and other sensitive settings use production values
+
+### Common Production Mode Concerns
+
+Development environments typically include features that should be disabled in production:
+
+1. **Debug Information**: Detailed error messages and stack traces that could expose system internals
+2. **Development Tools**: Admin UIs and diagnostic endpoints (e.g., `/dev-ui` in Quarkus)
+3. **Verbose Logging**: Excessive logging that impacts performance and disk space
+4. **Permissive Security**: Relaxed CORS policies, authentication bypasses, or test credentials
+5. **Hot Reload**: Live-reload capabilities that consume resources
+6. **Sample Data**: Test accounts, demo content, or development keys
+
+### REST API Specific Concerns
+
+For REST APIs specifically, production configurations often differ in:
+
+- **Authentication/Authorization**: Strict token validation, proper credential management
+- **Rate Limiting**: Throttling to prevent abuse
+- **CORS Policies**: Restrictive cross-origin resource sharing rules
+- **SSL/TLS**: Enforced HTTPS with valid certificates
+- **Error Responses**: Sanitized error messages without internal details
+- **Caching**: Production-grade caching strategies
+- **Connection Pools**: Optimized database connection settings
+- **API Documentation**: Public-facing API docs may be disabled or restricted
+
+## Use Cases
+
+### Primary Use Case: Production Environment Validation
+
+**When to use:** During or after deployment to a production environment, or when preparing to transition from development to production.
+
+**Workflow:**
+1. Administrator deploys cplace to a production environment
+2. Platform detects it's running in production mode
+3. Production Mode Hint widget appears on REST API configuration pages
+4. Widget displays warnings about potentially problematic settings
+5. Administrator reviews each warning
+6. Administrator updates configurations to production-appropriate values
+7. Widget confirms when all critical issues are addressed
+
+### Specific Scenarios
+
+1. **Initial Production Deployment**: First-time setup of cplace in a production environment
+   - Validates that development settings haven't been accidentally carried over
+   - Ensures security best practices are followed from day one
+
+2. **Development-to-Production Migration**: Transitioning an instance from development to production
+   - Highlights configurations that need updating when changing modes
+   - Prevents common oversight errors during environment promotion
+
+3. **Security Audit**: Regular review of production configurations
+   - Provides a checklist of security-critical REST API settings
+   - Helps maintain compliance with security policies
+
+4. **Performance Optimization**: Identifying settings that impact production performance
+   - Points out verbose logging or inefficient caching configurations
+   - Suggests production-optimized settings
+
+5. **Multi-Environment Management**: Managing multiple cplace instances
+   - Quick visual indicator of which environments are production-ready
+   - Helps administrators track configuration drift across environments
+
+### Typical Warning Examples
+
+Based on common production mode patterns, this widget likely warns about:
+
+- **Development API Keys**: Test or demo API credentials still in use
+- **Debug Mode Enabled**: REST API running with debug logging or detailed error responses
+- **Permissive CORS**: Allow-all CORS policies that should be restricted
+- **Insecure Connections**: HTTP instead of HTTPS for API endpoints
+- **No Rate Limiting**: Missing throttling or request limiting configurations
+- **Default Credentials**: Unchanged default passwords or tokens
+- **Verbose Error Messages**: Stack traces being sent to API consumers
+- **Test Endpoints**: Development-only REST endpoints still accessible
+
+## Configuration Options
+
+### Widget Attributes
+
+Given its role as an information/warning widget, it likely has minimal configuration:
+
+| Option | Type | Description |
+|--------|------|-------------|
+| `height` | Number | Display height (inherited from base widget mixins) |
+| `checkSeverity` | Enum | Level of warnings to display (e.g., critical, warning, info) |
+| `autoRefresh` | Boolean | Whether to automatically re-check when settings change |
+
+### Embedding Context
+
+The widget is likely embeddable on:
+
+- **REST API Configuration pages**: Primary location for REST endpoint setup
+- **System Administration dashboards**: Overview of system health and configuration
+- **Deployment/Environment pages**: Pages showing environment-specific settings
+
+### Display Modes
+
+Potential display modes based on status:
+
+1. **No Issues**: Green checkmark or "Production Ready" message
+2. **Warnings Present**: Yellow alert with expandable list of warnings
+3. **Critical Issues**: Red alert highlighting security or stability risks
+4. **Mixed State**: Grouped warnings by severity level
+
+## Relationship to Other Components
+
+### cplace REST API System
+
+The Production Mode Hint widget is part of the **cplace-rest** repository, which provides:
+
+- **REST API Configuration**: No-code/low-code REST endpoint creation
+- **API Documentation**: Auto-generated API documentation
+- **Authentication**: Token-based authentication for REST APIs
+- **Permission Management**: Integration with cplace's permission system
+- **Data Access**: Reading and writing cplace data via REST endpoints
+
+### Related Configuration Areas
+
+| Component | Relationship |
+|-----------|--------------|
+| **REST Endpoint Configuration** | Widget validates settings for configured endpoints |
+| **Authentication Settings** | Checks for production-appropriate auth configurations |
+| **Permission Policies** | Ensures REST APIs respect cplace permission model |
+| **SCIM Integration** | Validates cross-domain identity management settings |
+| **API Rate Limiting** | Warns if rate limiting is insufficient for production |
+| **Logging Configuration** | Checks for overly verbose logging |
+
+### Integration with cplace Platform
+
+The widget integrates with:
+
+- **Environment Detection**: Reads system property or configuration to detect production mode
+- **Configuration Validation**: Queries REST API configurations against production best practices
+- **Localization System**: Provides warning messages in multiple languages
+- **Permission System**: Only visible to administrators with configuration rights
+
+## Technical Architecture
+
+### Backend Components
+
+**Widget Definition Class**: `ProductionModeHintWidgetDefinition.java`
+- Defines widget metadata and embedding rules
+- Likely restricted to administrator users
+- May query system properties and REST API configurations
+
+**Configuration Checker**: Validation logic that compares current settings against production requirements
+- Reads REST API endpoint configurations
+- Compares against security and performance best practices
+- Generates list of warnings with severity levels
+
+**Settings Provider**: Component that identifies what constitutes production mode
+- Reads environment variables or system properties
+- Determines if platform is running in production mode
+- May check deployment type (cloud, on-premise, etc.)
+
+### Frontend Components
+
+**Display Component**: Renders warnings in user-friendly format
+- Color-coded severity indicators
+- Expandable/collapsible warning sections
+- Links to relevant configuration pages
+- "Acknowledge" or "Dismiss" actions for warnings
+
+**Localization**: Multi-language support
+- English and German message translations at minimum
+- Context-sensitive help text
+- Links to documentation
+
+## Best Practices for Use
+
+### For Administrators
+
+1. **Review on Every Deployment**: Check the widget after any production deployment
+2. **Address Critical Warnings First**: Prioritize security and stability issues
+3. **Document Exceptions**: If warnings can't be addressed, document why
+4. **Regular Audits**: Periodically review even if no changes were made
+5. **Update After Configuration Changes**: Re-check when modifying REST API settings
+
+### For Platform Managers
+
+1. **Include in Deployment Checklist**: Make reviewing this widget part of deployment procedures
+2. **Monitor Configuration Drift**: Use widget as indicator of unintended changes
+3. **Security Compliance**: Reference widget warnings in security audits
+4. **Training**: Educate administrators on interpreting and addressing warnings
+
+### When to Ignore Warnings
+
+Not all warnings may apply to every environment:
+
+- **Internal Networks**: Some security warnings may be less critical for internal-only APIs
+- **Controlled Environments**: Restricted production environments may allow certain development features
+- **Custom Configurations**: Specific business requirements may necessitate non-standard settings
+- **Legacy Integrations**: Existing integrations may require maintaining certain settings
+
+## Comparison with Similar Widgets
+
+### Production Mode Hint vs. Standard Alert Widgets
+
+| Aspect | Production Mode Hint | Generic Alert Widget |
+|--------|---------------------|---------------------|
+| **Context** | REST API configuration specific | General purpose |
+| **Triggers** | Environment mode + configuration state | Manual or event-based |
+| **Validation** | Automated checks against best practices | User-defined conditions |
+| **Audience** | Administrators and DevOps | Varies by use case |
+| **Lifecycle** | Always present in production | May be temporary |
+
+## Key Considerations
+
+### Security Implications
+
+This widget plays a critical role in:
+
+- **Preventing Data Breaches**: Ensures API authentication is properly configured
+- **Maintaining Compliance**: Helps meet security audit requirements
+- **Reducing Attack Surface**: Identifies exposed development endpoints
+- **Protecting Credentials**: Warns about test credentials in production
+
+### Performance Impact
+
+The widget helps optimize:
+
+- **Response Times**: Identifies inefficient configurations
+- **Resource Usage**: Warns about memory or CPU-intensive settings
+- **Scalability**: Ensures production-appropriate connection pooling
+- **Monitoring**: Validates that logging doesn't overwhelm systems
+
+### Operational Benefits
+
+- **Reduced Downtime**: Catches misconfigurations before they cause issues
+- **Faster Troubleshooting**: Provides clear guidance on what needs fixing
+- **Knowledge Transfer**: Helps less experienced administrators learn production best practices
+- **Audit Trail**: Documents configuration state at deployment time
+
+## Limitations and Constraints
+
+### What the Widget Likely Does NOT Do
+
+1. **Auto-Fix Issues**: Displays warnings but doesn't automatically change configurations
+2. **Block Deployment**: Warnings are informational, not enforcement mechanisms
+3. **External Validation**: Only checks cplace configurations, not network or infrastructure
+4. **Real-Time Monitoring**: Static configuration check, not runtime performance monitoring
+5. **Custom Rule Definition**: Uses predefined checks rather than user-configurable rules
+
+### Known Constraints
+
+- **Administrator Only**: Likely visible only to users with administrative permissions
+- **Production Mode Dependency**: May not display anything in development mode
+- **Configuration Scope**: Limited to REST API configurations, not entire platform
+- **Language Support**: Warning messages limited to supported localization languages
+
+## Research Sources
+
+This research document is based on:
+
+1. **Widget Identification**: Analysis of widget registry and repository mapping
+2. **Production Mode Concepts**: General application platform patterns for development vs. production configurations
+3. **REST API Security**: Common security and configuration concerns for production REST APIs
+4. **cplace Platform Context**: Understanding of cplace's architecture and REST API capabilities
+
+### External References
+
+- [OutSystems Development vs Production Modes](https://success.outsystems.com/documentation/10/managing_the_applications_lifecycle/outsystems_running_modes_development_vs_production_mode/)
+- [Expo Development and Production Modes](https://docs.expo.dev/workflow/development-mode/)
+- [Microsoft ASP.NET Configuration Differences](https://learn.microsoft.com/en-us/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/common-configuration-differences-between-development-and-production-cs)
+- [Quarkus Dev Mode Differences](https://quarkus.io/guides/dev-mode-differences)
+- [Node.js Production vs Development](https://nodejs.org/en/learn/getting-started/nodejs-the-difference-between-development-and-production)
+- [cplace Technical Integrations](https://www.cplace.com/en/product/integrations/)
+- [cplace REST API Roadmap](https://roadmap.cplace.io/c/48-rest-api)
+- [cplace No-Code REST API](https://roadmap.cplace.io/c/160-no-code-rest-api-reading-data)
+
+## Summary
+
+The Production Mode Hint widget is a specialized configuration assistant that:
+
+- **Validates REST API configurations** against production environment best practices
+- **Displays warnings and recommendations** to administrators
+- **Enhances security** by catching common misconfigurations
+- **Improves performance** by identifying inefficient settings
+- **Supports operational excellence** through clear guidance and audit capabilities
+- **Serves as a safety net** during environment transitions and deployments
+
+This widget is essential for maintaining secure, performant, and reliable REST API configurations in production cplace environments. It embodies the platform's commitment to enabling both technical and non-technical users to successfully manage complex integration scenarios while maintaining enterprise-grade quality and security standards.
+
+## Notes and Limitations
+
+**Important:** This research document is based on inference from the widget's name, location in the cplace-rest repository, and general software engineering patterns. The actual implementation may differ from these predictions. For definitive information about:
+
+- Specific configuration checks performed
+- Exact warning messages and thresholds
+- Widget attributes and embedding rules
+- Frontend implementation details
+- Backend validation logic
+
+Consult the actual source code at:
+- `cf.cplace.rest.config/src/main/java/cf/cplace/rest/config/widget/ProductionModeHintWidgetDefinition.java`
+- Associated frontend assets in the cplace-rest repository
+- cplace REST API documentation
+
+This research provides a conceptual framework and likely use cases, but should be validated against the actual implementation for accuracy.

package/dist/widget-specifications/_research_from_ga_products/cf-cplace-simpleCalendar-calendar/research.md

@@ -0,0 +1,284 @@
+# Widget Research: cf.cplace.simpleCalendar.calendar
+
+## Widget Description
+
+The **Calendar Widget** displays events from configured cplace types in an interactive calendar view, allowing users to visualize and manage time-based data across different time scales (month, week, day, or year list views).
+
+## Purpose
+
+This widget transforms any cplace type into calendar events by mapping date attributes to visual calendar entries. It provides a unified calendar view for displaying multiple event types from one or more spaces, with support for event categorization through event classes, color-coding, and interactive filtering.
+
+## Core Functionality
+
+### Event Type Configuration System
+
+The calendar operates on an **Event Type Configuration** model where:
+
+1. **Event Types** define which cplace types should be displayed as calendar events
+   - Maps a cplace type to calendar events
+   - Specifies which attributes represent start and end dates
+   - Defines default color for the event type
+   - Supports custom display name patterns for event titles
+   - Has an order property for consistent display across the system
+
+2. **Event Classes** provide fine-grained categorization within an event type
+   - Subdivide events based on attribute values (e.g., status, priority, category)
+   - Define conditional logic: if attribute X equals value Y, apply this event class
+   - Each event class has its own display name and color
+   - Only the first matching event class is applied per event
+   - Falls back to the event type's color if no event class matches
+
+### Configuration Storage
+
+Event type configurations are stored as pages in each space:
+- Type: `cf.cplace.simpleCalendar.eventTypeConfiguration`
+- Contains: event type name, start/end date attributes, color, display pattern, order
+- References: event class configuration pages
+- Can be exported/imported as XML for reuse across spaces
+
+### Calendar Views
+
+The widget supports four calendar view modes:
+- **Month View** (default): Traditional monthly calendar grid
+- **Week View**: Weekly schedule view
+- **Day View**: Single day detailed view
+- **List Year View**: Linear list of all events in a year
+
+## Use Cases
+
+### 1. Project Timeline Visualization
+Display project milestones, tasks, or phases in a calendar view to understand temporal distribution and scheduling conflicts.
+
+**Example Configuration:**
+- Event Type: Project Milestone
+- Start Date: Milestone Date
+- Event Classes: By Status (Planned, In Progress, Completed)
+- Use Case: PMO dashboard showing all project milestones across multiple projects
+
+### 2. Resource Scheduling
+Track resource availability, bookings, or absences across team members or physical resources.
+
+**Example Configuration:**
+- Event Type: Absence/Leave
+- Start Date: Leave Start
+- End Date: Leave End
+- Event Classes: By Type (Vacation, Sick Leave, Training)
+- Use Case: HR dashboard for team absence planning
+
+### 3. Multi-Type Event Aggregation
+Combine different event types into a single calendar view to see the complete picture.
+
+**Example Configuration:**
+- Multiple Event Types: Meetings, Deadlines, Releases
+- Each with distinct colors and configurations
+- Use Case: Executive dashboard showing all important dates across different categories
+
+### 4. Compliance and Deadline Tracking
+Monitor regulatory deadlines, audit dates, or compliance milestones.
+
+**Example Configuration:**
+- Event Type: Compliance Deadline
+- Start Date: Due Date
+- Event Classes: By Priority or Regulatory Body
+- Use Case: Legal/Compliance team tracking dashboard
+
+### 5. Event Management
+Display and manage actual events like conferences, workshops, or company events.
+
+**Example Configuration:**
+- Event Type: Company Event
+- Start Date: Event Start
+- End Date: Event End
+- Event Classes: By Event Category (Conference, Training, Social)
+- Use Case: Corporate events calendar
+
+## Configuration Concepts
+
+### High-Level Configuration Options
+
+#### 1. Title and Frame
+- **Widget Title**: Custom localized title for the widget
+- **Show Frame**: Toggle widget frame visibility
+
+#### 2. Event Selection
+Two approaches for defining which events to display:
+
+**Option A: Search-Based**
+- **Search for Events**: Define a search query to filter events
+- Provides fine-grained control over which pages appear
+- Must specify the embedding space as the search space
+- Validates that searched types are configured as event types
+
+**Option B: Type-Based**
+- **Shown Types**: Select which event types to display
+- Used only when "Search for Events" is empty
+- Empty selection shows all available types in the space
+- Simpler configuration for straightforward use cases
+
+#### 3. View Configuration
+- **Default View**: Starting view when widget loads (month/week/day/list)
+- **Fixed Height**: Optional pixel height for calendar content area
+
+#### 4. Interactive Features
+
+**Year Selector**
+- **Show Year Selector**: Toggle year selection control
+- Automatically determines year span from available events
+- Only shown if multiple years are available
+- Provides slider for quick year navigation
+
+**Event Creation Actions**
+- **Show Actions**: Enable "Create New" buttons for event types
+- Displays action buttons to create events from within the calendar
+- Generates buttons based on event type configurations and user permissions
+- Adapts to show dropdown if multiple types, single button if only one
+
+**Event Class Filtering**
+- **Show Event Class Selector**: Toggle event class filter buttons
+- Displays buttons for each event class with:
+  - Color-coded visual indicator
+  - Event class name
+  - Count of events in that class
+- Users can click to show/hide events by class
+- Helps manage visual complexity in crowded calendars
+
+#### 5. Event Interaction
+- **Enable Event Links**: Control whether clicking events navigates to the page
+- When enabled, events link to their corresponding cplace pages
+
+### Space and App Architecture
+
+#### cplace Calendar App
+The widget requires the "cplace Calendar" app to be installed in spaces where events are configured:
+- App provides event type and event class configuration types
+- Manages configuration validation
+- Handles configuration import/export
+- Supports rolling out configurations to multiple spaces
+
+#### Multi-Space Support
+The calendar can aggregate events from multiple spaces:
+- If no search is defined, displays events from all spaces with the Calendar App
+- Search can specify multiple spaces
+- Event type configurations are space-specific
+- Each space maintains its own configuration
+
+### Validation and Error Handling
+
+The widget performs comprehensive validation:
+- **Configuration Validation**: Ensures event type configurations are complete
+  - Start date attribute is required
+  - Referenced attributes must exist
+  - Types in search must be configured as event types
+- **Error Display**: Shows configuration errors with helpful icons and messages
+- **Graceful Degradation**: Widget shows errors but doesn't break the page
+
+### Technical Integration
+
+#### Frontend (AngularJS)
+- Uses FullCalendar library for calendar rendering
+- State management for year selection and event class visibility
+- Dynamic event loading from backend handler
+- Responsive rendering on widget resize
+
+#### Backend (Java)
+- `SimpleCalendarWidgetDefinition`: Widget registration and configuration
+- `EventsHandler`: Loads and transforms page data into calendar events
+- `SimpleCalendarConfiguration`: Manages event type configurations
+- `EventTypeConfiguration`: Models event type and event class definitions
+- Caching mechanism for configuration data to optimize performance
+
+#### Event Loading
+Events are loaded dynamically based on:
+- Current calendar view date range (month/week/day)
+- Configured search or event types
+- Event type configurations with date attribute mappings
+- User access permissions (respects cplace's access control)
+
+### Display Name Pattern
+
+Event types can define custom display name patterns:
+- Uses attribute interpretation patterns (e.g., `$attributeName$`)
+- Special token `$name$` for the page name
+- Fallback to page name if pattern evaluation fails
+- Example: `$priority$ - $name$` → "High - Release Planning Meeting"
+
+### Event Classes vs. Event Types
+
+**Event Type**:
+- Represents which cplace type is an event
+- Maps attributes to start/end dates
+- Defines default color and display pattern
+- One event type per cplace type
+
+**Event Class**:
+- Subdivides events within an event type
+- Conditional based on attribute values
+- Provides alternative color and display name
+- Multiple event classes per event type
+- First matching class wins
+- Enables richer categorization without creating multiple types
+
+### Color Configuration
+
+Color hierarchy:
+1. Event Class Color (if class matches and has color)
+2. Event Type Color (if no class or class has no color)
+3. Default Color (`#00519e` - cplace blue)
+
+Legacy support for domain-based color maps (backwards compatibility).
+
+## Related Widgets and Features
+
+### Widget Ecosystem
+- Complements table and list widgets for time-based data
+- Can be combined with search widgets for filtering
+- Often used alongside dashboard widgets for overview pages
+
+### App Configuration Pages
+- Event Type Configuration pages (created in spaces)
+- Event Class Configuration pages (nested in event types)
+- Configuration import/export functionality
+- Propagation tools for rolling out configurations
+
+## Prerequisites and Dependencies
+
+### Required
+- cplace Calendar App must be installed in target space(s)
+- At least one event type configuration must be defined
+- Configured event types must have date attributes
+
+### Optional
+- Event class configurations for categorization
+- Custom display name patterns for event titles
+- Search configuration for filtered event display
+
+## Key Implementation Notes
+
+### Performance Considerations
+- Configuration is cached globally per space
+- Bulk operations suppress cache refresh during imports
+- Events loaded dynamically for visible date range only
+- FullCalendar handles rendering optimization
+
+### Migration Support
+- Attribute name migration for widget search configurations
+- Backwards compatibility for legacy domain color definitions
+- Configuration validation during widget rendering
+
+### Localization
+- Widget title supports localized strings
+- Event type and event class names are localized
+- Calendar UI adapts to current user language
+- Week numbers and date formats respect locale
+
+## Summary
+
+The Calendar Widget is a sophisticated visualization tool that transforms cplace data into interactive calendar views. Its strength lies in:
+
+1. **Flexible Configuration**: Support for multiple event types and classes
+2. **Space Aggregation**: Can combine events from multiple spaces
+3. **Interactive Filtering**: Year selection and event class toggling
+4. **User Actions**: Create events directly from calendar
+5. **Extensive Customization**: Colors, patterns, views, and display options
+
+The widget is ideal for any scenario requiring temporal visualization of cplace data, from project management to resource scheduling to compliance tracking.