If `method_time` is set to end, `method_number` is not the reference for the number of depreciation lines.
Take directly the number of depreciation lines is more correct.
When creating a task on a project which is accessible to followers only,
an access error pops up.
This comes from the `subtask_project_id` field on the task, which is a
related to a `project.project` field. When a task is created, the ORM
tries to write on the related field, and hence on `project.project`.
opw-687252
This revision removes the context from the action:
afd29b277d
The thing is, in saas-11, the `product.template.type`
no longer has in its selection values `product`,
in the module `product`,
there is only `consu` and `service`.
the type `product` is added in the module `stock`
Therefore, this `product` cannot be used as default value
when only the module `product` is installed and not
`stock`.
We force the empty context for migration purposes,
so bases in ealier releases than saas-11 do not have
`'default_type': 'product'` within this action
when they are upgraded to saas-11.
opw-687986
Commit 06754b32 brings an inconsistency between the PoS frontend, the
pos_order and the account_invoice tax calculation. Part of the commit is
correct since it corrects the matching between the `compute_all`
methods, however.
opw-680891
Removing a slide was buggy :
* Removing the last slide left the slide handles (and the user had to
click on remove slide again)
* There was an ugly delay before the removal
* Changing the bg image of a slide was not possible anymore once one
slide was removed
* ...
WHen checking `Dedicated Refund Sequence` in a
sale / purchase journal,
the field `Refund Entry Sequence` must be filled with a sequence.
Otherwise, later, when issuing a refund invoice, it won't be able
to generate the number of the refund invoice as it won't be able
to find the sequence to use.
opw-687839
When using t-esc, if the value is False/not set, the element is not
added to the DOM. Therefore the page asked for feedback but never
actually displayed a textarea input.
Using t-att-value simply prefills the input.
Inconsistencies can arise between the tax calculation performed in the
PoS and in the backend (e.g. in a SO). For example:
- Unit price: 9.479
- Tax: excluded, 5.5 %
- Buy 5 units
- Round globally
In the backend, the result is 47.40 + 2.60 = 50.00
In the PoS, the result is 47.40 + 2.61 = 50.01
We make the PoS apply the same logic than in the backend. First, at the
level of the `compute_all` method, especially to use the appropriate
rounding precision before starting the calculation (so we move the
rounding of `total_excluded` after the rounding precision adjustment).
Then, by calculating the taxes amount as the difference between
`priceWithTax` with `priceWithoutTax`. This is mandatory since they
contain the result of `compute_all` in which the rounding logic has
already been applied.
opw-680891
In saas-11 stock was migrated to new API, but some old API still called
_prepare_values_extra_move so it needs to be callable via both API
version.
opw-687958
When we drag and drop a record in a folded column, the number of elements
in this column displayed in the column title is not updated.
This issue is present because when a record is droped in a column
its id is not added to the dataset of its new column.
To fix this, we had to add the id of the record in the dataset, and
override the method 'add_ids' in 'DataSetSearch' to have the size
of the dataset equal to the number of ids in it. We have replicated
the behaviour of the function 'remove_ids' in the new function 'add_ids'.
It is possible to put a clickable object in a vignette that opens
an action, for example the kanban_status class used in the CRM
pipeline. This thing presents an issue as it opens a wizard, but
when the wizard is closed the vignette is not reloaded.
When you click on this item, it will go through `on_kanban_action_clicked`
in kanban_record.js that will trigger up a `kanban_do_action` custom
event. The kanban_view have an handler for this custom event and
will call the `do_execute_action` method defined on the view.
This method can take a callback as its last argument that will run
when the wizard is closed. Before rev ae583ba1, the behavior was
to reload the entire kanban view but this rev tries to only reload
the kanban record. Unfortunately, it didn't use the argument
in `do_execute_action` but in a then of this method. So it
didn't work. This commit put the onclose callback at its right place.
Without this patch, the new-api/old-api adatpter will invert the
context and count attributes (takes always the context as last positional
argument). This lead to having the count argument being the context,
always returning the count of elements.
Commit 404ed0f788 tried to solve the
problem but only solved a part of it. Indeed, if the snippet child
has a bg color option but not a bg image option, the event propagation
stops in the parent handler, when it is too late.
Solution is checking that the event comes from the same element on
which the callback is attached to.
The `geoip` is not always defined in the session,
and therefore one needs to check it's defined before
attempting to use it.
The same is done at different places in the code,
through the different modules.
opw-687783
It was doing something before but the useful line was removed at 908f4165
The method is no longer useful and can be removed.
It was error prone has it had not the same signature as the one on project.
Fixes#13402
Without the @api.multi property,
the method is considered as taking only one parameter (self?),
while it takes multiple parameters.
This prevented to change the quote template on a sale order,
if the quote template had some order lines, due to the below error
`TypeError: product_id_change() takes exactly 1 argument (19 given)`
opw-687797
Commit f30ec302 defines the messages sent thanks to the channels as
plain text. This is true for all cases but one: the notification
(e.g. @user). Therefore, the notifications links are broken.
opw-687781
From Odoo 9.0, en_US is not always activated in Odoo. As a fallback, if
the search for a language does not find company language nor English US,
we use the first available language (there is always at least one).
In order to reproduce this behavior, eg: you can set the language of
your company's partner to en_US, then load another language, then
disable en_US from your database. Try to open the "Accounting" dashboard
and you will get a traceback.
`product_id.product_tmpl_id` expects ids of `product.template`
while `products.ids` are ids of `product.product`.
This is an oversight during the migration to the new API of this
module in the below revision:
b9853db8b5
opw-687444
Since the below revision:
293c1c06e6
The "Suggested products" tab on the sale quote template
form has been doubled. This is an oversight when adding the field
`layout_category_id` to it.
opw-687633
When consuming products tracked by unique serial number, no check is
done on the quantity consumed for a given serial number. It means that
negative quants might be created without any warning to the user.
We implement a simple warning thanks to a onchange.
opw-687129
When a model has no form defined, a default view is generated displaying all
fields of the model.
The one2many and many2many fields were not displayed on the form, probably for
aesthetic or historical (2008) reasons.
In the merge partner wizard, there's a button in the footer which
trigger the method `action_close`. This method is decorated by
an api.multi and begins with an ensure_one() and if you click
on close directly after opening the wizard, self.ensure_one
fails.
The thing is, `action_close` only return an ir.action.act_window_close
action and there's a special attribue you can set in the form
view button to make it return an ir.action.act_window_close directly.
If we use this technique, then there's no traceback anymore. So this
is the fix.
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal
move for the delivery to debit outgoing inventory (since the goods don't
transit by an internal stock) but the sale does credit it so there was a
build up in the holding account that has to be moved out manually.
This was also reported in #12687.
The solution implemented is to check if the invoice line is related to
sale order lines having one of its procurement_ids with a purchase_line_id
set. If yes, it means that it is a confirmed dropship and in that case we
don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the
behavior will be as it is currently, but it's fine as you don't know how
the procurement will be solved, and it'll be only at the beginning (once
the config is done it shouldn't go in exception anymore). People will have
to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account
(received)' on supplier invoices for dropshipped goods, but rather use the
COGS directly (sounds to me logical, and that's actually why I wouldn't go
for the solution to create the stock move entries every time even for the
dropshipped goods. That, and the fact that it would pollute the accounting
with useless moves).
This is a forward-port/cherry-pick of 7bdd4de805
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.
For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.
Since commit 2ab68047, the Paypal link can be sent in an invoice as it
was the case before. However, in order to be able to save the Paypal
account in the accounting settings, the Paypal account must be
website-published. If the module `website_payments` is not installed,
this is not possible.
We remove this condition, since it should be possible tu use the Paypal
payment method without installing the whole website.
opw-686216
This reverts commit a57b10dbd5. This has to be fixed in 8.0, and moreover it uses fields defined in sale only so the fix must be done in stock_dropshipping module
OPW: 684742
When using dropship+anglo-saxon+perpetual valuation, there is no journal move for the delivery to debit outgoing inventory (since the goods don't transit by an internal stock) but the sale does credit it so there was a build up in the holding account that has to be moved out manually. This was also reported in #12687.
The solution implemented is to check if the invoice line is related to sale order lines having one of its procurement_ids with a purchase_line_id set. If yes, it means that it is a confirmed dropship and in that case we don't call to super (we don't create the cost of sale line).
That means that:
* If the procurement is in exception at the customer invoice time, the behavior will be as it is currently, but it's fine as you don't know how the procurement will be solved, and it'll be only at the beginning (once the config is done it shouldn't go in exception anymore). People will have to manually fix those amounts with a miscellaneous operation.
* users in anglo saxon mode should not use the 'stock interim account (received)' on supplier invoices for dropshipped goods, but rather use the COGS directly (sounds to me logical, and that's actually why I wouldn't go for the solution to create the stock move entries every time even for the dropshipped goods. That, and the fact that it would pollute the accounting with useless moves)
Martin Geubelle