[ADD] sale_rental_deposit: introduce deposit mechanism for rental products#1268
Draft
aykhu-odoo wants to merge 19 commits into
Draft
[ADD] sale_rental_deposit: introduce deposit mechanism for rental products#1268aykhu-odoo wants to merge 19 commits into
aykhu-odoo wants to merge 19 commits into
Conversation
…tion - Configured manifest with required metadata and dependencies. - It covers chapter- 2 and 3 task - Added the required fields.
- Completed Ch 4 task for Access Rights
- Created an action - Define main menu and submenus - Add views to manifest 'data' list - Completed Ch 5 Action and Menu part
- Added is_active and state fields in form - Added fields in list view - Improved and adjusted fields in Form View - Completed Ch 5 and Ch 6 List and Form Views
- Implemented search view - Added property types, tags, and offers models - Linked properties with buyer, salesperson, types, tags, and offers - Completed Ch 6 and Ch 7.
- Added Best Offer and Total Area fields in property form view - Covers 2 tasks of chapter 8.
…nction - Added Validity and date_deadline fields with inverse function - Implemented onchange logic for garden_area and garden_orientation - Suggested fixes implemented - Covers last 2 tasks of chapter 8.
- Added sold and cancelled action buttons for state transition - Prevent invalid transitions between 'sold' and 'cancelled' states
- Introduce Accept and Refuse buttons for property offers - Assign buyer and selling price to property on acceptance - Restrict multiple offers from being accepted for the same property - Chapter 9 Completed.
- Ensure positive property and offer prices - Ensure unique property tag and type names - Chapter 10 task 1 completed.
- Adds constraint using float_compare, ignores zero selling price. - Chapter 10 completed.
- Added inline list view for property types - Implemented statusbar widget for property state - Defined default ordering on models - Added conditional visibility and readonly attributes - Enhanced list views with decorations and optional fields - Introduced stat button on property type to access related offers - Added related field and computed offer count for property types - Chapter 11 completed
- Extended CRUD methods for offer validation, state update - Added constraints to prevent invalid operations (state and offer price check) - Inherited res.users to add property_ids relation - Implemented view inheritance to display properties in user form - Completed chapter 12
- Integrated account module to create invoices from sold properties - Reused account.move for financial operations - Enhanced kanban view using QWeb templating - Implemented conditional UI logic with t-if and raw values - Chapter 13 and 14 completed.
- Added visit scheduling with list, form, and calendar views - Added constraint to prevent overlapping visits within the same property - Automatically create calendar events on visit creation - Added issue reporting with list and form views - Completed Group Tasks.
- Added chatter and activities - Implemented logic to reject all other offers when one is accepted - Added “Accept Best Offer” action to simplify offer selection - Added rainbow animation when a property is marked as sold - Display sold ribbon in form and kanban views - Updated kanban default grouping to state and disabled record drag - Made “Sold” and “Accept Best Offer” buttons conditional primary actions
…ard) - Create Counter component with increment action - Introduce TodoList component to manage todos - Add dynamic todo creation - Implement toggle functionality for todo completion - Add conditional styling based on state - Implement delete functionality for removing todos - Refactor Card to use slots and add toggle-able content.
This commit implements the Awesome Dashboard as part of learning Owl. The main goal was to understand how frontend dashboard is built using Owl instead of using xml for standard list/form/kanban views as these are not suitable when we want to display mixed information like KPIs, charts and quick actions in one place, so a custom dashboard is needed. Explored how components, services and hooks are used together. The dashboard is split into smaller parts so it is easier to follow and not everything is in a single file. Also added the option to add/remove dashboard items. This was mainly to understand how state is handled on the client side.
|
|
aykhu-odoo
force-pushed
the
19.0-renting-deposit-aykhu
branch
from
a2c488d to
c5759b0
Compare
…ducts Rental workflows currently lack a way to enforce or manage security deposits, which are a common business requirement for renting high-value or damage-sensitive products. Without this, users must rely on manual workarounds such as adding extra order lines or handling deposits outside the system, leading to: - higher risk of human error, - lack of traceability between rented product and its deposit, - poor user experience on online product page(no visibility of required deposit). This change introduces a structured and configurable deposit mechanism to standardize how deposits are handled across the system. A dedicated deposit product can now be defined in settings, ensuring consistency in accounting and reuse across all rental operations. At the product level, a deposit requirement and per-unit amount can be configured, allowing flexibility depending on the nature of the item. The system automatically manages deposit lines when rental products are added to orders, ensuring that: - deposits are always applied when required, - amounts stay synchronized with product quantities, The same logic is extended to the website to guarantee consistency between backend and frontend flows, and to provide transparency to customers by displaying deposit information before checkout.
aykhu-odoo
force-pushed
the
19.0-renting-deposit-aykhu
branch
from
c5759b0 to
73a3fb9
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Rental workflows currently lack a way to enforce or manage
security deposits, which are a common business requirement for
renting high-value or damage-sensitive products.
Without this, users must rely on manual workarounds such as adding
extra order lines or handling deposits outside the system, leading to:
This change introduces a structured and configurable deposit mechanism
to standardize how deposits are handled across the system.
A dedicated deposit product can now be defined in settings, ensuring
consistency in accounting and reuse across all rental operations.
At the product level, a deposit requirement and per-unit amount can be
configured, allowing flexibility depending on the nature of the item.
The system automatically manages deposit lines when rental products
are added to orders, ensuring that:
The same logic is extended to the website to guarantee consistency
between backend and frontend flows, and to provide transparency to
customers by displaying deposit information before checkout.