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.
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.
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.
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 I did efd15852, I accidentally undid d20074c5. That commit
wanted to filter out unwanted values from the action context, but
it was too violent, as it was discarding the action context. (See
bug described in efd15852)
My original commit aimed at avoiding the filtering of the action
context by having it devoid of unwanted values altogether. The
idea was "if this is an action button, we don't want the element
context". However, the default behavior of the _getContext function
was to add the element context. There were options to force to add
the element context despite being in a case where it should not be
added, but we needed the opposite: do not add the element context.
We used "additionalContext" in this fashion, the idea was: "if I
give you specific context values, don't polute it with the element
context". This was efd15852.
However, not all actions have context defined explicitely in their
definition. In this case, since additionalContext was undefined,
the element context was added again, despite our will not to add
it for actions. We solved this by simply always giving an
additionalContext to getContext, providing an empty one if needed.
To reproduce this bug (which is the same as efd15852):
- Go to Manufacturing
- Click on menu Master Data then Products
- Open a product
- Click on the "Bills of Materials" stat button
- Click on create
- The create crashes because of the "default_type" context key
that is erroneously passed from the "Products" action to the
"Bills of Materials" stat button action.
This commit aims to reproduce saas-15 behaviour when rendering the
calendar. More explicitely, in favourable conditions, we would like the
calendar to be contained in a scroller adapted to the screen dimensions.
To do so, we require that the calendar only use the height given by its
parent container (in case of overflow, the calendar should have its own
scrollbars). We then trigger a 'resize' event to account for a bad
initial render of the calendar.
This fix reproduces a behavior implemented in saas-15.
It avoids simultaneous actions when you quickly click
on status bar buttons.
For example, in a manufacturing order, the main_flow_tour clicks
on 'check availability' and 'produce'.
Clicking on 'check availability' triggers an act_window_close
action when it has done.
Clicking on produce opens a dialog. Both action are executed simultaneously.
It may happen that the act_window_close closes the dialog opened by action
'produce', which makes the test fail.
Now the following buttons are disabled if you click on a status bar button:
- action buttons in control panel
- action buttons in status bar
- stat buttons in button box
A traceback occurred when trying to reload a graph view with no
groupBy in the searchview, because the array of fields to read
given to the read_group RPC didn't contain the default groupBy
field (Error "Fields in 'groupby' must appear in the list of
fields to read"), e.g. in Sales > My Pipeline.
In previous versions, readonly used to prevent sending the values
of the fields to the server. However, it was not working properly
for fields which have their own sub-arch in the view, as the value
used to be sent regardless of the readonly value.
In the new views, the readonly modifier is never overlooked, which
created a bug in the stock_picking_return wizard which was not
able to return products received from a po anymore. Basically the
value of the product_id field was not sent so the create crashed.
This commit introduces a new "force_save" modifier which is used
to express that we want to save the value of the field even though
it is readonly from a user interface point of view.
Since the switch to the new views, 'all' filters such as "Everybody's
calendar" did not work as intended (activating the filter would
sometimes lead to fewer events being shown).
This commit corrects the way 'all' switches affect a domain.
More precisely, the conversion from filters to domain has been changed
in the following way.
- Ticking all visible checkboxes associated with a filter no longer
means the same as ticking the 'all' checkbox. The former choice was
particularly problematic when a filter only had one visible checkbox,
in which case it was not possible to see the list of records
only associated with that one filter.
- The conversion used to contain an impossible case in which we convert
a filter into a 'not in' domain. All the related logic has now been
deleted.
- Minor changes (renaming variables etc.) to make the code more
readable.
Grouped lists aren't editable. However, they may contain a widget
allowing the edition in readonly (e.g. priority, toggle_button...).
This is for example the case in Leaves > Reporting > Leave Details.
When the toggle button is clicked, the model is correctly notified
of the change, which is correctly sent to the server. However,
before this rev., the edited row wasn't redrawn in the grouped
list, so the former value of the boolean was still displayed.
Before this commit, the session object was responsible for loading the
translations in the backend only. There was then ugly code in web_editor
(which is also loaded in backend...) which was doing "if frontend then
load translations by myself". This code was also translating templates
while this is the qweb object's job. Now session is always responsible
for loading translation.
Note: the session object should be refactored/split.
Let's assume that we have a form view with a one2many field
displayed as a list containing two fields A and B (an input field,
e.g. a char field). An onchange on the one2many is triggered as
soon as A changes. This triggers a reset of the one2many which
thus redraws the corresponding line by resetting its widgets.
A problem occured when the user updated A, and directly (before
the onchange returned) updated the input field B, as in this case
the new value in B was erased when the onchanged returned, as the
widget was reset with its former value (or with the value returned
by the onchange, if any). Note that the model was aware of the
change on B, so the model and the UI were actually desynchronized.
This was quite hard to reproduce in practice, by hand, but it
occured in the tour testing 'the flow', in the form view of
account.bank_statement, with fields partner_id and amount of the
line_ids one2many.
With this rev., we don't re-render the input fields if there are
pending changes that haven't been acknowledged by the model.
The pad widget does something unconventional: it creates the pad url
only when rendering in edit mode. This was done to prevent creating pad
by default for record in readonly mode.
Because of that, if the user clicks on create, then discard, the record was
considered dirty, so a confirmation modal popped up. In this commit, we
just make sure that the initial setValue from the rendering does not
'dirty' the record.
*board,crm
Before this rev., the dashboard panel (e.g. of the sales team
dashboard) wasn't displayed when there were no record to display,
whereas it should. Only the nocontent helper was displayed.
This was a bug introduced with the new view: the views' controller
was in charge to display the renderer (if there were data to
display) xor the nocontent helper. As the dashboard panel was
rendered by the renderer, it couldn't be displayed alongside the
nocontent helper.
This rev. moves this logic to the renderer. So now, the controller
always contains the renderer, which decides what to render (the
data or the nocontent helper). This way, the dashboards can display
their panel and the nocontent helper.
In 3071ef16c sorted filter was added, but arround the same time with the
change of filter in 6c579354 the js part of the feature was lost.
This commit adds it back.
opw-749422
closes#18361
Some one2many fields are called with a many2many widget to unlink
records instead of delete them. But this behavior was modified with the
new views and the records were deleted anyway.
In this commit, we restore the previous behavior, and create a FORGET
command in basic model
to do that. Note that the widget='many2many' is a hack, and a better way
to accomplish this is to use a new custom option. But this would be a
fix for master (PR #18413)
Trying to display external identifiers would make the server crash
because the method in charge of requesting the external id information
would expect an object but it was being given a string and thus not
computing the m2o_value for the record.
This commit fixes this by changing FieldMany2One objects' m2o_value
instatiation to use its _formatValue method to compute it, _formatValue
is then overridden in FieldReference so that it properly handles both
strings and objects to calculate its m2o_value and relation.
Before this commit, the makeDefaultRecord could return a rejected
deferred if the onchange returned a warning. This was useful in this
usecase: the user is in a form view with a one2many (for example, an
invoice with no customer set), then click on 'Add a line' (the invoice
line). In that case, the onchange returns a warning, and we do not want
to add the line at all, so the makeDefaultRecord is rejected.
This works fine, but we then have another problem: when we create a new
record from scratch, it may happen that a warning is returned (for
example, if a vendor has its 'warning on invoice' flag set, then a
purchase order is done with this vendor, then confirmed, then the stat
button for 'vendor bills' is clicked, which opens a list view with the
vendor in the context. Clicking on 'create' will return a warning,
which is what we want). In that case, the record still needs to be
created.
To solve this issue, we simply add an option to the makeDefaultRecord
function to prevent rejecting the deferred.
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
qsm-odoo