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='.*'
Opening a modal in Odoo should be done thanks to the 'Dialog' class. In
the frontend, there can also be modals which are meant to be shown to
the unconnected frontend visitors and those should then get the style of
the website (bootstrap) and not the one of odoo. To manage this, the
website JS code was extending the Dialog class so that it adds the
'o_website_modal' class on modals which are opened thanks to the class.
The LESS code was then in charge of forcing the Odoo style on those.
This behavior is not the right one. "Visitors" modals should also be
able to be opened with the Dialog class. This commit is a first step
towards to the right behavior:
- The standard 'Dialog' adds the 'o_technical_modal' class on its root
element by default and allows to not put it thanks to 'technical'
options.
- 'o_website_modal' is then replaced by 'o_technical_modal'.
What should be done next is:
- Use the Dialog class when it is possible
- Move modal.less in the common assets and make it style only technical
modals -> remove some forcing of the style on 'o_technical_modal' in
the frontend
This behavior also allows future improvements, like building a
completely different structure for technical modals which would allow
better designing and the end of visitor/technical bootstrap conflicts
(and so LESS efficiency).
* web_editor
Odoo extends jQuery to add some utility functions. The 'prependEvent'
one add the possibility to add an event handler on an element (like
the jQuery built-in 'on' function) but to be executed before the
already binded ones.
This function was however incomplete and did not allow to use jQuery
namespaced events.
* web_editor, web_tour
jQuery has the built-in ':visible' selector. This is however not enough
as this only checks if the element and its parents have a visible
'display' property. Ironically, if the element has the 'visibility'
property set to 'hidden', it will be considered ':visible' by jQuery.
This commit creates the ':hasVisibility' and ':hasOpacity' selectors
which respectively check if the element and its parents have a visible
'visibility' property and a visible 'opacity' property.
The rev. https://github.com/odoo/odoo/commit/99ae418bf24171fbc6bb27584059c27efb857e77
introduced a trigger_up `mutexify` when quick creating a record in a many2one ;
this broke the behaviour when the many2one was standalone (because it has no
BasicController and mutexify is handled in the latter).
An attempt to fix this issue has been made in the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
by adding an option `standalone` in the field widget options. In this case,
the action was directly executed instead of the trigger_up. While this correctly
works, this implies that the option needs to be added in every standalone
many2one (and only many2one as the others won't use the option), which is not
very convenient.
An other attempt is made in this rev. by moving the mutexify handler from the
BasicController to the FieldManagerMixin ; as a widget that instantiates a field
widget needs to extend this mixin, both cases will work and we won't need to
specify the option anymore.
This commit thus partially reverts the rev. https://github.com/odoo/odoo/commit/e83c3e2678500c9bf2c17b4d23ae9a294ebafaa7
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
The tested use case is the following:
- Create a SO with 5 units of a product (invoiced on delivered quantity)
- Ship 5 units
- Create an invoice with 5 units, validate
- Return 2 units from delivery
The current state:
- Ordered : 5
- Delivered : 3
- Invoiced : 5
In that case you have invoiced more than the delivered quantity and the sales order should be marked as fully invoiced following the commit c854de4
The salesman will transfer the credit note to the accountant and everybody's happy.
As it is the intended behavior, this commit modifies the test.
A bug happens in stock move's action_assign method. It tries to get
the quantity done and the reserved quantity from the parent move and
sibling move in order to guess the available quantty.
With uom activatred, the quantity done is not always the same than the quant
quantity and the quantity done on stock move/stock move lines has to be
converted in order to know the real quantity available/
This commit change the quantity done in action assign to the
associate product uom.
PURPOSE
=======
Clarify the invoice status on the sales orders.
SPECIFICATION
=============
If you have invoiced more than the required quantities and, the invoice status of the sales order should be "Fully Invoiced" and not "to invoice"
* rename stmart button Quote to Quotations to be coherent with naming
through all addons;
* fix stmart button counter to correctly take into account sale orders
otherwise displayed orders are not really coherent with the opportunity;
* stmart button Orders now correctly redirects to sale orders only;
Rename "Quote" to "Quotation(s)" on the opportnity form view, and display the appropriate counter on that. and open the Quotation view when create a quotation from an opportunity.
[ADD] sale_crm: Added a tooltip on the "Orders" stat button.
[FIX] sale_crm: samll fix.
On a list view, if we group records the arrows and changing page
feature are disabled. But if then we removed the grouping, the arrows
never reappeared.
note: not necessary as of 9.0 it was already solved in 1280bf251
opw-760956
closes#18596
the field data-max is supposed to be stored in the database.
Currently, the arg is 'stored=True' which is not recognised by the orm.
This fix ensures the field is correctly sotred and thus not computed at reading.
Due to o_kanban_mobile class which adds text-overflow to all span tag
overflow: hidden is applied on activities. To avoid this overflow issue
we have to use overflow: inherit property.
Add into the warning message the list of stock.move that raise the constraints
error.
When you create an 'Inventory Ajustment' of 1000 lines and see this error,
it is not easy to find which product could cause the problem.
This solution is not perfect since the name is not uniq, but it decrease
drastically the number of record to check manually.
opw-760643
Richard Mathot