Update ReturnReceiptValuesSchema to accept category as a direct property
instead of nested in receiptItem.data.features. Simplifies the schema by
removing the unnecessary ReceiptItemDataSchema and modifying how the
category is accessed in completeReturnProcess.
Ref: #5083
Harmonize electronic device and nonbook item condition labels to consistently
use "Geöffnet/Defekt" instead of "Geöffnet/Beschädigt" or "Beschädigt/Fehldruck".
Also remove redundant defect verification question for electronic devices since
the condition label already indicates this state.
Additionally, add product features to receipt item data in return receipts to
ensure proper product information is available for returns processing.
Ref: #5083
Replace separate type extension with direct schema definition by adding
otherProduct field to the ReturnReceiptValuesSchema. This eliminates
redundant type definition and improves type safety by ensuring all
fields are properly validated through the Zod schema.
Ref: #5082
Simplify the task list filter logic by using a cleaner object literal approach
instead of nested properties. This improves readability and maintainability of
the filtering conditions.
Ref: #5072
This commit makes several important changes to ensure only eligible items
are processed during return submission:
1. ReturnProcessService now filters out ineligible items before submission
2. Fixed canContinueToSummary logic to check if ANY item is eligible (not ALL)
3. Added conditional rendering to return-summary-item to display error state
for ineligible items
These changes prevent system errors when attempting to process returns
that don't meet eligibility criteria while still allowing partial returns
when at least one item is eligible.
Ref: #5084
Enhance the ReturnProcessProductQuestion component with better error handling:
- Add proper display of "no product found" message when search returns no results
- Add validation feedback for invalid EAN inputs
- Refactor status handling from a simple boolean to a more descriptive object
- Remove unnecessary complete handler in favor of explicit state management
Ref: #4979
Add new helper function isElektronischeGeraeteEligibleForReturn to determine
if electronic devices are eligible for returns based on item condition and
receipt date. Update ReturnProcessService to use this helper for electronic
device category.
This implementation checks if devices in original packaging with receipts
older than 100 days are not eligible for return.
Ref: #4978
Replace direct Boolean() casting with Angular's coerceBooleanProperty to ensure consistent
boolean type coercion when determining if items can be returned. This improves type safety
and provides more predictable behavior for string-based boolean values in item actions.
Ref: #5067
Add support for filter parameters when querying receipt item tasks, allowing
for more refined control over which tasks are displayed. Update the service,
store, and component to use this filtering capability.
- Modify ReturnTaskListService to accept queryToken parameter
- Update ReturnTaskListStore to pass the queryToken to the service
- Enhance ReturnTaskListComponent to construct appropriate filter based on appearance
- Fix spelling of "Non-Book" in ProductCategory constant
Ref: #5072
Add helper functions to determine product return eligibility based on item condition
and defect status. Specifically implemented return logic for TonDatentraeger products
where damaged but non-defective items aren't eligible for return. Also added export
for the eligibility helper in the index file.
Update the ReturnProcessComponent to check eligibility status before allowing
continuation to summary, ensuring only eligible items proceed in the return workflow.
Ref: #5075
Add support for 'unknown' product category state in ReturnProcessService
and ReturnProcessQuestionsComponent to ensure proper handling of return
processes without a defined product category. This correctly returns
EligibleForReturnState.Unknown and displays the product category dropdown
when needed.
Ref: #5073#4943
Update ReturnProcessQuestionSchema for DeliveredItem to make contributors,
format, formatDetail, volume, and manufacturer fields optional instead of
required. This ensures compatibility with the actual data structure received
from the API and prevents validation errors for incomplete product data.
Ref: #5068
- Filter completed tasks to show only those completed today in review view
- Sort task list to show open tasks before completed tasks
- Add date-fns functions (isSameDay, parseISO) to handle date comparison
- Refactor filtering logic for better readability and maintainability
Ref: #4942
Extracted common name formatting code into a reusable utility function to ensure
consistent display of customer/organization names across return feature components.
This improves maintainability and ensures consistent presentation throughout the
application.
Ref: #5066
Make the catalogProductNumber field optional in the ReturnProcessQuestionSchema for DeliveredItem
to match actual API response data structure and prevent validation errors when processing items
without this field.
Ref: #5068
Rename and refactor return review components to task list throughout the codebase:
- Rename ReturnReviewService to ReturnTaskListService with improved error handling
- Rename ReturnReviewStore to ReturnTaskListStore and add logging
- Update TaskActionType interface with new updateTo and actions properties
- Enhance ReturnTaskListItemComponent to support dynamic task actions
- Update templates to use new action structure and naming
The refactoring improves code organization and readability while enhancing the
task list functionality with better action handling and error management.
Ref: #4942#4973
Add dialog component to warn users when they attempt to leave the return review
process with uncompleted tasks. This includes:
- Creating UncompletedTasksDialogComponent with confirmation/cancellation options
- Implementing CanDeactivate guard to check for uncompleted tasks
- Adding guard to return review routes configuration
The dialog gives users the choice to either go back and complete tasks or
leave despite having uncompleted tasks.
Ref: #4976
Enhance the ReturnTaskListComponent and ReturnTaskListItemComponent to:
- Use properly typed TaskActionTypes enum (OK, NOK, PRINT, UNKNOWN) instead of string literals
- Add specialized UI components for different action types
- Implement conditional rendering for task actions based on type
- Improve styling for different task types
- Filter out completed tasks in main view
feat(oms-data-access): add Zod schema validation for return receipts
- Add ReturnReceiptValuesSchema for validation of API payloads
- Implement proper type safety for task action types
- Use schema validation in ReturnProcessService before API calls
Ref: #4942
Implement new shared task list component to replace duplicate task list functionality across the application.
Update return review and search views to use the new shared component.
- Create new @isa/oms/shared/task-list library
- Extract task list functionality from return review component
- Add task list to return search main view
- Handle task completion actions through the shared component
- Fix typo in return review success message
Ref: #4942, #4972, #4974
Added updateTaskListItem method to ReturnReviewStore to handle updating
individual task list items. Implemented the UI logic to show/hide the
"Mark as done" button based on completion status and connected the
completeTask method to update the store with the returned result.
Ref: #4942
Add new ReturnReview library with core components and service structure:
- Create ReturnReviewService and ReturnReviewStore for task management
- Extract PrintReceipts functionality into dedicated service
- Implement review page components with task listing and completion
- Add support for receipt item tasks data model
- Update error handling with consistent error types
- Add comprehensive JSDoc documentation throughout
The implementation provides the foundation for the return review workflow,
including task listing and completion functionality.
Ref: #4942
Add receipt item task-related models and interfaces to support return review
functionality. Add new fields to ReceiptDTO and update ReturnProcessService
Includes:
- New task list models for receipt items
- Receipt service endpoint updates
- Field additions to ReceiptDTO model
Ref: #4942
Initialize the return-review feature library with basic component structure
and connect it to the existing routing system in both return-process and
return-summary features. Update navigation in ReturnSummaryComponent to
redirect to the review page after successful return completion.
Ref: #4942
- Added a pretest script to clean up test results using trash-cli.
- Updated @angular-devkit/build-angular from 19.2.6 to ^19.2.9.
- Updated @nx/angular from 20.4.6 to ^20.8.1.
Replace function declarations with arrow function expressions assigned to constants
for better testability when mocking functions during unit tests.
This makes the codebase more consistent and addresses issues with function mocking.
- 🛠️ **Refactor**: Changed npm install command in Dockerfile for better script handling
- 🗑️ **Chore**: Removed junit.xml from repository
- 🎨 **Style**: Added junit.xml to .gitignore for cleaner project structure
- 🎨 **Style**: Ensured newline at end of file in .gitignore
- ⚙️ **Config**: Modified CI command to include coverage in package.json
- ⚙️ **Config**: Updated summary file location in azure-pipelines.yml
- ⚙️ **Config**: Enhanced Jest preset to configure coverage reporters
Add data-what and data-which attributes to key UI elements:
- Add back button attributes to return details and process components
- Add filter button attributes to the filter menu component
- Add sort button attributes for both desktop and mobile views
- Add result count element attributes for better selection
- Add attributes to search result items for identification
- Add attributes to loading spinners for state verification
These attributes improve E2E test stability by providing reliable selectors
that are not tied to styling or DOM structure changes.
Ref: #5052
- ✨ **Feature**: Added support for hierarchical logger context
- 🛠️ **Refactor**: Updated logging methods to use LoggerContext
- 📚 **Docs**: Improved documentation for logger methods and context
- Deleted validation functions for electronic devices, nonbook items, and ton/datentraeger.
- Removed associated test files for these validations.
- Updated question definitions to use new constants for item conditions and return reasons.
- Refactored return process service to utilize schema validation instead of custom validators.
- Adjusted HTML templates to reflect changes in eligibility state handling.
- ✨ **Feature**: Added customizable appearance options for CheckboxComponent
- ✨ **Feature**: Implemented ChecklistComponent for managing groups of checkboxes
- 📚 **Docs**: Added comprehensive documentation for Checkbox and Checklist components
- 🧪 **Test**: Created unit tests for ChecklistValueDirective and ChecklistComponent
- ✨ **Feature**: Introduced ReturnReceiptValuesDTO for return receipt data
- ✨ **Feature**: Added ReceiptCreateReturnReceipt method in ReceiptService
- ✨ **Feature**: Updated ReceiptItemDTO with new fields for handling details
- ✨ **Feature**: Added checklist question type for return process
- ✨ **Feature**: Implemented checklist question component
- 🛠️ **Refactor**: Updated return process service to handle checklist answers
- 📚 **Docs**: Added schemas for checklist answers and return details
- 🧪 **Test**: Updated tests for new checklist functionality
- 🛠️ **Refactor**: Updated component selectors from 'lib-' to 'oms-feature-' for consistency
- 🎨 **Style**: Enhanced formatting and readability in HTML and TypeScript files
- 📚 **Docs**: Added detailed comments for return process questions and validation logic
- 📚 **Docs**: Improved documentation for return process service methods
- 📚 **Docs**: Updated schemas with descriptions for clarity
- Added questions and validation logic for the Tolino return process.
- Introduced Ton-/Datenträger return process questions and validation.
- Created a registry to map product categories to their respective questions and validators.
- Developed unit tests for the new return process questions and validators.
- Removed deprecated return process questions and validators to streamline the codebase.
- ✨ **Feature**: Added mapping for min and max values in date range input
- 🛠️ **Refactor**: Updated handling of optional min/max properties in mapping function
- 🧪 **Test**: Added unit test for min and max value mapping
- Added comprehensive JSDoc comments to mapping functions for checkbox and text filter inputs, improving code readability and maintainability.
- Refactored checkboxFilterInputMapping and checkboxOptionMapping functions to enhance clarity and structure.
- Removed unused data-range-filter-input mapping files and tests to streamline the codebase.
- Introduced a new dateRangeFilterInputMapping function with detailed mapping logic for date range inputs.
- Updated filter input schemas to include descriptive comments for better understanding of properties.
- Implemented unit tests for date range filter input mapping to ensure correct functionality.
- Enhanced existing filter mapping functions with improved error handling and validation.
- Updated index exports to reflect the removal and addition of mapping files.
- 🛠️ **Refactor**: Updated return search result component for mobile responsiveness
- 🗑️ **Chore**: Removed unused order-by dropdown component and related files
- 📚 **Docs**: Enhanced component documentation for clarity
- Added Core Logging library providing centralized logging functionality.
- Implemented LoggingService with multiple log levels and configurable sinks.
- Created ConsoleLogSink for logging to the browser console.
- Introduced LoggerApi for context-aware logging.
- Added support for custom sinks and logging configuration during app initialization.
- Enhanced FilterService and FilterMenuButtonComponent with logging capabilities.
- Updated ESLint and Jest configurations for the new logging library.
- Documented the logging library API and usage in README.
fix(customer): Updated Validations for B2B Customer
Conditional Validator - If Organisation Name is set First and Lastname is not required, If no first and last name organisation name is required
Ref: #4996
- Added filter input mapping functionality to handle different input types (Text, Checkbox, DateRange).
- Created schemas for various filter inputs including BaseFilterInput, CheckboxFilterInput, DateRangeFilterInput, and TextFilterInput.
- Developed filter mapping logic to aggregate filter groups, inputs, and order by options.
- Implemented unit tests for filter mapping, input mapping, and order by option mapping to ensure correctness.
- Introduced a dropdown component for selecting order by options with appropriate styling and functionality.
Hotfix 5022 - AHF Buchungh von Bezalten und nicht Bezahlten artikeln auf unterschiedliche Abholfächer 5022-Bezahlte-undunbezahlte-Ware-auf-der-seben-AHF-nummer
bugfix: Show error when control has error
Rename validator requiredIfControlIsSet to requireGenderWhenNameIsSet
Update logic for requireGenderWhenNameIsSet
Added JSDoc for Documentation
UiFormControlComponent Subscribing to ngControl.statusChanges and ngControl.valueChanges independendly and call cdr.markForCheck when emitted
Related work items: #4996
- ✨ **Feature**: Added InViewport directive for element visibility detection
- ✨ **Feature**: Introduced new button for navigation in return details
- 🛠️ **Refactor**: Improved scroll position restoration logic and removed deprecated files
- 📚 **Docs**: Updated README with usage instructions for new directives
Ref: #5034
- ✨ **Feature**: Added method to remove entities by process ID
- ✨ **Feature**: Implemented onInit hook to clear entities based on process IDs
- 🛠️ **Refactor**: Updated imports for clarity and organization
- 🛠️ **Refactor**: Improved entity management logic in return search store
- ✨ **Feature**: Added 'clear' parameter to search method in store
- 🛠️ **Refactor**: Updated search calls in ReturnSearchMain and Result components
- 🎨 **Style**: Improved conditional rendering for apply button in filter actions
feat: enhance return search component to handle search callbacks and update query parameters
fix: update return search result component template to use new search method and improve loading states
refactor: streamline return search result component logic and improve state management
feat: implement scroll position restoration in return search feature
feat: introduce filter service enhancements for query settings and synchronization with URL parameters
chore: create utils for scroll position management and viewport detection
fix: update filter service to use new input and query settings types
chore: add tests and configurations for new utils library
ref: #5033
- ✨ **Feature**: Added breakpoint utility for responsive design
- ✨ **Feature**: Implemented BreakpointDirective for conditional rendering
- 🛠️ **Refactor**: Updated styles for filter and order-by components
- 📚 **Docs**: Created README and documentation for ui-layout library
- ⚙️ **Config**: Added TypeScript and ESLint configurations for the new library
- 🛠️ **Refactor**: Changed filter service method calls to use new query methods
- 🎨 **Style**: Updated button components for consistency
- 🧪 **Test**: Adjusted tests to reflect changes in query parameters
- ⚙️ **Config**: Modified pre-commit hook to run CI checks
- ✨ **Feature**: Implemented return search main and result components
- 📚 **Docs**: Created README for return search library
- ⚙️ **Config**: Added TypeScript and Jest configuration for return search
- 🛠️ **Refactor**: Updated filter menu components with scroll strategy
- ✨ **Feature**: Introduced Gender, AddressType, and ShippingType enums
- 🗑️ **Chore**: Removed obsolete schemas and service files from return feature
- 🛠️ **Refactor**: Updated index files to export new models
- ✨ **Feature**: Added InputControlDirective for better input handling
- 🎨 **Style**: Updated button and text-field styles for loading states
- 🛠️ **Refactor**: Improved button component structure and disabled state handling
- 📚 **Docs**: Updated code style guidelines with new control flow syntax
- 🗑️ **Chore**: Updated Angular dependencies to version 19.2.x
- 🗑️ **Chore**: Updated Nx dependencies to version 20.7.0
- 🗑️ **Chore**: Updated devDependencies including Jest and ESLint
- ⚙️ **Config**: Added Jest configuration files for testing
- 🗑️ **Chore**: Removed unused Karma configuration and assets
- 🛠️ **Refactor**: Updated return details store methods for better clarity
- 📚 **Docs**: Enhanced comments and documentation in return details store
Improved the searchbox components to utilize environment service for mobile detection.
- ✨ **Feature**: Integrated EnvironmentService for mobile device detection
- 🛠️ **Refactor**: Cleaned up provider definitions for better readability
- 🎨 **Style**: Reformatted code for consistency in style
#5001
Refactored routing structure and improved side menu functionality.
- 🛠️ **Refactor**: Simplified route definitions for process handling
- 🎨 **Style**: Cleaned up side menu HTML for better readability
- 🛠️ **Refactor**: Enhanced side menu item click handling
#5021
Introduced a new model for return process answers and corresponding validation tests.
- ✨ **Feature**: Created ReturnProcessAnswers type for handling answers
- ✨ **Feature**: Added validation functions for various return scenarios
- 🧪 **Test**: Implemented comprehensive tests for return process validations
Clarified guidelines for highlighting positive aspects of code reviews.
- 📚 **Docs**: Specify using different funny emojis for good practices
- 🛠️ **Refactor**: Removed redundant good practice example
Enhanced the code review guidelines to improve clarity and effectiveness.
- 📚 **Docs**: Expanded review process steps with detailed explanations
- 📚 **Docs**: Added a review template for structured feedback
- 📚 **Docs**: Clarified the use of emojis for categorizing feedback
Introduced a new dropdown component with associated styles and fixed a typo.
- ✨ **Feature**: Added dropdown component and its styles
- 🎨 **Style**: Updated styles for dropdown button and options
- 🐛 **Fix**: Corrected typo in dropdown options class name
Updated the chip option component and its styles for improved functionality and organization.
- ✨ **Feature**: Introduced new chip option styles and layout
- 🛠️ **Refactor**: Removed outdated styles and organized SCSS files
- 🧪 **Test**: Added unit tests for chip option component functionality
Introduced new documentation files for state management and testing guidelines to enhance developer understanding and best practices.
- 📚 **Docs**: Added state management guidelines with local and global state recommendations
- 📚 **Docs**: Created testing guidelines including unit testing requirements and best practices
- 📚 **Docs**: Updated project structure documentation for clarity
Commit messages should follow the [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/). This provides a standardized format for commit messages, making it easier to understand changes, automate changelog generation, and trigger build/publish processes.
## Format
The commit message structure is as follows:
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
---
### Components
1.**Type**: Indicates the kind of change introduced by the commit. Must be one of the allowed types (see below).
2.**Scope (Optional)**: A noun describing the section of the codebase affected by the change (e.g., `auth`, `ui`, `build`). Enclosed in parentheses.
3.**Description**: A concise summary of the change in the imperative, present tense (e.g., "add login feature", not "added login feature" or "adds login feature"). Starts with a lowercase letter and should not end with a period. Max 72 characters recommended for the entire header line (`<type>[optional scope]: <description>`).
4.**Body (Optional)**: A more detailed explanation of the changes. Use the imperative, present tense. Explain the _what_ and _why_ vs. _how_. Separate from the description by a blank line. Wrap lines at 72 characters.
5.**Footer(s) (Optional)**: Contains additional metadata. Common footers include:
-`BREAKING CHANGE:` followed by a description of the breaking change. A `!` can also be appended to the type/scope (`feat!:`) to indicate a breaking change.
- Issue references (e.g., `Refs: #123`, `Closes: #456`). Separate from the body by a blank line.
---
### Allowed Types
- **feat**: A new feature for the user.
- **fix**: A bug fix for the user.
- **build**: Changes that affect the build system or external dependencies (e.g., gulp, broccoli, npm).
- **chore**: Other changes that don't modify src or test files (e.g., updating dependencies, build tasks).
- **ci**: Changes to CI configuration files and scripts (e.g., Travis, Circle, BrowserStack, SauceLabs).
- **docs**: Documentation only changes.
- **perf**: A code change that improves performance.
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc).
- **test**: Adding missing tests or correcting existing tests.
---
### Examples
**Commit with description only:**
```
fix: correct minor typos in code
```
**Commit with scope:**
```
feat(lang): add polish language
```
**Commit with body and breaking change footer:**
```
refactor: drop support for Node 6
The new implementation relies on async/await and other features
introduced in Node 8+.
BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.
```
**Commit with scope, body, and issue footer:**
```
docs(readme): improve installation instructions
Provide clearer steps for setting up the development environment.
Add links to prerequisite tools.
Closes: #12
```
**Commit with `!` for breaking change:**
```
feat(api)!: send an email to the customer when a product is shipped
You are Mentor, an AI assistant focused on ensuring code quality, strict adherence to best practices, and development efficiency. **Your core function is to enforce the coding standards and guidelines established in this workspace.** Your goal is to help me produce professional, maintainable, and high-performing code.
## Tone and Personality
Maintain a professional, objective, and direct tone consistently:
- **Guideline Enforcement & Error Correction:** When code deviates from guidelines or contains errors, provide precise, technical feedback. Clearly state the issue, cite the relevant guideline or principle, and explain the required correction for optimal, maintainable results.
- **Technical Consultation:** In discussions about architecture, best practices, or complex coding inquiries, remain formal and analytical. Provide clear, well-reasoned explanations and recommendations grounded in industry standards and the project's specific guidelines.
## Behavioral Guidelines
- **Actionable Feedback:** Prioritize constructive, actionable feedback aimed at improving code quality, maintainability, and adherence to standards. Avoid rewriting code; focus on explaining the necessary changes and their rationale based on guidelines.
- **Strict Guideline Adherence:** Base _all_ feedback, suggestions, and explanations rigorously on the guidelines documented within this workspace. Cite specific rules and principles consistently.
- **Demand Clarity:** If a query or code snippet lacks sufficient detail for a thorough, professional analysis, request clarification.
- **Professional Framing:** Frame all feedback objectively, focusing on the technical aspects and the importance of meeting project standards for long-term success.
- **Context-Specific Expertise:** Provide specific, context-aware advice tailored to the code or problem, always within the framework of our established guidelines.
- **Enforce Standards:** Actively enforce project preferences for Type safety, Clean Code principles, and thorough documentation, as mandated by the workspace guidelines.
When conducting a code review, follow these steps to ensure a thorough and constructive process.
**Ensure that all review guidelines are followed. If any guideline is not adhered to, make it explicitly clear which guideline needs to be followed.**
## Review Process
1. 🎯 **Key Issues**
Identify critical issues in the code such as bugs, security vulnerabilities, or violations of the project's coding standards.
_Include specific links to files and line numbers (e.g., file.js#L10) where applicable._
2. 💡 **Suggestions for Improvement**
Highlight areas where the code can be enhanced in terms of readability, performance, maintainability, or adherence to best practices.
_Clarify what constitutes a "Critical" versus a "Minor" issue to avoid ambiguity._
3. ✨ **Code Examples**
Provide specific, concise code snippets that illustrate your suggestions.
_Include both a "Before" (problematic code) and an "After" (improved version) example where beneficial._
4. 📚 **Relevant Documentation Links**
Attach links to useful resources or official documentation to support the suggested changes.
_For example, link to ESLint, Jest, or Angular Style Guide pages when relevant._
## Tone and Feedback
- Be constructive and supportive.
Frame suggestions as opportunities for growth rather than criticism.
- Use the following emojis to categorize your feedback:
- 🚨 **Critical issues**
- ❗ **Minor Issues**
- ⚠️ **Warnings**
- 💡 **Suggestions**
- ✅ **Good practices**
## Additional Informations
- Missing tests and JSDocs are minor issues
- Missing unit test are minor issues
- Missing End-to-End (E2E) Testing Attributes (`data-what`, `data-which`) are warnings
### Review Template
````markdown
# Code Review
## Summary
A brief overview of the code’s overall quality, highlighting key strengths and areas needing attention. This sets the stage for the detailed feedback below.
---
## 🚨 Critical Issues
High-priority issues that must be addressed immediately due to their potential to severely impact functionality, performance, or security.
### 1. High Priority: [Issue Title]
#### 🚨 Issue
Describe the issue clearly, including links to specific files and lines (e.g., file.js#L10). Explain why it’s critical—highlight crashes, security risks, or significant performance issues.
#### 💡 Suggestions for Improvement
Provide specific steps or alternative approaches to resolve the issue.
#### ✨ Code Example
**Current**: [file](file.js#L10) Problematic code with path to the file and line of the code
```typescript
// Code...
```
**Improvement**: Improved version
```typescript
// Code...
```
#### 📚 Relevant Documentation
Include URLs for further research (e.g., [Jest Documentation](https://jestjs.io/docs/getting-started)).
---
## ❗ Minor Issues
Issues that can improve code quality, maintainability, or adherence to best practices when resolved.
### 1. Medium Priority: [Issue Title]
#### ❗ Issue
Describe the issue clearly, including file and line references (e.g., file.js#L10). Explain the impact on the project.
#### 💡 Suggestions for Improvement
Offer concrete steps or alternative approaches to mitigate the issue.
#### ✨ Code Example
**Current**: [file](file.js#L10) Problematic code with path to the file and line of the code
```typescript
// Code...
```
**Improvement**: Improved version
```typescript
// Code...
```
#### 📚 Relevant Documentation
Provide links to further resources.
---
## ⚠️ Warnings
Low-priority issues or suggestions that could help prevent future problems or improve the code quality over time.
### 1. Low Priority: [Issue Title]
#### ⚠️ Issue
Describe the issue clearly with references (e.g., file.js#L10). Explain the potential impact if left unaddressed.
#### 💡 Suggestions for Improvement
Provide suggestions or alternative implementations to mitigate the issue.
#### ✨ Code Example
**Current**: [file](file.js#L10) Problematic code with path to the file and line of the code
```typescript
// Code...
```
**Improvement**: Improved version
```typescript
// Code...
```
#### 📚 Relevant Documentation
Include relevant resources for more information.
---
## 🛑 Bad Practices
Highlight up to five bad aspects of the code to reinforce improvements and encourage good practices. Use different funny emoji at the beginning of each bad practice.
- Emoji **Bad Practice 1**:
Describe a specific weakness (e.g., clear code structure) with an example reference (e.g., file.js#L20). Explain why it’s bad.
- Emoji **Bad Practice 2**:
Outline another negative feature (e.g., effective error handling) with a snippet reference.
---
## ✅ Good Practices
Highlight up to five positive aspects of the code to reinforce well-implemented patterns and encourage good practices. Use different funny emoji at the beginning of each good practice.
- Emoji **Good Practice 1**:
Describe a specific strength (e.g., clear code structure) with an example reference (e.g., file.js#L20). Explain why it’s commendable.
- Emoji **Good Practice 2**:
Outline another positive feature (e.g., effective error handling) with a snippet reference.
---
## 📓 Additional Notes
- **General Feedback**: Optional thoughts regarding the overall quality or potential areas for future improvement.
- **Next Steps**: Outline follow-up actions or further examination areas as needed.
This library was generated with [Angular CLI](https://github.com/angular/angular-cli) version 12.2.0.
## Code scaffolding
Run `ng generate component component-name --project scan` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module --project scan`.
> Note: Don't forget to add `--project scan` or else it will be added to the default project in your `angular.json` file.
## Build
Run `ng build scan` to build the project. The build artifacts will be stored in the `dist/` directory.
## Publishing
After building your library with `ng build scan`, go to the dist folder `cd dist/scan` and run `npm publish`.
## Running unit tests
Run `ng test scan` to execute the unit tests via [Karma](https://karma-runner.github.io).
## Further help
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI Overview and Command Reference](https://angular.io/cli) page.
This library was generated with [Angular CLI](https://github.com/angular/angular-cli) version 10.1.2.
## Code scaffolding
Run `ng generate component component-name --project product-image` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module --project product-image`.
> Note: Don't forget to add `--project product-image` or else it will be added to the default project in your `angular.json` file.
## Build
Run `ng build product-image` to build the project. The build artifacts will be stored in the `dist/` directory.
## Publishing
After building your library with `ng build product-image`, go to the dist folder `cd dist/product-image` and run `npm publish`.
## Running unit tests
Run `ng test product-image` to execute the unit tests via [Karma](https://karma-runner.github.io).
## Further help
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI README](https://github.com/angular/angular-cli/blob/master/README.md).
This library was generated with [Angular CLI](https://github.com/angular/angular-cli) version 15.0.0.
## Code scaffolding
Run `ng generate component component-name --project core` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module --project core`.
> Note: Don't forget to add `--project core` or else it will be added to the default project in your `angular.json` file.
## Build
Run `ng build core` to build the project. The build artifacts will be stored in the `dist/` directory.
## Publishing
After building your library with `ng build core`, go to the dist folder `cd dist/core` and run `npm publish`.
## Running unit tests
Run `ng test core` to execute the unit tests via [Karma](https://karma-runner.github.io).
## Further help
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI Overview and Command Reference](https://angular.io/cli) page.
This library was generated with [Angular CLI](https://github.com/angular/angular-cli) version 10.1.2.
## Code scaffolding
Run `ng generate component component-name --project availability` to generate a new component. You can also use `ng generate directive|pipe|service|class|guard|interface|enum|module --project availability`.
> Note: Don't forget to add `--project availability` or else it will be added to the default project in your `angular.json` file.
## Build
Run `ng build availability` to build the project. The build artifacts will be stored in the `dist/` directory.
## Publishing
After building your library with `ng build availability`, go to the dist folder `cd dist/availability` and run `npm publish`.
## Running unit tests
Run `ng test availability` to execute the unit tests via [Karma](https://karma-runner.github.io).
## Further help
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI README](https://github.com/angular/angular-cli/blob/master/README.md).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.