At present there are two methods of sending/receiving electronic
invoices in odoo.
The first, contained within l10n_it_edi, sends and receives the xml via
a verified email known as 'PEC mail', with use of a fetchmail server. It
is no longer the prefered method.
The second, contained within l10n_it_edi_sdicoop, sends and receives the
xml via a proxy hosted by odoo. The proxy server in turncommunicates
with the 'sdicoop' system. This has become the prefered method.
The 'PEC mail' method of sending/receiving invoices will no longer be
supported. The contents of l10n_it_edi_sdicoop will be merged into
l10n_it_edi and the fields, views, methods, and dependencies
exclussively associated with the old 'PEC mail' are deleted.
There are many instances in which a function was provided in l10n_it_edi
that worked through the fetchmail edi system, and was then overriden in
l10n_it_edi_sdicoop. In this case the content of the overriden method
is replaced with the content of the method that has overriden it.
The manifest has been updated to reflect the slight change in the file
structure (the addition of cron.xml and res_config_settings_views.xml to
the data and views folders respectively). The fetchmail dependency has
also been removed from the manifest.
The tests have been updated to match the restructuring of the module.
The i18n files have been altered to include the relevant translations
from the l10n_it_edi_sdicoop module, and the translation terms that are
made redundant are deleted.
closesodoo/odoo#82581
Related: odoo/upgrade#3828
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
With this commit, we use the new (owl) FormViewDialog instead of
the legacy one in the "View Metadata" debug item.
closesodoo/odoo#99532
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since commit fbfc0dc63c that reworked the scss of the KanbanView,
the favorite icon in dashboards was no longer aligned with the
text (for instance, in the Project dashboard). This commit fixes
the issue.
closesodoo/odoo#99503
Related: odoo/enterprise#31033
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
In form views, we want the fields displayed in the "oe_title" div
to take full width. It worked before because we have a rule in
webclient that applies on all almost all kinds of inputs (text,
number,phone...). However, since we wrap fields in a div, those
rules no longer have the wanted effect in our particular usecase.
This commit is a heuristic, but it should solve most of the cases.
It applies on all char fields displayed as title.
Part-of: odoo/odoo#99503
Before this commit, the values in the CoA searchpanel weren't
visible, making it unusable. This was due to the use of bootstrap
classes in /web, which have padding rules that took the priority
over the account customization to make it as thin as possible.
Part-of: odoo/odoo#99503
This class is added automatically on large screens, to better
style the form view to benefit form the available space. However,
the width of dialogs is limited, so it makes no sense to apply
this classname in this case. If we do, those form views may display
an horizontal scrollbar. For instance: in project with worksheets
enabled, create and edit a worksheet many2one.
Part-of: odoo/odoo#99503
Before this commit, if the user multi-edited a field in a list
view, and the widget on that field was legacy, this widget was
displayed in edition in the confirmation dialog. This was because
the "mode" argument wasn't correctly computed in the legacy
compatibility layer. This fix comes with no test as this layer
will be removed in the next week or two.
Part-of: odoo/odoo#99503
website: get_base_url was not working with unprivileged users
Before this commit, when a unprivileged user tried to generate a report
(in sale for example), he could not access to the field website_id on ir.ui.view
An access error would be raised. This commit allows to read the base_url for all users.
Misc: UI for sale order templates
Before this commit, the sale order template information was not clear enough.
Note: these changes were merged into a single commit to ease the manual FW port of
changes in 15.3 for sale_subscription
taskid: 2942621
Since the fields were rewritten in owl, they all have a width of 100% by
default, which is what we want when displaying a field on their own.
In some places, fields are used as part of a longer block of content (eg
unit of measure behind a number). In those cases, we want to display the
field inline, which requires the addition of the oe_inline class in the
arch.
There was also a missing piece of css for the monetary field, as the
previous rule no longer applied because of the slight changes to the DOM
structure.
closesodoo/odoo#99529
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984
It also introduces BS5 utility-classes for font sizes.
Requires:
- https://github.com/odoo/odoo/pull/87448
task-2812594
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#88073
Related: odoo/enterprise#31048
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984
- Converts dropdown into "nav ul li" structure.
- Removing of '.o_burger_menu_user'
- Removing of '.o_burger_menu_app'
- Removing of '.o_menu_sections'
- Removing of '.o_burger_menu_section'
- Some 't-key' not necessary anymore (thx to OWL2)
task-2812594
Part-of: odoo/odoo#88073
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The linter would require flagging "Common" classes with
`post_install_l10n`, which is incorrect but innocuous before tag
inheritance, however it's incorrect and broken with tag inheritance.
Fix to only apply the lint to actual test containers.
Although eventually the analysis should probably run on the actual
classes, so that the "common" classes can be tagged and the children
don't need to be (since they inherit tagging from their parents).
Part-of: odoo/odoo#98814
The unconditional setting made a lot of sense before the new test
tags (95b4f2ab4b) when the test module
was a test tag: filtering the module out of the existing tags would be
difficult.
However since then the tags should only contain "actual" tags,
therefore inheriting tags (and tagging mixins or Common cases) should
not be an issue anymore.
Part-of: odoo/odoo#98814
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_forum
A "page manager" list view will be created for key models in other
apps. This commit moves blog and forum views to a dedicated file to
save some history for the future introduction of that "page manager"
list view.
task-2889981
Part-of: odoo/odoo#98937
*: website_event, website_sale
The "Site" menu will now be organized in 3 sub-areas, the last two being
named "Content" and "This page". The first area contains a link to the
website iframe and the menu editor. The "Content" area will contain
menus to list all contents of the website (page, products, events, ...).
This commit only moves the "page" one, the others will be created by
other commits of this PR. The "This page" area contains elements
specific to the page (html editor, page properties, ...).
task-2889981
Part-of: odoo/odoo#98937
After [1], the frontend website page manager was replaced by a custom
'website.page' list view and, with following commits on this PR, this
view will be used with other website content models records (blog,
event, forum, ...) too.
The goal of this commit is to adapt the pages list code to the new Owl
view system.
Other changes (related to the view's behavior) were added in this
commit:
- "Page list action buttons" are removed, we keep only the action that
triggers the form view of 'page.view_id' in debug mode. Page properties
and SEO dialog can be accessed via the website iframe after clicking on
the page entry in the list. The clone button should be later restored as
part of the main website backend menu, still when viewing the iframe.
Meanwhile, it is accessible in page properties. The 'delete' button is
still accessible via page properties too but the standard "delete"
button when selecting records in the list view will later be improved to
act the same way.
- The "website switcher" on top of the list view (to filter records
which impact one website, generic + specific records) is added as part
of the search view. Limitation: it will only be shown for pages at the
moment.
- A standard "Create" button is added and displays the form view dialog
to create a new content record as with "+ New". Known bug: it only
allows to create on the first website at the moment.
- The click on page/content record should redirect to the corresponding
url/website_url in iframe. This is now achieved via the new possibility
of defining an action on the <tree> tag in the view definition. Known
bugs/inconsistency: depending on the model, this opens in edit mode, in
a new tab, ... behavior to unify in a future update.
- The 'PagePropertiesDialogManager' is removed since the code is in Owl
and we don't need page properties dialog on the list view anymore.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2889981
Part-of: odoo/odoo#98937
A "page manager" list view will be created for key models in other
apps. This commit prepares a convention that all other apps will follow:
a dedicated file for the views related to this feature, named
"website_pages_views.xml".
task-2889981
Part-of: odoo/odoo#98937
This commit adds the possibility to use a grid to move and resize
columns inside some building blocks.
More precisely, for the majority of the building blocks having columns,
it is now possible to toggle between the current layout (= normal mode)
and the grid layout (= grid mode). The grid mode can be triggered in
two ways:
- by using the "Grid" button in the options (when available),
- by dragging a column using the move handle.
The toggle places the different columns in the grid as close as
possible as how they were placed in normal mode.
The normal mode is toggled back by clicking on the "Cols" button (when
available).
Since the move handle is now used to trigger the grid mode, the columns
in normal mode are now moved using the arrows.
NB: to avoid any confusion with the word 'column' in the explanation
below, the BS column will be called 'grid item' and the grid column
will be 'column'.
When in grid mode, the building block is a grid with 12 columns and a
number of rows which depends on the height of the grid items.
This mode offers the following functionalities:
- Moving a grid item:
When a grid item is dragged, it can be placed anywhere in the grid. If
it is dragged towards the bottom, new rows are added in the grid to
increase its height and to place the grid item lower. These added rows
are removed when it is dragged towards the top.
A grid item can also be placed over an other item (-> they can overlap)
and their order can be changed using the two new buttons to place an
item in front of/behind all the others.
A grid item can be moved from a grid to another, and also from a grid
to a building block in normal mode.
- Resizing a grid item:
A grid item can be resized vertically, horizontally and diagonally with
the help of the grid. When resized towards the bottom, new rows are
added in the grid and they are removed if it is towards the top (like
with the drag and drop).
- Adding elements:
The "Add Elements" option allows the user to add as many images, text
blocks or buttons as wanted in the grid.
Inner contents can still be dragged and dropped inside a grid item.
- Changing the padding of the grid items:
The padding option allows to change the vertical/horizontal padding of
all the grid items at the same time.
- Mobile view:
When in mobile view, the grid items are not in a grid anymore (the
display is back to flex) but they keep their grid properties. They
cannot be resized, nor dragged and dropped but they can be moved using
the arrows. By moving this way, it does not impact the desktop view.
task-2825241
closesodoo/odoo#93144
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now trigger an UI update for all the options when clicking on the mobile
preview button. This is at least important for the next commit in this
PR to update the visibility of the different overlay elements as some
will be shown in desktop and some other on mobile.
task-2825241
Part-of: odoo/odoo#93144
Co-authored-by: qsm-odoo <qsm@odoo.com>
When adding an option, using data-select-style with a CSS variable in
data-css-property does not work. This commit adds the support for the
use of these variables.
task-2825241
Part-of: odoo/odoo#93144
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This PR adds some trigger to make sure that all python request
is correctly finished. This is needed because an unfinished python request
makes a traceback appears on runbot.
opw-28835921
closesodoo/odoo#99475
X-original-commit: 7a98b59b36e9e2cf1816b73ebc3be5de58e054c2
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*: website_slides
After [1], the website "new content" dialogs were replaced by formView
dialogs of targeted content (blog, slides, product,...).
The goal of this commit is to restore the "course layout image preview"
on the "New Course" dialog for the "channel_type" field (as on the old
frontend dialog).
Remarks:
- The field was added on 'website' module so it can be used on other
website related modules if needed.
- Some CSS related to the old form was removed in this commit too.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
closesodoo/odoo#96346
Related: odoo/enterprise#29922
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
This commit adds an "on scroll" option for animations. In addition to
being triggered when they appear in the viewport, animations can now
also be triggered based on page scroll.
Animations are also improved in this commit, we add "intensity" option
and the dropdown with the list of animations has been split by adding a
new dropdown to choose the "direction" of the animations.
task-2862761
closesodoo/odoo#94119
Related: odoo/upgrade#3858
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the height of the element to be animated was
calculated without the padding of the element. That was wrong as the
padding needs to be considered part of the element.
task-2862761
Part-of: odoo/odoo#94119
Steps to reproduce:
- Install purchase
- Go to Settings and activate `Variant Grid Entry`
- Create a new Requests for Quotation
- Add a customer and add a product that has a variant min 2 variant
- Wizard should ask for the variant
- Select 1 variant by increasing quantity in the grid and confirm
- Confirm order
- Add again a product variant with the wizard
Issue:
Price unit is not set on the new line.
Cause:
In `_onchange_quantity` (triggered by the purchase_product_matrix
module), we do not update price unit if order line
is in state `purchase` or `done`.
Solution:
Replace condition to not perform `_onchange_quantity` if order line
has an invoice line.
opw-2956755
closesodoo/odoo#99522
X-original-commit: 8f92146b2d4996be724213345567291f045aad85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Install pos_sale module
- Create a product and set it as available in POS
- Create 2 variants and set a weight for each variant
- Open a POS session and make an order with one of the variants
- Go to the Sales -> Reporting -> Sales and select view pivot
- Set Gross Weight as measure
Issue:
Weight for ordered variant is set to 0.
Cause:
Sales Analysis is an SQL view and it use product template in instead
of product product to get the weight value.
opw-2956457
closesodoo/odoo#99518
X-original-commit: 3a2f845375400623e4cabba57e66373abe9d0b85
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Before this commit, the `/web/static/tests/views/helpers.js` was only
imported in the "desktop" qunit test suite but unavalaible for the
mobile one.
This commit adds it in the `web.test_assets` bundle to be available in
all tests suites.
closesodoo/odoo#99498
X-original-commit: 2875f43da28d01f837c1ee53f8cadd21e169b612
Related: odoo/enterprise#31029
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, `BooleanToggleField` and `BooleanField` are 2
distincts components. However, they are some attributes in common.
Also, there is an inconsistency between the both components, in the
boolean field, a `onChange` method is defined but not in the other one.
This commit changes the `BooleanToggleField`, this one will inherit to
`BooleanField` to have the attributes in common and override the ones
which are different. Also, the `onChange` method will exist in the
both components.
closesodoo/odoo#99492
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before in BS4, the table used the `$table-head-color` SCSS variable to
color the header of table. This variable doesn't exist anymore on BS5.
In the commit of the BS5's merge, we have replaced the old value by
a value calculated with the color contrast in the case of the list view
it wasn't the right fix, so in this commit we restore the original value
like it was before the merge of BS5.
Note:
In BS4 branch the result is `#212529`:
```scss
$o-gray-900: #212529 !default;
$o-main-headings-color: $o-gray-900 !default;
$table-head-color: $o-main-headings-color !default;
.o_list_view .o_list_table thead {
color: $table-head-color;
}
```
In BS5 branch the result is `#00000`:
```scss
.o_list_view .o_list_table thead {
color: color-contrast(opaque($body-bg, $light));
}
```
closesodoo/odoo#99488
Related: odoo/enterprise#31026
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
plus_report_line_ids and minus_report_line_ids have now been replaced by plus_report_expression_ids and minus_report_expression_ids on tax templates.
The test was failing locally but not on runbot, because it was missing the post_install tag.
closesodoo/odoo#99462
Signed-off-by: Laurent Smet <las@odoo.com>
Connect in your browser to a db on runbot with mail installed and wait
until the runbot put to sleep the db. After a while, a new request to
get im_status will be sent and nginx responds to it with an error 404
and an invalid JSON response. A traceback with a particularly bad
message is then shown. Here we improve the traceback message.
closesodoo/odoo#99430
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For reading one2many fields, we make 2 queries (in batch):
- One to search "id" the comodel
- One to read <inverse_field> in the comodel to group lines by record
(sometimes, this one is bypass because the cache already contains the information).
In many cases (> 80% of cases in our tests) we read a one2many field on
a single record. In that case, we can avoid the second query completely
(grouping all lines on a single record is trivial).
This reduces SQL queries by about 0.8% on all-install runbot builds.
closesodoo/odoo#99415
Signed-off-by: Rémy Voet <ryv@odoo.com>
For non-stored computed fields, `_modified_triggers` will traverse the
tree (at the cost of extra queries) only to know which record to
invalidate in cache. But in most cases, these fields have no data in
cache, so they can be ignored from the start, which allows us to prune
entire subtrees from the merged tree.
By example:
With simple write on `show_operations` of one `stock.picking.type`, the
`_modified_triggers` will fetch every ids (from database) of `stock.picking`
and `stock.move` related to this `stock.picking.type`
(For `stock.move`, it is because of the
`show_operations = fields.Boolean(related='picking_id.picking_type_id.show_operations'`))
In that case, there isn't any data of `show_operations` (`stock.move`)
in cache, then there are nothing to invalidate and
the `_modified_triggers` cost
is high (extra queries/processing) for nothing.
Then we cut parts of the tree when we know that
they won't invalidate anything (=> if the cache is empty for the field).
Also refactor the way to merge trees to be more efficient.
Performance improvements:
- For all tests at-install done by the runbot, we gain -+ 3.5% of
queries.
- In the example above, we reduce the number of queries (potentially
bottleneck queries in large DB) from 7 to 4.
- In term of CPU (without counting time in SQL), the new version is -+
20 % faster (on install of stock,purchase,mrp and with
--test-tags=/stock,/purchase).
closesodoo/odoo#76322
task-2780812
closesodoo/odoo#99274
Related: odoo/enterprise#30951
Signed-off-by: Raphael Collet <rco@odoo.com>
*: sale, sale_product_matrix, test_sale_product_configurators,
website_sale_product_configurator
Previously, the product configurator used a transient model and a
corresponding wizard to configure products. In subsequent refactorings,
the product configurator was merged with the optional product modal, and
because this feature also needs to work in the eCommerce, all the
features are available in the modal which doesn't directly depend on the
form view.
Since the modal is capable of doing everything on its own, the form view
and its corresponding transient model are no longer necessary, the m2o
widget can just open the modal directly instead. The only thing that was
missing from the modal was the ability to selectively display the
optional products depending on the configurator mode (we don't want to
show optional products when we're configuring an existing product).
This commit refactors the product_configurator_widget so that it can
open the product_configurator_modal directly without the need for an
intermediate form view, and removes said form view and the corresponding
transient model.
Tours and tests have been adapted to have their selectors always match
the modal.
closesodoo/odoo#99219
Related: odoo/upgrade#3844
Related: odoo/enterprise#30860
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) Invoicing wizard refactoring
* reduce the use of context in the business logic,
store the orders being invoiced
* factorize invoice creation values, using the correct method from
the sale.order model
* switch from default fields to computed fields, and avoid computing
unnecessary fields when the wizard is opened to invoice multiple
orders together (most fields are only used for down payments)
* Rely on python constraints instead of error messages scattered
accross business methods to notify the user that the invoice cannot be
created.
* Clean the code to make it easier to follow, understand and maintain
2) Distinguish Down Payment Invoice lines from standard ones
(with a dedicated field)
Allows to stop relying on the dumb property,
not specifically reliable, e.g. if the down payment product is modified
in the settings after down payments orders were already created.
closesodoo/odoo#98600
Related: odoo/enterprise#30653
Related: odoo/upgrade#3799
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Despite recent improvements, the method is still quite confusing,
especially with the 'force_confirmation_template' parameter.
Splitting this parameter logic in a split method giving only the
confirmation template when needed.
Part-of: odoo/odoo#98600
Prior to this commit there was no way of removing an automatically
claimed reward from a website order, since it would always get claimed
right after the update to the cart.
TaskId-2951413
closesodoo/odoo#99023
Related: odoo/enterprise#30794
Related: odoo/upgrade#3820
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
dbkosky