Since commit 417a664f16:
The `ajax.loadXML` function has been refactored and improved so that
multiple calls to the function with the same URL only loads it once
and so that the deferred which is returned really indicates the status
of loading this particular URL.
Unfortunately, there was a mistake: when loading the same URL twice,
the second call always returned an already resolved deferred if the
first call to `ajax.loadXML` was done with this URL.
This will avoid useless warning when the file does not exists and
possible false positive errors in case of invalid config in this file.
Also strip output
Purpose: Replace POS APP settings with a clean POS Form settings,
one per POS
- add state button for (active/inactive) archive/unarchive and remove boolean field.
- remove 'Reprint Receipt' field from pos_reprint module and related code.
- remove 'Multi-currencies' field and related code.
- put 'Company' field under the 'Taxes' block and 'Sales Channel' under the 'Pricing' block.
- add 'save' buttons to install needed modules manually.
- removed constrains and set default fiscal value on fiscal position ids even if that not selected.
- change the skip Receipt Screen label to a more appropriate one.
- Tax help only appears when Tax-included is selected.
* [IMP] point_of_sale: Removing multiple prices prod
Purpose: The choice of the method for "Multiple price per product" was
not appropriate for the Point Of Sale. Only the choice of the Pricelist
make sense. So, only the Pricelist can be choosen in the POS config.
* [IMP] point_of_sale, pos_discount, pos_restaurant:
Generic module install
Purpose: Before this improvement, some fields were used in pos.config to
automatically install some modules.
This fix tries to mimic the ResConfigSettings transient so that
when a field starts with 'module_', it's automaticaly
installed.
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.
qsm-odoo