Issue: When closing a PoS session, the user can Cash In/Out of the
register but it requires Accounting/Billing group or Purchase/User
group. However with Purchase/User group, there was an access right
error (not allowed to create account.move.line
Steps to reproduce :
1) Install PoS Module
2) PoS > Your Shop > Settings and enable Advanced Cash Control
3) As administrator and in debug mode go to
Settings > Users & Companies > Users
4) Remove Accounting, Inventory and Purchase group of [User A]
5) Log in with [User A], open a PoS Session, close it, and in Cash
Control form, click Cash In/Out
6) Remove or add money
-> Access right error, you need to be Accounting/Billing or
Purchase/User
7) As administrator, add the User group to Purchase for [User A]
8) As [User A], click Cash In/Out, removed or add money
-> Still access right error
Why is that a bug:
The first warning asks us to give the Purchase/User group to the user
if we want to Cash In/Out but even when doing that, the access rights
are still not enough to allow the creation of the entry
opw-2611298
closesodoo/odoo#75156
X-original-commit: a28c9c1dd773f26151d6734d476e7f8d5a3d971b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
All background-color classes (bg-XXX) were defined before the color
combination classes. Except for the Odoo colors ones (bg-o-color-X)
which were defined after. That inconsistency was not a real problem
before as those two type of classes could not be combined but this will
change in the future.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
Currently, track proposals are submitted through an HTML form with an "action"
attribute, which requires that the associated route returns a redirect
response.
However, redirecting to a different page comes with its set of issues.
Indeed, when the track is submitted, the user that just submitted the track no
longer has access to it (because it's not published).
In 157a1d77058da97954edc9efba6ab9f43c7d13a2
We attempted to resolve this issue by checking if the partner set on the track
is the same as the partner set on the website.visitor record.
However, this does not handle every use cases since when specifying different
contact information, we create a different res.partner, making the check fail.
In this commit, we rework the track proposal submission to use AJAX instead.
This allows to dynamically show a "success" message while staying on the same
page, removing the need for redirects and "complex" ACLs checks.
While the main goal of this change is to avoid the need for that security
check, it also has a few additional minor advantages:
- Slightly faster UI, as you don't have to wait for a full page reload
- Fewer routes to maintain
- Easier and more thorough validation handling (current code returns a ugly
error page if validation fails server-side)
- Code makes a bit more sense, as we don't have a template that varies from
"form" to "success message" depending on the presence of a "track" variable
Task-2618734
UPG PR odoo/upgrade#2722closesodoo/odoo#74848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does not change anything, it simply applies linting on the track
proposal JS files to match our current guidelines.
This is done as preliminary work since we are going to change the way track
proposals are submitted (from POST request to ajax POST).
Task-2618734
The editor sometimes compare CSS values, in particular in the
selectStyle method where a given style is not applied if it would have
no effect (e.g. applying an inline pink background-color is useless if
the block is naturally pink because of CSS rules). That comparison
failed when it was comparing 'var(--XXX)' and 'YYY' as 'var(--XXX)' was
not processed as the CSS variable 'XXX' to be read.
Related to task-2599770
closesodoo/odoo#75201
X-original-commit: 22b5d90539895bb7c2b14de4abbb2d7d978a6f79
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The video linked to the "How to create your own piece of furniture" slide has
been removed from YouTube.
This commit simply updates the demo data with a new video.
Task-2621278
closesodoo/odoo#74899
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 369075f
The slide.slide embed_code field is a HTML field.
Meaning that when it's used in a HTML block to embed content, it needs to be
correctly t-outed, the current t-esc code will just print HTML.
Task-2621278
In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:
- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)
This was solved in pdf.js whith this commit:
https://github.com/mozilla/pdf.js/commit/8805614a03
And this PR is backporting that commit in 12.0 version up to master.
opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311
closes#75020closesodoo/odoo#75057
X-original-commit: d3feb26c8923cfde60894058f06dc2c2a8be05f5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit fixes the display of the status bubble inside of the status
button on the project form view. It wasn't visible since the recent css
changes.
Closes: odoo/odoo#74610
Task ID: 2615293
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previous implementation always updated *current website*, which is not
always the same as the value from `res.config.settings`.
---
opw-2623007
X-original-commit: d66d44db031be76403ce7c01616e334ef196fd03
In a multi-company environment, with l10n_es_reports installed,
a tab was added to the invoice form view.
That tab was also visible in other localizations as well,
which was not desired.
closesodoo/odoo#74701
Task: 2611256
Related: odoo/enterprise#20042
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, Scrap move was copied to new record on
duplicating Scrap order.
With this commit, Scrap move is not copied.
closesodoo/odoo#75180
X-original-commit: a725fed5168a140cb631732c3ffc994cd90b02b2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce:
- create a sale order with an event registration,
- on the event, the number of attendees is well computed
- cancel the sale order
- on the event, the number of attendees is still the same as before
Cause of the issue
There was no specific action for canceling a sale order linked
to an event registration
Solution
Add a action_cancel method which cancel also the sale order lines when
canceling the sale order
Also add a test to ensure the flow will not break in the future
opw-2576790
closesodoo/odoo#75174
X-original-commit: 9dcfae2234b1f45da1837c519b54926522cfa070
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
EHF3 is the Norvegian standard for Peppol. This module generates xml (based on BIS3 with NO country profile) to be submitted on the Peppol network.
TASK ID: 2528203
closesodoo/odoo#70679
Related: odoo/enterprise#20050
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Overriding '_is_embedding_to_invoice_pdf_needed' is unnecessary since the default value is already 'False'.
- When calling '_check_move_configuration', we should not ignore the errors returned by 'super'
the deleted commit is not needed since it's already called in
`_procure_orderpoint_confirm`.
The logs are usefull to check whether we have progress on repeating the
scheduler that gives timeout error.
closesodoo/odoo#75146
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
How to reproduce the problem:
- Install the sale_coupon module
- Sales -> Products -> Promotion Programs
- Create a promotion with "Fixed Amount" discount, "Apply on current
order", with Based on Products as "Name = Large Cabinet"
- Create a SO with 3 Large Cabinet.
- Modify the quantity on the new reward line: the price unit became 0.
A client should be able to manually change the discount quantity.
That was not possible before due to the fact that the reward products of
a promotion are saved in the DB with a list price of 0.
As the reward generation handles the job of computing the correct
unit price on a reward SOL, that unit price is simply re-used when
the quantity is changed.
Also corrects the case where a Free Product is different from the
Rule Product(s): with the promotion
"Buy 1 Product A, get 1 free Product B", if the Sale Order has
3 Product A, for example, the promotion will offer only 1 Product B,
while it should offer 3.
opw-2522604
closesodoo/odoo#75143
X-original-commit: 97b78e8982f1e143350521bdee3c280618fb1846
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>
We introduce here an incomplete implementation of the new ControlPanel.
The idea is to allow the rewritting of the client actions that do not
use the search view but only the breadcrumbs or the button zone...
The full implementation of the new ControlPanel will be merged when the
new search infrastructure is ready to be merged.
closesodoo/odoo#75083
Related: odoo/enterprise#20231
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- fields/format.js has been renamed into fields/formatters.js
- fields/parsers.js has been introduced
- parsers and formatters from l10n/numbers have been moved to
fields/parsers.js and fields/formatters.js
- same for parseCurrency and formatCurrency, and they have been
renamed into parse/formatMonetary
- humanReadable option is now a boolean, no longer a function
- formatPercentage implementation has been simplified thanks to
that reorganization
- tests have been reorganized accordingly
Reintroduces a registry "formatters" that contains util functions for
formatting field values. Those formatters take the same parameters:
value, field, options.
We move some util functions from the legacy file math_utils.js to the
file arrays.js. Those funcions will be used in the new implementation of
the pivot view.
We prepare the rewritting of the search components for the new weclient:
we rename some legacy templates to allow the new components to use the
natural template names.
Before this commit, the confirmation dialogs displayed by the new dialog
service had the size "modal-lg" (default set on the Dialog class).
We set their size to "modal-md".
How to reproduce the problem:
- Install the Fleet app.
- Create a user that has access to 2 or more companies (e.g. Mitchell Admin).
- Log in as this user. Go to fleet -> Vehicles -> Vehicles Costs/Contracts/Fuel Logs/Services Logs
- Uncheck one of your companies.
- The user still has access to the fleet of the other companies, even if they are unchecked.
Cause of the problem : missing record rules
Solution : added multi-companies rules
opw-2518188
closesodoo/odoo#73925
X-original-commit: 41828bc22b5cf663b96196371f412ad2bfbbfb22
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Whenever using the `getPowerboxElement`, it is possible to have a
null node.
closesodoo/odoo#75163
X-original-commit: 03d7021b251d31cfda055c6ffe9684fad191903c
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
When a color combination was used as "color" (base case) for the menu,
the menu background in the boxed template, the footer or the copyright
section, it was not properly marked as selected in the color palette
widget of the editor panel.
Related to task-2599770
closesodoo/odoo#75157
X-original-commit: 04c476a11a084c825725cae89e104e9f205c685b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The term was untranslated
Export missing stock terms
Forward-port of fb0383f8c1d4ef5817cf67
closesodoo/odoo#75155
X-original-commit: 4a0d1dfd2b48ecad107a687093ac34a3b0d67d60
Related: odoo/enterprise#20247
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When combining a reordering rule, the 3-steps manufacture and
by-products option, the picking from the post-production to the stock
will not contain the residual products produced by the MO (by-products)
To reproduce the error:
1. In Settings, enable:
- By-Products
- Multi-Step Routes
2. Inventory > Configuration > Warehouse Management > Warehouses, edit
company's warehouse:
- Manufacture: 3 steps
3. Create 3 products P_compo, P_finished, P_secondary
- P_compo is consumable
- P_finished and P_secondary are storable
- Routes of P_finished: Manufacture
4. Create a reordering rule for P_finished:
- Min = Max = 1
5. Create a BoM:
- Product: P_finished
- Type: Manufacture
- Components: 1 x P_compo
- By-products: 1 x P_secondary
6. Inventory > Operations > Run Scheduler
7. Open the generated MO
8. Check Availability, Produce, Mark as Done
- Note that in the "Produce" wizard, we mention that one P_secondary
is also produced
- Also note that in "Finished Products" tab, there are 1 x
P_finished and 1 x P_secondary
9. Open the Transfers
Error: The picking Post-Production -> Stock does not exist
When creating the byproducts move
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L587
the field `move_dest_ids` is present (is the move created after
evaluating the RR)
https://github.com/odoo/odoo/blob/ad62f877c174d56b90ec516cf24494d751383db9/addons/mrp/models/mrp_production.py#L580
so it is used, but this will cause the `_push_apply` to skip the
evaluation of the move
https://github.com/odoo/odoo/blob/f0eaa756c4947e2a595359959b34b14bfda81a07/addons/stock/models/stock_move.py#L678-L679
and `_assign_picking` will not run, as it normally do when creating the
manufacture
Thanks to this change, the picking Post-Production -> Stock will exist
and contain the residual products
OPW-2581762
closesodoo/odoo#75068
X-original-commit: 098af2fa85d2aebfc71b7e2342a1bbf05100e10d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
All accross Odoo, when a document is assigned to a salesperson, that person is notified via email.
However, the `account.move` model is inconsistent with that behavior, because the salesperson field name is `invoice_user_id` instead of just `user_id`.
With this fix:
- When creating an invoice from a sales order, the salesperson will get the assignment notification.
- When modifying the salesperson in the invoice form, the new salesperson will get the assignment notification.
- In both cases, the salesperson will get subscribed to the invoice.
This restores the behavior that `account.invoice` had in v12. For master, a better fix should be considered (a.k.a. simply removing the `invoice_user_id` field and using only `user_id` to avoid these kind of inconsistencies).
@Tecnativa TT29909
closesodoo/odoo#75152
X-original-commit: 95cfa5755b2cb1760f6cce3acb1d1a5ad791d6b7
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In the 'mass_mailing' module, the action helper has an absolute position
and will be placed relatively to the top left corner of the form sheet
With this configuration, the element can sometimes be placed off the
notebook page. It can occur when the list of recipients placed above the
notebook page contains a lot of elements.
To fix the issue, we will wrap the content of the notebook page in a
`div` having the `position-relative` class. The content helper will then
be placed relatively to that element which prevents the overflow.
task-2614456
closesodoo/odoo#75149
X-original-commit: 5d34828f5e25bb7c28c226c4226c1062138721c7
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The commit fixes a small UI glitch in the website.visitors kanban view when
website_livechat is installed.
Since 5a0a1e76b3
The "o_field_many2one_avatar" class works a bit differently and requires
additional wrapping.
To get around that, we specify a custom image tag with the appropriate size and
classes to get a small rounded avatar-style rendering.
Task-2612936
closesodoo/odoo#75148
X-original-commit: aa2951731458896bebfa6146a5899277b2d07e26
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
`update_list` is an expensive operation and could be avoided when no modules are
updated. Particually, it speeds up initial theme installation on website, which
has following code:
```
themes.filtered(lambda m: m.state == 'installed').button_upgrade()
```
Benchmark for Odoo 15: `/website/configurator_apply` spends 1.3 sec for unneeded
`update_list` call.
closesodoo/odoo#75140
X-original-commit: 82ba4994e54fc46cc55a463629727e840349bb6e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Backport of 14.0 PR odoo/odoo#73082 with some slight changes.
Backport of master PR odoo/odoo#62083.
Improve stock.picking._compute_state by computing pickings new state conditions
beforehand. This avoids looping through picking.move_lines for each
condition for each picking.
opw-2613931
closesodoo/odoo#75125
X-original-commit: dca7119f6fe4f9e66c3ecc58f204420e2ad805cd
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Nathan Marotte (nama)