Purpose: Improve fleet for a better usability
Dashboard:
- Replace 'leasing' button by a contract status icon in kanban tiles
- Add a link to contract
- Link to vehicule form when clicking on the tile
Vehicle form:
- Track contract status in a chatter
- Add a model_year
Contracts:
- Imporve the states names
- Split service types in two list views service/contracts
- Execute a cron once a day to upgrade contract status
- Add a new contract status is introduced 'Expiring Soon' to help
spot contracts that will expire until 15 days with a filter.
- Add a 'group by vehicle' to improve list usability
Fuel logs view: Add an an odometer column
Avoid `SELECT *` on `information_schema.columns` because specific access
right restrictions in the context of shared hosting (Heroku, OVH, ...)
might prevent a postgres user to read this field.
Purpose
=======
Advantages :
~~~~~~~~~~~~
- using tasks and issues in a project is not easy. Indeed stages are shared but the process is rarely exactly the same. That's why we have a project for master bugs in our prod.
- having tasks and issues causes issues with email templates (it is easy to put a task-related template on an issue-related stage and that may cause crashes) and rating (same here)
- views are globally the same
- using tasks and issues causes issues with mail alias, as you can create only one of them. We have some strange onchange to ensure the alias creates the right model but I don't think it is really user friendly
- code is globally the same between task and issue and therefore will cut the code in half for those models
- timesheeting on issues is not as complete as timesheeting on tasks, and merging them makes sure we have only one way of working with timesheets in project
- customer portal can be simplified as we have only one menu item for project, leading to code reduction and portal simplification
It doesn't make sense.
- The end date is set on a task when it's moved into a folded stage.
- The start date is the last date on which the task as been assigned to a user.
It's possible that an unassigned task is moved into a folded stage, and it shouldn't raise a ValidationError
This field was needed because a rating could be sent to a customer for a task or an issue.
This was buggy, because if a template was set on a shared stage between tasks and issues, the rendering could crash, generate an email with wrong piece of information, and so on.
By removing this field, we can also remove some ugly code that was needed to make that distinction.
Currently when calling default_get (example: Create a new task), if a user is set on the new task, the assign date is automatically set at now()
It seems wrong for 2 reasons:
- It's alreay done either in write or create
- If the user creates a new task, but removes himself from the `Assigned to` field, the assignation date is still set, which is wrong.
Seen that:
- a unicity constraint on a translated field may lead to unexpected results
- declaring records with xmlids of other modules (aka 'base') raises a warning
- some titles may be translated and are highly local
=> we let people manage titles of their countries, even if it may lead
to a few duplicates in case where more than 1 localization is installed
We also:
- reorder a bit the form view for quote templates
- change the way default templates are selected for sales order
(inactive quote templates are not selected) while keeping
customizability through ir.values
* [IMP] product: Clean product form view
* [IMP] website_sale: Remove old availability functionality
* [IMP] website_sale: Fix to get attributes details
* [IMP] website_sale_stock: Add inventory availability
- Warning messages:
- Don't show anything
- Show inventory
- Only show below a Threshold
- Show a custom message
- Add Default Inventory availability option in website admin under product catalog setting
- Show inventory availability message based on variant
- Block add to cart if product not available in stock (Block if Show inventory or Only show below a Threshold option is selected)
* [IMP] website_sale_options: Prevent user to buy optional product if stock is not available
* [FIX] product,website_sale_stock: details
- Corrects the display of the image on the product form when selecting a pre-existing image.
It was displaying a template and not the pre-existing one.
[FIX] website_sale_stock: sale_order
Condition was set on linked_line_id which is pointless as we iterate on each line of the order.
[FIX] website_sale_stock: fix import
Change import to proper form: from . import
* [ADD] website_sale_stock: default threshold
- Add available_threshold in website_config_setting view.
- Fix availability and threshold values to be directly
linked to product template instead of website config settings.
- Change custom_message to non-required.
* [ADD] Website_sale: Install checkbox for wbs_stock
-Add checkbox to install website sale stock as 'Inventory' in Website Settings
-Change 'Inventory Availability' to 'Inventory'
-Add help and tooltip for 'Inventory'
* [IMP] website_sale_stock: website product view
- Add Unit of measure in the stock information on the product page.
- rework get_attribute_value_ids method.
* [IMP] website_sale: Stock and Options
- bridge module to allow stock and options to interract together
- changes on the field names (follow pad), modifications.
* [FIX] product: revert on product_views and cleaning
Revert changes suggested on the task as it it scheduled on another one for a big clean-up.
Clean comments on code.
* [IMP] website_sale_stock: website product view
+[FIX] sale_stock: dependency
- changed strings and views for website and backend product view.
- change dependency of 'sale_management' to 'sale' in 'sale_stock'.
We don't actually need the sale menu when managing our stock. Sale if sufficient thix way.
* [FIX] website_sale_stock: triggers on js and ajax
The function inserting the avalability template in the web page was triggered by too much events,
this was triggering a problem with the deferred calls. This was raising an error in the website_sale_tour_buy test.
Now only change on data-attribute_value_ids will trigger the function. The test should run smoothly.
[FIX] website_sale, website_sale_stock: route tour_buy
- The improvements on the branch prevent a user to buy a product when there is no stock.
Adapted the route test to the new behaviour in order to add_cart/buy/pay a product.
--> now buying iPod (16Gb) instead of iPod (32 Gb)
- ajax.loadXML was called to often (each trigger of the function) and was making the runbot crash.
Only one call of the loadXML right now.
The world changes and some country names too :
- Anguilla is not a part of Saint Kitts and Nevis anymore (1980)
- East Timor is now called Timor-Leste and has a new ISO code (2002)
- Netherlands Antilles have been split in CW, SX, BQ (2010)
- Neutral Zone between Irak and Saudi Arabia does not exist anymore
(1991)
- The U.N. now use "State of Palestine" for West Bank and Gaza (2012)
- Yugoslavia has been split (1992) then some remaining parts renamed as
"Serbia and Montenegro" (2003)
- Zaire is now called Democratic Republic of the Congo (1997)
We also fixed/simplified names of other countries/territories when
there is a more vernacular name that is not ambiguous or simply a typo
source: https://www.iso.org/obp/ui/en/#search
(We also fix a test that count countries beginning by Z, and there is
no Zaire anymore)
The Odoo Dialog API already had the "confirm" helper to open a dialog
which shows two buttons: one to confirm and one to cancel. This commit
introduces the "safeConfirm" helper which requires two clicks to
effectively confirm.
Note: this will be used by the upcoming website update.
Odoo checkboxes have a special style which requires a special DOM
structure. Instead of having to build this structure each time we need
a checkbox to be rendered, it is better to have a function that does
that. It is also better to have a JS function for this instead of a qweb
template so that this has not to be lazy loaded by the frontend for
something as simple as a checkbox.
In case `--db-filter` is not provided and `--database` is passed,
Odoo will not fetch the list of databases available in the postgres
server anymore because it does not have anything to match against this
list. Instead, `list_dbs()` will use the value of `--database` as a
comma separated list of exposed databases.
This allows better security hardening in postgres access rights.
Basically, that means that those commands
$ odoo-bin -d foobar
$ odoo-bin -d foo,bar,baz
are now respectively equivalent to those commands
$ odoo-bin -d foobar --db-filter='^foobar$'
$ odoo-bin -d foo,bar,baz --db-filter='^(foo|bar|baz)$'
The old behaviour can still be used with this command:
$ odoo-bin -d foobar --db-filter='.*'
Baris Kocak