- Create payslip
- Add a contract with any structure
- Add a structure in payslip, different from the one defined in step 2
- Confirm or compute sheet
Payslip is computed using the contract structure, while it should be
computed using the payslip structure.
Closes#21567
opw-787671
Before this commit, when the sales person (user A) of a lead assigned another user (user B) to an activity
user B couldn't see the lead in his pipeline
After this commit, he can
OPW 787935
Before this commit, because of 9d2f48d and abea8d3 and 4ebb5efac4
closed crm.lead with late activities wouldn't show.
Aware that this is essentially a choice of non-crucial behavior, there are some precautionary arguments.
- The three commits above make the choice of having a "clean" backlog:
late activities are not polluted by crm leads that are already won
- The choice of this commit is to count activities as late regardless of the state of the lead:
The use case: Close a deal with a partner > lead is won and closed
But it doesn't mean you don't have to call the partner back in a few days to actually sign a paper, organize some sort of meeting
The argument: it is better to not miss deadlines eventhough they might accumulate, rather than forgetting about them altogether
(but you don't script something to put all your emails as read when they arrive, do you ?)
OPW 744940
When opening an opportunity from a notification, it always opens the default view
which is the lead view and then the button "Button "Convert to opportunity" was visible.
opw:792931
Changed at 08d48b0ff but was crashing when building the documentation as not
complient for sphinx
Temporary fix that should be restored when our doc engine will be smarter
When modifying files the a widget FieldMany2ManyBinaryMultiFiles would
not keep its metadata (currently associating attachment to [url,
allowUnlink]) up with current value.
So with an attachment added after init:
- clicking on it would error (because link is wrong)
- deleting it would unlink attachment originating from from onchange
The expected behavior is:
- being able to download attachments
- not unlinking attachment originating from onchange
and this is what this commit fixes.
opw-787746
closes#21813
Before this commit, website had incomplete context.
It was causing website.menu to not be translated correctly because lang was
not set on website.
Now, since the website has the context correctly binded, menus are translated
opw-787012
Before this rev., when a graph view was reloaded (e.g. by clicking
on the graph view switcher), the inital groupby was lost if it
didn't come from the searchview (i.e. if it came from the context
or from the arch). For instance, go to Sales > Reporting > Sales
(the view is grouped by 'date', and there are two groups), reload
by clicking on the graph view switcher: there is only one group
left.
The reload RPC was actually fine. What was wrong is the 'state'
object given to the renderer after the reload, as it didn't contain
the correct groupby, so the view wasn't correctly re-rendered.
When changing the date of an account move, the method
`_onchange_amount_currency` is called manually on a recordset. If the
recordset length is > 1, it crashes.
- In an account move, change the date
- All debits and credits of the lines are reset
This is because the recomputation of the credits and debits should only
occur in case of currency rate change.
opw-801030
- Create a product A tracked by lot
- From the Dashboard, create a 'Planned Transfer'
- Add product A, any quantity
- Click on "Mark as TODO"
It's now possible to edit the serial numbers, but it's impossible to set
any quantity in the move lines.
This is due to the remaining context key `planned_picking` which makes
`is_initial_demand_editable = True`. In this case, `qty_done` is
read-only in the view `view_stock_move_line_operation_tree`.
As a workaround, `action_confirm` returns an action and set the context
accordingly.
opw-785332
- Create an inventory 1 with "Product A - Variant 1"
- Start inventory
- Create an inventory 2 with "Product A - Variant 1", "product A -
Variante 2"...
- Start inventory
An error pops-up because two inventories for the same product
"Product A - Variant 1". However, you don't know which variant is
impacted sincethe message error only shows the product name:
"Product A".
Closes#21687
opw-799583
This revision is similar to
6e8faf40bd
but for the opposite case:
When the task is using the pad,
somehow the regular `description` pad
was written as well on save, making both field
being saved together,
and when description is saved
its content is written on the pad.
Therefore, whatever you written in the pad,
the pad was overriden with the current content of
the task regular description field
opw-787773
Suppose that modules M1 and M2 belong to a subcategory of some exclusive
category. Then M1 and M2 may not be both installed, unless one of them
transitively depends on the other.
OPW 785434
The web planner specified no language for frontend.
This commit add a specialized fallback for this use case so the planner
on the website is in the language of the current user.
opw-781727
fixes#20829closes#21006
When installing a payment acquirer from the kanban view, this would by
luck display the form view correctly.
But if we go back to the listing then forward to the form view, things
go awry.
This is because the listing action views have not been updated after the
module installed, this worked at install because we loaded a new action.
This commit change the action so when installing a payment acquirer from
the kanban view, the view is simply reloaded.
opw-786454
closes#21757
Usecase to reproduce:
- Create a new unit of measure "Pack of 6" of UoM Categ = units
- Create a new product: Coca cola can, sell in unit, purchase in packs
- Create a PO, buy 1 pack of this product
- Receive the pack from the delivery order
- On the picking you just received, click on return
-> If you validate the wizard by clicking on "return", you get 6 packs, so you multiply by 6 the amounts of what you send as the system changed the quantity but not the Uom
It happens because the system compute the quanity to returns in terms of quant uom but when creating the return move it copies the origin move uom.
This commit uses the quant uom on the return move and also adds the uom in the view in order to be less confusing for the end user.
opw-800566
Purpose
=======
There's a lot of occurence in Odoo with unicode in views (or models).
But this one is special because it breaks the functional documentation build when loading the fields on the model pos.config with:
.. demo:fields:: point_of_sale.action_pos_config_pos
As the module description is processed by `docutils`, it should be
syntaxically valid to avoid warnings like:
`Bullet list ends without a blank line; unexpected unindent.`
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
There is a drawback in 12048bd6, if a kanban view with an
"Undefined" column (exist when a kanban view grouped on a relational
field and some record have this field unset) had a column resequenced a
traceback would happen if more than one column was displayed.
This happen because before we had a "undefined" ID for the "Undefined"
column and after 12048bd6 we get a framework unique ID which was not
managed.
note: this commit also adds `left`/`right` values in the dragAndDrop
test utility function so an element can be dropped at the right/left of
another element.
related to opw-782433
closes#21708
Before this commit, there was a default behaviour reducing the padding of the qweb render
to 0 in order to display bakcground images correctly. Unfortunately, this doesn"t take in account
cases where images or more generally, qweb template were not provided in the InsufficientCreditError
message.
This commit solves this situation.
Before this commit, the way mode was handled was not optimal. The end
result was correct (the widget were properly created/displayed in
edit/readonly as required), but useless work was done. In particular,
if we have list/x2manys with widgets and modifiers, it could happen that
widgets were created in edit mode, then destroyed and recreated in
readonly mode.
This could happen in some important views, for example, any view with a
field many2many_tags with a readonly modifiers (pretty much all views
handling taxes)
In this commit, we add a 'editable' attribute to list renderer. This is
necessary, because the list renderer is not actually editable when it is
in a x2many in a form view which is in readonly mode. Also, we need to
manage the distinction between the fact that a list view is editable,
and the fact that some widgets are created in edit and other in readonly
mode, depending on modifiers, and on which line is being edited.
We also add a benchmark (courtesy of CHM) to be able to measure the
performance impact of edit/readonly/onchange in a larger form view.
Before this commit, running this form benchmark on my machine gave a
number of 0.4 op/sec, and after, it increases to 1.26 op/sec, so a
pretty large improvement.
There is a subtle issue happening in tests when we override a widget
property for the duration of the test and try to restore the initial state at
the end by rewriting on the property. It actually changes the widget, by
having a function bound to the sub widget prototype instead of its ancestor.
This in turns can cause weird interactions with the class system.
We introduced a proper way to temporarily patch a class/widget by adding
a method in testUtils to do exactly that. This commit simply uses that
method to prevent unwanted interactions in barcode tests
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The kanban view uses a template which comes from the server, already
translated. Before this commit, it tried to retranslate again the
template in qweb.js, which may be a problem (in addition to the useless
work): if some english string A is translated in B (french), but B is
also a valid english string which is translated into C in french, then
we will have a wrong result.
In this commit, we simply add a flag to disable the translation process, which
should also slightly improve the kanban view rendering performance.
When using requisition with a mto product the link
between moves coming from supplier and move going to
customer are not created.
It happens because creating a purchase order from a
requisition set automaticaaly a default requisition id
that trigger an onchange. However the onchange modify the
move dest ids but those are not present in the purchase order
view and thus not send to the server during the create call.
This commit includes the move dest ids as invisible in the view.
Usecase to reproduce:
- Set a product with the same lot in different locations
- Create a MO that will uses theses products and that require more than one location
- Produce it.
-> Traceback Expected singleton: stock.move.line
It happens because product produce only expect one move line
by lot. Howeever it could exist more than one move line if the
product for a specific lot are shared among multiple under location.
This commit try to fill the move line with the correct quantity
one by one and add the extra in a new move line.
Use case to reproduce:
- Create a MO with a product tracked and a qty to produce greater than 1.
- The Bom should also use a routing with at least 2 operations.
- On the first workorder only produce 1 unit and record the production
- Go to the next workorder -> The final lot is not set.
It happens because the lot for the next workorder is only set if the
total quanity for the mo was produced.
This commit fixes the bug by removing the code for the workorder lot
assignation outside the wrong condition. This commit also update the
test test_00b_workorder_process that allows us to find the above bug.
If a kanban view is grouped on a many2one, records with the field unset
are displayed in a column "Undefined" displayed first.
But the tab in mobile view doesn't respect this, so we can get:
columns: Undefined colA colB
tabs: colA colB Undefined
So we always get always on the wrong column wrong when clicking on a
tab: clicking on colB we get on colA, clicking on Undefined we get on
colB, ...
note: in this commit the "false" tab has been set to a translatable
"Undefined" name.
issue found when working on #21199
If at one time kanban column are sortable then they stay sortable for
ever even if they should not.
eg. kanban view is grouped by a many2one (sortable) then by selection
field (should not be sortable): the columns are still sortable.
issue found when working on #21199
A kanban column has two identifiers:
- db_id: framework unique identifier for the column
- id: either the record res_id (grouped on x2o) or the value
The issue is that sometimes the value may be a any string which
would be source of issue unexpected for an ID (and there was one
issue in mobile renderer).
This code change this so "id" is either the record res_id or
`undefined` value, and when used in XML we use id or fallback on db_id
when we need an identifier.
So in the XML data-id on a colum is always either the ID of the record
the group is based on, or the db_id in the form.
opw-782433
closes#21199
Before this commit, when grouping a kanban by date with a modifier
e.g. crm.lead grouped by create_date:month
A traceback was thrown on the python side bacause create_date:month was literally not a field
After this commit, the progress bar in that situation displays well,
at the price of copying bits of the read_group infrastructure
OPW 785021
- Added latest taxes for year 2018 of sales and purchase with percentage 3.7 and 7.7
- Added tags to show newly added taxies in VAT report(enterprise branch with PR #1628) for Switzerland
- Added fiscal positions mapping as well.
Was PR #20851. Was task 39082
The condition in `_free_reservation` explicitely ignore move lines
having a done quantity. Let's imagine the scenrario where two stock
moves reserve all the quantity available and the user chose to process
all the quantity in a move while another user already set half the
quantity as reserved. In this case, we should keep the processed
quantity on the other move but correctly remove its reservation.
Nicolas Martinelli