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.
Before this rev., nothing was rendered when the 'gauge' widget was
set on a field (e.g. Sales > Leads Management > Team Assignation),
because the API of the fields in web evolved a lot recently, and
the rendering should now be done in a private function called
'_render', not 'render'.
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.
This module defines tours meant to test some cross-app workflows in Odoo.
At this time, it contains a 'tour' that do some important tasks like:
- product creation
- sale order creation
- reordering rule
- invoicing
- reconciliation
- ...
Before this commit, it was only possible to set an option with
his value.
For example:
<select name="test">
<option value="1">One</option>
<option value="2">Two</option>
</select>
The only way to set the first option was to do the following:
run: "text 1"
With this commit, we can now select the first option with his text value:
run "test One"
We need this because in 'main_flow_tour', some values are generated ids.
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.
Before this commit, the pad widget did not force the view to save the
current value, since it did not change (pad values are just the url for
the pad). However, this is a problem for the server, since it uses the
fact that the web client forces a save to update the description field
in the model (get the data from the pad server and add it to the
database).
This was not a big deal when looking at the pad (the pad widget fetches
its data each time), but it is a problem that the database is not
synchronized with the current data.
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.
If the pad content field is modified in Odoo, the content of the pad should be modified too.
Example: When merging tasks, the tasks descriptions are concatenated into the target record. But the taregt pad is not modified if it already exists.
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
Display both fiscal position and fiscal position remark on invoice.
Since the note is usually empty, it most of the time displays an empty
label next to 'Fiscal Position:'.
opw-756720
The constraint does not allow the same check out time as the next
check in time which might be rare but a possible and likely use case.
opw-756694
Closes#18400
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.
A special case was made for products not available when running a search on
the qty_available field.
For domains like ('qty_available', '<=', 5), it should include non-available
products too.
Fixes#18336
Create a company, try to install a coa without specify an Interbank Transfer Account (required field):
The COA can't be installed due to the missing Interbank Transfer Account that will be created by the COA... that leads to a "deadlock".
-opw: 752928
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
- Create a tax using the tax template 'GST + QST for sales'
- Create a SO with the following lines:
Product 1 100 Units @ 0.1
Product 2 2000 Units @ 10.334
Product 3 2000 Units @ 10.334
Product 4 5000 Units @ 0.1
Product 5 1500 Units @ 0.1
- The totals are:
Amount without taxes: 41996.00
Taxes: 6288.90
When printed, the quotation gives:
Amount without taxes: 41996.00
Taxes: 6286.52
This is due to the method `_get_tax_amount_by_group`, which is using
`line.price_reduce` for tax computation. Since it is a Monetary field,
it is automatically rounded to the currency precision, while it should
be rounded with the same precision as `price_unit`.
To avoid breaking overrides, changing the field type is done in master
branch.
Introduced in 99743cc4aa
opw-752487
This fix previous commit a29f7f671b.
(1) Some objects have no color field.
(2) There was an issue when two many2many tags were instantiated:
If the first one had the 'color_field' attribute the second one
had it too even if this attribute weren't specified.
Now, it's fixed in data_manager
The field 'payment_acquirer_id' is added on the sale.order model
in the website_sale module, which may not be installed when this
code runs since it is higher up in the dependency tree.
Either way, it's quite convoluted to go fetch the acquirer on the
quote since it's already available on the transaction itself anyway.
opw-755998
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
Thibault Delavallée