- Updated the InitTEDScraper function to return a scheduler instance, allowing for better error handling during initialization.
- Added error logging for failed scheduler initialization and job scheduling, improving robustness.
- Implemented graceful shutdown for the scheduler in the main function, ensuring proper resource management during application termination.
- Removed the entrypoint.sh script from the scraper Dockerfile to streamline the build process.
- Updated the Dockerfile to directly set the ENTRYPOINT to the scraper build executable, simplifying the container startup.
- This change enhances maintainability by reducing the number of files and improving clarity in the Docker configuration.
- Removed command line flag parsing for date range scraping in the scraper's main function.
- Introduced configuration fields for one-time scraping and date range (FromDate, ToDate) in the ScraperConfig struct.
- Updated the main function to utilize the new configuration fields, improving the clarity and maintainability of the scraping logic.
- This change enhances the scraper's functionality by centralizing configuration management and reducing command line complexity.
- Replaced inline entrypoint script creation in the Dockerfile with a separate entrypoint.sh file for better maintainability and clarity.
- The new entrypoint script handles one-time scraping with date range support, improving the scraper's functionality and usability.
- Added an entrypoint script to the scraper Dockerfile to handle one-time scraping with date range support.
- Introduced a new ContentXML field in the Notice entity to store XML content, improving data structure for notices.
- Updated the scraper logic to map XML content to the tender entity, enhancing data processing capabilities.
- Corrected the middleware usage in the CMS routes by ensuring the AuthMiddleware is applied correctly.
- This change enhances the security of the CMS endpoints by enforcing authentication for all CMS-related operations.
- Updated Swagger documentation to include new fields: CompanyName, Country, and Language, improving clarity and usability for API consumers.
- Added a new Type field with enumerations for Company and Organization, enhancing data categorization in the CMS API.
- Reflected changes in the definitions for CMS entities, ensuring accurate representation of the API structure and expected inputs/outputs.
- Improved examples in the documentation to provide better guidance for developers integrating with the CMS API.
- Added new fields to the CMS entity: CompanyName, Country, and Language, enhancing the data structure for better content management.
- Updated the CMSForm to include validation and examples for the new fields, ensuring proper input handling.
- Modified the copyFormToEntity method in the CMS service to map the new fields from the form to the entity, maintaining data integrity.
- Enhanced Swagger documentation to reflect the changes in the CMS API, providing clear examples for the new fields.
- Refactored the NoticeWorker to generate unique tender IDs using the PBL naming convention (SCDYYNNN format) and project names based on client and opportunity details.
- Introduced methods for generating tender IDs and project names, including logic for extracting client and opportunity names, ensuring consistency and clarity in naming.
- Updated the Tender entity to include a new ProjectName field, enhancing the data structure for better project identification.
- Added MongoDB indexing for the new project_name field to optimize query performance.
- Improved error handling and logging during the tender ID generation process, ensuring robustness in the worker's functionality.
- Added command line flags for specifying a date range and a one-time scraping mode in the scraper's main function.
- Implemented validation for the date inputs to ensure both dates are provided and correctly formatted.
- Introduced a new RunOneTimeScraping function to handle the one-time scraping logic, including context management and error handling.
- Updated the TED scraper initialization to support both scheduled and one-time scraping modes, improving flexibility in data retrieval.
- Enhanced logging to provide clear feedback on the scraping process and any errors encountered.
- Updated the worker initialization process to include the new GLM SDK, enhancing the worker's capabilities for translation tasks.
- Modified the InitWorker function and NewNoticeWorker constructor to accept the GLM service, ensuring a cohesive integration.
- Implemented the GLM service initialization and logging for successful setup, improving maintainability and usability.
- Updated the NoticeWorker to utilize the GLM SDK for translating notice titles and descriptions, enhancing functionality and user experience.
- Added a step in the Dockerfile to copy the documentation files from the build stage to the final image.
- This change ensures that the documentation is included in the Docker image, improving accessibility for users and developers.
- Refactored API paths to replace "companies" with "cms" for better alignment with CMS management functionality.
- Updated descriptions, parameters, and responses for CMS-related endpoints to reflect new functionality, including search, create, retrieve, update, and delete operations.
- Enhanced the Swagger documentation to include detailed definitions for CMS entities, forms, and responses, ensuring comprehensive API specifications.
- Improved consistency in naming conventions and descriptions across the CMS API endpoints.
- Introduced a new CMS management feature, including the ability to create, retrieve, update, search, and delete CMS entries.
- Implemented the CMS entity, repository, service, and handler layers following Clean Architecture principles.
- Added API endpoints for CMS operations in Swagger documentation, ensuring comprehensive API specifications.
- Enhanced error handling and validation for CMS data, improving robustness and user experience.
- Updated the main application to initialize the CMS repository and service, integrating them into the existing system.
- Introduced a new contact management feature, including the ability to create, retrieve, search, update, and delete contact messages.
- Implemented the Contact entity, repository, service, and handler layers following Clean Architecture principles.
- Added API endpoints for contact operations in Swagger documentation, ensuring comprehensive API specifications.
- Enhanced error handling and validation for contact data, improving robustness and user experience.
- Updated the main application to initialize the contact repository and service, integrating them into the existing system.
- Removed the Ollama SDK from the worker initialization process, simplifying the worker's dependencies and enhancing maintainability.
- Updated the InitWorker function and NewNoticeWorker constructor to reflect the removal of the Ollama SDK, ensuring a cleaner and more focused implementation.
- Commented out the Ollama model listing logic for potential future use, maintaining clarity in the main function while reducing unnecessary complexity.
- Introduced a new build step in the Drone CI configuration for the worker service, enabling automated Docker image creation.
- Added a Dockerfile for the worker service, defining the build process and dependencies, ensuring a streamlined deployment for background tasks.
- Enhanced the overall CI/CD pipeline to support the new worker service, improving the project's build and deployment capabilities.
- Updated the ToTender method to accept a tender instance, allowing for direct population of tender fields from the notice entity.
- Simplified the tender creation and update process by checking if the tender ID is zero, streamlining the logic for handling tender entities.
- Removed the commented-out code related to AI translation, improving code clarity and maintainability.
- Enhanced error logging for tender creation and update failures, ensuring better visibility into potential issues during processing.
- Added 'image' and 'link' fields to the NotificationRequest and NotificationResponse structures, improving the flexibility of notification content.
- Updated the 'created_at', 'updated_at', and 'schedule_at' fields to use integer types for Unix timestamps, ensuring consistency in time handling.
- Expanded the tender status enumeration to include 'closed', 'modified', 'suspended', and 'published', enhancing the representation of tender states.
- Reflected these changes in the Swagger documentation, ensuring accurate API specifications for clients.
- Introduced AlertMail configuration in both scraper and worker bootstrap files, allowing for customizable email notifications.
- Updated the TED scraper to utilize the AlertMail configuration for sending completion notifications, improving flexibility in notification management.
- Enhanced error logging in the worker's main function to capture issues when listing Ollama models, ensuring better visibility into potential failures.
- Refactored notification sending logic to check for a valid AlertMail before dispatching emails, ensuring notifications are only sent when configured.
- Improved overall structure and readability of the bootstrap configuration files, aligning with best practices for maintainability.
- Introduced a new worker service with a dedicated main entry point for handling background tasks, including MongoDB connection management and notification service initialization.
- Added a bootstrap package to manage application configuration, logging, and service initialization for the worker.
- Implemented a NoticeWorker to process unprocessed notices and create corresponding tender entities, enhancing the integration of notice management within the tender system.
- Refactored the tender service to remove the Ollama SDK dependency, streamlining the service initialization in the main application.
- Enhanced the notice repository with a method to retrieve unprocessed notices, improving data handling capabilities.
- Moved the initialization of the notification service to follow the MongoDB connection setup for better organization.
- Added comments to clarify the initialization sequence of services, including the TED scraper.
- Removed commented-out code related to stopping the scheduler to clean up the main function.
- Enhanced the overall readability and structure of the main application entry point.
- Replaced the tender repository with a new notice repository, encapsulating notice-related data access methods.
- Introduced the Notice entity to represent tender/contract notices, including relevant fields and methods for managing notice data.
- Updated the TED scraper to utilize the new notice repository for creating and managing notices, enhancing the integration with the tender management system.
- Implemented Ollama SDK initialization in the web bootstrap process, allowing for improved AI interactions.
- Enhanced the tender service to include Ollama SDK for additional functionality, ensuring a more robust service layer.
- Introduced a new configuration file for the TED scraper, defining database connection settings, logging preferences, and scraping parameters.
- Implemented a CronScheduler to manage scheduled tasks for TED operations, utilizing the robfig/cron library for scheduling.
- Added new entities and structures for handling TED XML data, including eForms and tender-related information, enhancing the scraper's functionality.
- Updated the main application to initialize the TED scraper with the new configuration and set up graceful shutdown handling.
- Removed the deprecated scraping implementation to streamline the codebase and focus on the new architecture.
- Deleted the TED XML parser and scraper implementation files, including parser.go, scraper.go, and ted.go, to streamline the codebase and eliminate unused components.
- Commented out the initialization code in main.go to prevent execution while maintaining the structure for future reference.
- Removed the README.md for the TED package, which contained documentation for the now-deleted parser and scraper functionalities.
- Changed API title and version in Swagger documentation from "Tender Management API" to "Opplens API" with version 1.0.0.
- Updated contact information and terms of service URLs to reflect the new branding for Opplens.
- Added a new "Notification" tag in the Swagger documentation for public notification management operations.
- Adjusted the Swagger endpoint path for documentation to improve routing consistency.
- Enhanced response structure in notification handlers to include metadata, improving clarity in API responses.
- Introduced a new ValidationService for customer operations to ensure valid username formats.
- Updated customer service and handler to utilize the new validation service, enhancing input validation during registration and updates.
- Modified CreateCustomerForm and UpdateCustomerForm to enforce username validation rules.
- Adjusted repository indexing to improve search efficiency by refining the text index for customer data.
- Ensured consistent handling of usernames across the customer module, improving overall data integrity and user experience.
- Updated feedback repository and service methods to use a consistent naming convention, changing `NewTenderRepository` and similar methods to `NewRepository`.
- Refactored feedback handler methods to improve clarity by renaming methods such as `ListFeedback` to `Search` and `GetFeedback` to `Get`.
- Enhanced feedback response structures to include detailed company and tender information, improving the clarity of feedback data returned to API consumers.
- Updated Swagger documentation to reflect changes in feedback response structures and endpoint paths, ensuring accurate representation of the API for consumers.
- Modified the route for marking notifications as seen to ensure a consistent and clear API structure.
- Updated the notification client to reflect the new endpoint path for marking all notifications as seen, enhancing clarity for API consumers.
- These changes improve the overall usability and maintainability of the notification API.
- Changed the endpoint for marking notifications as seen to improve clarity and consistency in the API structure.
- Updated the endpoint for marking all notifications as seen to a more descriptive path.
- Reflected these changes in the Swagger documentation, ensuring accurate representation of the updated API endpoints for consumers.
- Updated the notification routes to enhance clarity and usability by changing the endpoint for marking notifications as seen.
- Introduced a new route for marking all notifications as seen, improving the API's functionality and user experience.
- Updated Swagger documentation to reflect the changes in endpoint paths, ensuring accurate API documentation for consumers.
- Updated the CORS middleware configuration in the HTTP server initialization to include additional allowed headers: Origin, Content-Type, Accept, and Authorization.
- This enhancement improves the flexibility and security of cross-origin requests, ensuring that necessary headers are accepted for proper API functionality.
- Introduced new query parameters for filtering notifications by 'seen' status and 'priority' in the API documentation, enhancing the flexibility of notification retrieval.
- Added a new endpoint to mark all notifications as seen for a user, including detailed Swagger documentation for the new functionality.
- Updated existing API documentation to reflect the changes, ensuring clarity for API consumers and improving overall documentation quality.
- Updated the InquiryService to include a notification SDK for sending notifications upon inquiry creation, enhancing user engagement.
- Modified the NewInquiryService constructor to accept the notification SDK as a dependency, adhering to dependency injection principles.
- Refactored the Create method to send notifications with inquiry details, improving communication and response to inquiries.
- Cleaned up commented-out code related to duplicate inquiry checks for better readability and maintainability.
- Added new endpoints for marking notifications as seen and retrieving detailed notification information for both admin and user contexts, improving the flexibility of the notification system.
- Implemented the MarkSeen and ViewNotification methods in the NotificationHandler, ensuring proper handling of notification visibility and details retrieval.
- Updated the NotificationService interface to include methods for getting notification details and marking notifications as seen, enhancing service capabilities.
- Enhanced the notification response structures to include additional fields such as Image, Seen, and ScheduledAt, providing richer data in API responses.
- Updated API documentation with Swagger comments for the new endpoints and response formats, ensuring clarity for API consumers.
- Added new endpoints for retrieving notifications for both admins and users, improving the flexibility of the notification system.
- Implemented query parameters for filtering notifications by status, method, event type, type, and recipient, enhancing usability.
- Introduced new response structures for notifications, including pagination information, to provide better data handling in API responses.
- Updated API documentation with Swagger comments for the new endpoints and response formats, ensuring clarity for API consumers.
- Refactored notification handling logic to support the new features, promoting a more robust notification management system.
- Updated the notification handling logic to utilize a new SDK for sending notifications, improving the flexibility and scalability of the notification system.
- Introduced new methods in the notification service for sending notifications to users and customers based on various target audience types, enhancing the notification delivery capabilities.
- Added a new endpoint to assign companies to a customer, improving customer management functionalities.
- Refactored the customer entity and forms to replace 'CompanyIDs' with 'Companies', ensuring consistency across the data model.
- Enhanced API documentation with Swagger comments for the new endpoint and updated notification structures, ensuring clarity for API consumers.
- Introduced a new endpoint to assign companies to a customer, enhancing the customer management capabilities.
- Implemented the AssignCompanies handler in the customer service layer, including validation and structured responses.
- Updated the routes to include the new PATCH /admin/v1/customers/{id}/companies endpoint, improving administrative functionalities.
- Enhanced API documentation with Swagger comments for the new endpoint, ensuring clarity for API consumers.
- Introduced a new DeviceToken field in both Customer and User entities to store device tokens for authentication and notifications.
- Updated LoginForm structures for both Customer and User to include an optional DeviceToken field, allowing clients to send device tokens during login.
- Enhanced the Login methods in the customer and user services to append the device token to the respective entities if it does not already exist, improving user session management and notification capabilities.
- Ensured proper validation and structured responses for the new DeviceToken field in the forms, maintaining compliance with best practices for API design.
- Added "target" field reference to the notification request and response structures in Swagger documentation, improving clarity for API consumers.
- Introduced "notification.TargetAudienceType" definition with enumerated values for target audience options, enhancing the API's usability and understanding.
- Updated related documentation files (YAML and JSON) to reflect these changes, ensuring consistency across all API documentation formats.
Nima Nakhostin