Popover has some style by default (eg. padding), but it is not always desirable
(eg. if the content has a scrollbar, having padding to the right of the
scrollbar is not good).
-> Add a class to allow overriding the default style in the legacy popover.
closesodoo/odoo#73655
Note: the new popover already has this prop.
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some characters were overlapped in the printed receipt or receipt sent by email because the library html2canvas doesn't handle well the css wrapping (e.g. in the German localization) by default.
closesodoo/odoo#73594
X-original-commit: debab4026f4f4bf380cba3bcb65c223cc4e1bbc9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Right now, if we want to add a quiz to the event track, we need to
create it from the m2o field available in the form view. But it is
not very intuitive as user will have to select 'Create and Edit'
option from the m2o drop-down. Quick create is not really helpful
here. Also, trying to add question for the quiz will pile up the
modals which looks messy.
With this commit, in the event track's form view, we:
- Remove the m2o for `quiz_id` (from the track form view, not from model)
- Introduce "Add Quiz" header button, which redirects user to form view
of the quiz, with no option to create new quiz directly as only one quiz
should be linked to quiz. Also, once the quiz is added, this button will
be hidden.
- Introduce new stat button "Go to Quiz", which redirects user to the form
view of quiz (again, does not allow creation from the same reason). This
button is visible only if the quiz is already added for the track.
Apart from that, re-arrage the quiz form view `event_quiz_view_form` by
putting 'Event' and 'Event Track' fields on the same line, and we utilize
the same view while creating / updating quiz from the track.
Note:
Since the creation of quiz is now done in its own form view (with action button
"Add Quiz" from track's form view), we are passing the default `event_track_id`
while creating the quiz. It means that we don't need to compute it anymore.
Instead, now we need to compute the `quiz_id` on the track, based on the
`event_track_id` field alreay set on the quiz.
So, we introduce new One2Many `quiz_ids` field to compute the `quiz_id` on the
track, and we remove `event_track_ids` from the quiz. Basically, the logic of
setting `quiz_id` (on the track) and `event_track_id` (on the quiz) is inverted
with the commit, and the demo data is updated accordinlgy.
TaskID-2486552
closesodoo/odoo#70067
Related: odoo/upgrade#2522
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When confirming a SO, if the costing method of a product's category is
not `Standard' and if the SO's currency is different from the company's
currency, the cost of the product won't be converted to the SO's
currency
To reproduce the error:
1. In Settings, enable:
- Margins
- Multi-Currencies
2. Create a product category PC:
- Costing Method: FIFO
3. Create a product P:
- Product Type: Storable
- Product Category: PC
- Sales Price: 200
- Cost: 100
4. Update P's quantity to 1
5. Create a pricelist PL:
- Currency: EUR
6. Create a SO:
- Pricelist: PL
- Order Lines:
- 1 x P
7. Add field "Cost" to the tree view of the order lines
- The value is correctly converted
8. Confirm the SO
Error: The cost of the order line is now 100€. This is actually the USD
cost, it should be converted
This code applies the same conversion as when the cost method is
standard:
https://github.com/odoo/odoo/blob/8a8ff03f6111f377bcd9c2b0f584c450b82a4182/addons/sale_margin/models/sale_order.py#L42-L48
OPW-2563442
closesodoo/odoo#73786
X-original-commit: 04e4cd91637c836b4d856b8638d88c5cf1770421
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Codice Fiscale can be 16 length (letters + digits) for physical people.
Codice Fiscale can be 11 digits prefixed or not with 'IT' for companies.
An error is raised if the codice fiscale is not saved in the correct format. When registering to l10n_it_edi_proxy, we try to normalize the Codice Fiscale if possible.
Also, when entering the vat in the partner, the Codice Fiscale is automatically set normalized.
closesodoo/odoo#73774
X-original-commit: 3741e141e5a468b8ce0413f4f7d7fc05751b0c1b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: bfr-o <bfr-o@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider an expense E paid by the company
- Validate E and post journal entries
Bug:
Two journal entries were created:
1. Outstanding payments (debit) / Account Payable (credit) as draft
2. Expense (debit) / Outstanding payments (credit) as posted
With the this fix:
Only the second entry is created and posted
This reverts commit 25ac51e01a2084afd7a4d5e9c4c87a50ea787b93.
opw:2510663
closesodoo/odoo#73715
X-original-commit: 3add44d462deebb2b7600d0bd2d86a4af8b2ab4e
Signed-off-by: William André (wan) <wan@odoo.com>
In some specific cases, a serialization error can happen on the account
move if it's not a move to cancel. If it happens, the full process
starts again for that move, which includes the requests sent to the
PAC in MX accounting.
It will send 2 CFDI files for the same invoices and the PAC will
interpret that as 2 different invoices, which is a problem.
This fix ensure that the concerned account moves are always locked
to avoid this kind of issue
opw-2489399
opw-2529134
closesodoo/odoo#73789
X-original-commit: bcc4934f80bea4ce70b9edfb22fd40030c5f0063
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This is already there before refactoring in saas-12.4
you can check here https://github.com/odoo/odoo/blob/saas-12.3/addons/l10n_in/models/account_invoice.py\#L73
also add id in group by becouse if there is invoice line have same product,qty and uom then qty is wrong.
For example:
we have there is the same product with the same quantity and UOM like
```
Product | quantity | UOM
=========================
Mobile | 2 | Unit
Mobile | 2 | Unit
```
then tax line is not split so report count qty is 2
opw-2563120
closesodoo/odoo#73803
X-original-commit: 49e6bc9c499a511d479282dc67c1560e1c6bae5b
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: Jigar Vaghela <jva-odoo@users.noreply.github.com>
At the closing of the POS, we try to reconcile
all lines involved in the closing.
If for any reason, a line is already reconciled
(I.E. Debit=0 and Credit=0 is considered as reconciled),
the closing fails because we cannot reconcile an already
reconciled line.
OPW-2602410
closesodoo/odoo#73783
X-original-commit: 4fd374b3f97eee1e706842ce1e28d0ad7a50315a
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
AttributeError: 'HttpRequest' object has no attribute 'is_frontend'
e.g.: when we call request.redirect in ensure_db(), before that the _dispatch
method check if it is a is_frontend route or not.
closesodoo/odoo#73759
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Despite that Werkzeug documentation specify:
'location (str) – the location the response should redirect to.'
Werkzeug support URL as location.
So now Odoo will support URL for request.redirect as argument too.
This commit closes#73729
Re-introduce after discussion with AL the function that allow to specify
a custom placeholder for a specific model.
It has been removed because no more used since we use avatar mixin for
res.users and res.company. But it doesn't means that each model should add
his own mixin and controller and ... Keep it simple!
Use it for product and product template to have a default placeholder more
representative of the model.
Courtesy of xlu-odoo for this design
opw-2513801
closesodoo/odoo#73576
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The journal needs to access the payment acquirers to determine with payment method is still available.
Since the acquirers can't be accessed only for admin users, an accountant doesn't any right to read them, and then, an access error was raised when opening the journal form view.
Also, the 'payment.acquirer' was accessed from the 'account' module instead of being overridden in 'payment'.
closesodoo/odoo#73761
X-original-commit: 7b4580c3756657c902eceb9840984dde76429dcd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When using drag&drop for adding elements to a product's page through
the website edit mode, users sometimes find the feature confusing to
use. Two examples of said confusion can be seen here:
- https://dashboard.userbrain.net/shared/qwl65bqlk6jg?t=404
- https://dashboard.userbrain.net/shared/k796mnj95pow?t=258
The suggestion for improvement was to reduce height and opacity for
the top and bottom droppable zones (available on all products), and
make any element not explicitly dropped in those zones go to the
zone below the product, available only on the product's own page.
This behaviour is extended to be more generic and is applied when
a dropzone has the class oe_structure_not_nearest, which excludes
it from the nearest search, unless the element is dropped explicitly
in a zone that has the class oe_structure_not_nearest.
task-2581641
closesodoo/odoo#73580
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.
Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.
If you want to have more time to deliver than one day, security lead
time are there for it.
However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0
It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.
closesodoo/odoo#73737
X-original-commit: f988b7629f8f54e8e3f48bf76e6af9d97b4f47da
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previously, push_state events triggered from withing window actions
inside dialogs would bubble push their state into the URL even while
within a dialog, this is undesirable as this can cause the URL to become
invalid (eg by pushing the id of a record from an entirely different
model)
This commit fixes that by simply checking whether we are in a dialog
within the adapter before calling pushState.
task-2602458
closesodoo/odoo#73720
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, click on "Schedule activity" in the activity view
would open a dialog in which the search view is the default one on the
current activity view model.
With this commit, we make the dialog use the same search view as the
activity view.
Done to help with the task 2502339
closesodoo/odoo#73697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: test_website
In a previous commit, the new services and environment were made
available in the frontend. This now allows errors to be handled by the
new error service, and makes the legacy crash manager redundant. This
commit removes it.
Part of #72675
Related: odoo/enterprise#19258
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In previous commits, all references to the legacy notifications and
notification service have been removed, this commit removes the now
unused legacy notification and notification service
Part of #72675
When writing the new webclient, the notification service was rewritten,
and all of its uses in production code were changed to use the new
services, however, some tests were still reliant on the old notification
service.
This commit removes references to the legacy notification service so
that we can be one step closer to removing it from the code base.
Part of #72675
*: http_routing
When rewriting the webclient, a new environment was created, as well as
a new type of service and a new mechanism to start those services. This
environment and the services that go with it were not made available in
the frontend however.
This commit adapts the setup code for the frontend's root widget (and
the website specific equivalent, WebsiteRoot) so that the new
environment exists, and some of the calls to the legacy services are
redirected to the new services. The point is to allow removing some
legacy services whose code is currently only needed by the frontent
because of the lack of availability of this new env and services
Part of #72675
With the introduction of the new webclient, we introduced a new way to
create and interact with registry using categories. This alleviates the
need to explicitly export and import registries.
This commit converts the public root widget's custom registry to use the
new registry to avoid code duplication and having multiple diverging
implementations
Part of #72675
This commit adds a sanity check to the part of the ORM that uninstalls
module data, as a recap, here's how module uninstallation works:
- We fetch all data (ir.model.data) that corresponds to the module being
uninstalled (`WHERE module='my_module'`)
- We divide this data according to its type (ir.model, ir.model.field,
constraints, etc.)
- We fetch the corresponding records to each type, we delete them in a
certain order (e.g. ir.model.field before ir.model) and then finally we
delete the ir.model.data as a last step
The data is deleted in batch for maximum performance, if one of the data
cannot be deleted however, we perform a binary search until we find the
culprit(s) and we store these culprits in a list of undeletable_ids.
At the end of the process, we delete all ir.model.data **except** for
the ones that are undeletable, however, it is possible that because of
the multiple-step procedure, an undeletable ir.model.data could have
become deletable.
Imagine that an ir.model.field cannot be deleted, its module data id is
added to the list of undeletable_ids, however if later on its ir.model
is deleted successfully, the ir.model.field is dropped because its table
is dropped, in this case the ir.model.data becomes deletable, but since
we simply ignore it at the end of the process, we potentially end up
with orphaned xmlids.
This can be problematic when we reinstall the module and uninstall it
again, as the system does not expect an orphaned xmlid, will completely
crash and prevent the 2nd uninstallation of the module.
This is the case with CRM and its
crm.lead.scoring.frequency.field.field_id field, its ir.model.field
cannot be deleted because the name field (and display_name) of the same
model depend on it, so it is left as is, then further down the process
the entire model is deleted and as a result so is all of its remaining
fields, however the ir.module.data for the field that could not be
deleted remains.
opw-2575592
closesodoo/odoo#73668
X-original-commit: 75697934b34df882ec03595b876a8a6dadcef4c5
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The value of the related field should be cleared:
- If the other record no longer exists.
- If the target value is undefined.
This might fix hard to understand bugs, such as task-2410314
closesodoo/odoo#73743
X-original-commit: f1ff90bf48f22a4bed299abeb8e1d415cdfab9e0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
By luck the situation never happened before, but it is legitimate to handle it.
A future commit will actually introduce the possibility of the issue happening.
closesodoo/odoo#73741
X-original-commit: 62fa7c94724b8144d21ce577aa2f04d5d837c053
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since their convertion to "snippet" options with [1], the media options
were not handling previews correctly anymore, but also were recoding
their entire logic for each of the options instead of using generic
methods like selectClass or selectStyle.
One example of a bug was that previewing the 25% width option on an
image, not enabling it and saving the editor forced the image to a fixed
px width (its original one). Changing that image to another would keep
that wrong fixed width.
Note: this reveals that selectClass and selectStyle need more parameters
to handle all of this correctly. Most was added as a specific override
for these features but it could be handled even more generically.
[1]: https://github.com/odoo/odoo/commit/d934b81aaae8d68b5579d1489b1fbe8ea347b4ed
Related to task-2578242
task-2577848
closesodoo/odoo#73734
X-original-commit: f59affcdfe9529645a02680214f3d7d96ebacf6e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Change dependencies of a few computed fields in order
to avoid triggering them wrongly when migrating.
Also add a company check on the constrains blocking
deletion of payment method lines linked to an active
acquirer.
closesodoo/odoo#73731
X-original-commit: e94b4f09a4c5664360594bee6475cb2ef756be47
Related: odoo/enterprise#19663
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Overall UI review of the fleet app.
Also changes the behaviour of shared fields between vehicles and vehicle
models.
Task ID: 2468228
closesodoo/odoo#72943
Related: odoo/upgrade#2601
Related: odoo/enterprise#19356
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Making a dynamic domain with a `allowed_xxx_ids` field is a bad idea
when the domain doesn't filter out the most of records. It can create a
performance issue, if the `allowed_xxx_ids` contains too much ids
(for 70K by example), then a lot of data will be exchange to/from server
for each onchange (500Ko, > 1 sec) which slows down all the form views.
Change it into a static domain, which slows down a little the
search of the picking but the onchange becomes very fast. Also the JS
won't parse anymore a huge `allowed_xxx_ids` fields (the form becomes
smoother).
task-2558097
Making a dynamic domain with a `allowed_xxx_ids` field is a bad idea
when the domain doesn't filter out the most of records. It can create a
performance issue, if the `allowed_xxx_ids` contains too much ids, then
a lot of data will be exchange to/from server for each onchange which
slows down all the form views.
task-2558097
During the creation of the second warehouse,
a warning popup to tell that it will activate also the
Storage Locations setting even if this one is already activate.
Only raise this warning if the is Storage Locations not activate yet.
task-2558097
- Create 2 invoices (or 2 bills) but let them in draft
- In invoices list view, select all invoices
- Execute Action > Resequence
Resequence wizard will not show.
It comes from a template in resequence renderer using account move name as t-key
that silently crashes because both draft invoices have the same name ("/").
opw-2590273
closesodoo/odoo#73724
X-original-commit: 3e6b7dfd4854069724dde2df43ab2eb7d850e9b5
Signed-off-by: William André (wan) <wan@odoo.com>
In the first days of the month, many of the previous month's invoices
could still to be posted since the lock date is not yet set to the last
day of the previous month. To avoid the user having to modify the
default accounting date on each such bill, detect whether the conditions
allow the invoice to be posted on the very last day of the oldest
possible month, and then adapt the accounting date to the last day of
that month.
task-2575560
closesodoo/odoo#73701
X-original-commit: 2c5c1a4478505688f35e47ca20e7977b134d0fdb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When creating the l10n_fr chart of accounts, the tax payable and tax
receivable accounts of the tax groups were missing, and this had other
effects like a missing tax report entry.
This commit fixes the issue by setting the property on the template,
like in others modules (e.g. l10n_be).
closesodoo/odoo#73700
X-original-commit: 886efb07bd8775ebc969ee44343b8aaba333742f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Bug
===
Since 478068c829 we wanted to use the
Odoo redirection function everywhere.
But this function work only if we redirect the user to the same site.
The mail plugin need to redirect outside of Odoo and so we can not use
this function.
closesodoo/odoo#73698
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
A domain used in a ir action in mrp was syntaxically incorrect.
Strangely enough, it was nonetheless accepted by pyjs. However, pyjs
was recently remade, and is now stricter, so evaluating this domain
correctly throws an error.
This commit simply fixes the domain.
Task ID: 2601818
closesodoo/odoo#73670
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
Since cc67988241 a new option is available
for the reference widget.
When the new option "model_field" is used on a reference field in a list
view, after saving and then editing, we need to change the model to be
able to select the records
Links
=====
Task-2127615
See odoo/odoo/pull/46304
See odoo/enterprise/pull/7701
See odoo/upgrade/pull/848
closesodoo/odoo#46304
Related: odoo/upgrade#848
Related: odoo/enterprise#7701
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
A new module "Event Social" will be added in the enterprise PR. This
new module will use a new template type, the "Social Post Template"
adding one more column in the communication tab...
We want to have only one column to select the template (Mail, SMS or
Post template) and therefor we need to use a reference field.
Technical
=========
As we can not set a domain on a reference field, we added a context key
and in the `_name_search` of the `mail/sms.template` we filter with the
domain we want if the key exists.
Links
=====
Task-2127615
See odoo/odoo/pull/46304
See odoo/enterprise/pull/7701
See odoo/upgrade/pull/848
Ajroo