* localized checks layout of US and CA introduced in enterprise
* account settings now install account_check_printing instead of the US checks layout
Wsa PR #18791. Was task 33298
Before this commit, we create a new dynamic action when creating a new
project. This is a problem for various reasons:
- we did not have the nocontent helper properly set (so, the kanban view
could not display the help message just after creating a project
- the dynamic action is slightly different from the one you get when you
click on an existing project (different views, ...)
- the dynamic action is not editable in studio
With this commit, we simply reuse the same action, but with a different
context. This solves all these issues at once, without duplicating
logic.
In a recent commit, the kanban view was changed to display a nocontent
help message, even when grouped. To do that, it was necessary to change
the nocontent structure, and in particular, to position it absolutely.
This totally breaks dashboards.
Also, from a functional point of view, dashboards are used to see
existing information, so it can be said that the nocontent helper is of
a more limited use in this case. Therefore, I think that the best
technical decision is to simply remove the nocontent helper in the
dashboard, rather than fiddling with the css to try to make them work.
Before this commit, it was not possible to display a help message in a
kanban view, if it is grouped. This is an issue, from an onboarding
point of view. Imagine a new user, creating a project. After it
creates a few columns, it is not clear what to do.
With this commit, we display the nocontent help message in a grouped
kanban view, if the user is not currently creating a new column. This
allows the user to focus on its work, by working in phases: first, he is
prompted to create project column, then when he decides that he is done,
the user interface shows the nocontent help message, which guides
her/him to the process of creating a task.
When the user decrease the quantity on the SO it will log the
activity on a the upsteam documents however the user can't easily
find the impacted documents linked to it. In order to achieve that
the _get_upstream_documents_and_responsibles method pass a stack
that remember all the documents browsed in order to return the final
document. This stack is then passed in the _render_method in log activity
in order to use it when rendering the note for the activity.
return the linked requisition line and the responsible for the requisition
instead of returning the origin moves. there should be nothing upper
the requisition itself so we don't need anymore to grind documents in order
to find the upstream one. More information about _get_upstream_documents_and_responsibles
in method _log_activity_get_documents in stock_picking.py
return the production_id and the responsible if it exist on
the move instead of returning the origin moves. We can deduce that
if a production is linked to a move and this MO still ongoing then
it should be the upperstream document.
When the user decrease ordered quantity on a SO, it will log a note
on upstream ongoing document in order to notify the user that the
demand has changed in order to let him react has fast as possible.
Check method log_activity in order to have more details about the
shortcut method used in order to log activity on downstream/upstream
documents
Allow to redirect on a form view when the user click
on a html tag a with data-oe-model and data-oe-id specified.
In order to avoid code duplication the do_action already existing in
mail_thread is moved in the action_manager and mail_thread and mail_activity
use a trigger_up in order to call it.
The purpose of this commit is to create a generic method in order to
log an activity on following documents or on upstream documents in order
to avoid code duplication.
In order to use it, you have to:
- create a static method in order to generate the string
for the note (it will use an arguement with the format
{'dest_object': ['orig_obejct', (new_qty, old_qty)]}
- 'DOWN' to notify following document. In this case you
have to specify a groupby/sorted method.
- 'UP' to notify upstream document. In this case you have
to specify a specific method call
'_get_upstream_documents_and_responsibles' on the object to
ride up.
Log_activity's operating mode:
destination objects = self.stream_field(passed as arguments)
'DOWN' group destination objects by document on which we want
to log the activity and a responsible to assign.
For each pair (document, responsible) generate a specific note
with only the information relative to object that belong to the current
document. Once the note is returned, it logs the activity on the
document and assign the reponsible.
'UP' instead of sort and group runs the method
'_get_upstream_documents_and_responsibles'. For example on moves
this method is called recursively on all moves orig that are not done or
cancel until it can't find a valid one at this moment it returns its picking.
Then generate the note and log the activity the same way than 'DOWN'.
If two blanket order are active with the same vendor, we have to produce
two separate purchase orders even if the two products are ordered in the
same operation.
If the parameter multi currency is enabled, the field currency is added
in the purchase requisition form. The currency chosen will be the one by
default in the PO attached to the BO
If a there is blanket order in 'ongoing' state and linked with the purchase
order's vendor, we can choose associate it to the PO to retrieve the contrat
price and impact the ordered quantity.
If a purchase order is created from a blanket order, the vendor is
linked to the BO reference. So we forbid its edition once its choose.
When creating a blanket order, it will generate a supplier info for the
associated product. If there is already a supplier info for the same product
and same vendor, the sequence should be adapted to take the one created via
blanket order before the other(s) one(s).
The stages workflow of purchase tender is not suitable for blanket order.
the steps bid selection is use only with purchase tender. Now :
PT : draft -> confirmed -> bid selection -> closed
BO : draft -> ongoing -> closed
The blanket order is a contract between you and a supplier on a
different
price (usually lower than normal) for a big quantity of some specific
products.
The goal is to generate a supplier info for each product of the blanket
order and
remove them when the BO is either closed or cancel.
Purchase requisitions have two different type available : purchase tender
and blanket order. As the behaviours between these two types are very different,
the type is now locked once the requisition is no more in draft state.
When creating a draft purchase agreement, a reference number was generated even if
we do not click the 'Save' button.
Now, the reference is filled with 'New' at the creation and overided with a proper
reference number after clicking on 'Save'. Also, the prefix depends now of the
requisition type. BOxxxxx for blanket orders, TExxxxx for call for tenders.
The vendor is now a mandatory field in the blanket order form
because it's directly linked to purchase orders. So Odoo needs
to know to which supplier the PO is addressed.
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
Some sips provider don't use 2 as key_version.
E.g. mercanet uses '1' as production key.
Now we allow to override it in Ir Config Parameter for stable version.
Todo:
Need to make it customizable by end user into the configuration of acquirer.
Courtesy of BEK for reporting
Don't rewrite the wheel with serve_404.
It is the job of HandleException to do it.
In the same time, that will fix the status code that was
previously 200 instead of 404 in serve_404
This commit closes#22438
Before this commit, if you call a route with an missing ID, you
see an internal error 500 "Record not existing" (MissingError)
It has been intriduced by commit 9dc173cc2e
Now we catch the missing Error and return explicitely a 404 exception.
removeSrcAttribute should avoid these rpc, but for some
unknown reasons, on firefox it works but not with chrome.
Because the purpose of the test is to check the url and
not the content, that works to use an existing route.
Courtesy of @kangol for the fix
There is a slight visual inconsistency since: 9af8d5e6 the xml/less
editor for first level of descendants were just prefixed by an invisible
space.
opw-807624
closes#22704
From a form view (say Bill of materials)
Edit the form
Click on a bom line
Click on the external button that makes the product form pop up
change the order of suppliers on that product
Before this commit, a JS traceback was raised
This was because the changing object was not present in the localData that the Model object holds
or more accurately, it was not the **right** model object that was targetted
and this was due to the propagation of the resequence event
After this commit, no error is thrown, and the resequencing works as expected
OPW 807196
Before this commit the bootstrap version we used was inconsistent.
Indeed, the javascript files were the 3.3.4 ones and the less files
were the 3.3.5 ones. This was due to a failed merged resolution in 9.0.
This should however not cause any issue as the difference between
3.3.x versions are very minor.
Basically, this commit is more of a fix than an improvement and may
even be backported if we find reasons to do so. This commit is mainly
made to prepare the transition to version 4.0.0, which requires to
switch our LESS files to SCSS first (and it will be easier to go by
bootstrap 3.3.7 with SCSS files first).
Backport of this commit: c13c9e0b5c
Steps to reproduce the bug:
- install application MRP Maintenance
- open maintenance request form view, and from top right corner click Studio icon
- click on Equipment field while you are still in studio interface
- It will show left side studio panel, click Domain box and it will throw an error
opw:813594
Set up the following kanban columns:
| Col 1 | Col 2 | Col 3 | Col 4 | Col 5 | Col 6 | F |
| | | | | | Card | |
<------- Screen width ---------->
Col x are unfolded columns.
F is a folded colum.
Moving the Card from Col 6 to F is impossible: the card won't go 'out of
the screen' on the right, which prevents its center to reach F.
Commit 5ba6d93810 deactivates the drag & drop on read-only fields.
In order to restrict the kanban cards displacements, the `containment`
attribute is used to either restrict the displacement:
- in `o_kanban_view` if draggable
- in the parent if not (to allow the resequence)
The class `o_kanban_view` is too restrictive: when movind the card to
the folded column F, the card must go out of `o_kanban_view`.
opw-803929
Before this commit, the boolean_toggle widget was rendered
but the less contained errors that prevented it from displaying correctly
This was due to commit 9dead7e3d3
After this commit, the widget displays correctly
There might be an issue in the future because of
field_utils.formatBoolean, when this function decides to pass the full options dict
OPW 80782
The field `scheduled_date` on `stock.picking` is used to set the field
`date_expected` on `stock.move`. Since `date_expected` is required, we
should make `scheduled_date` required as well.
Closes#22684
Christophe Simonis