Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by “SN”
- Update the qty to 1 in “WH/stock” with “SN1”
- Create an internal transfer:
- Location: wh/Stock
- Dest location: wh2/stock
- Mark as todo
- Try to select SN1 in the `stock.move`
Problem:
A warning is triggered:
`Existing Serial numbers. Please correct the serial numbers encoded:
(001) exists in location WH/Stock`
We do a search to find all the quants in every location to verify if
the same serial number is not being used, but we do not exclude the
source location.
opw-3734300
closesodoo/odoo#155651
X-original-commit: c6e5b2b4c98f702f9108e75bdc669397ae5e0081
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, it was possible to capture an order twice due to
the rounding difference in quantity, especially when users use a scale.
With this commit, it uses a more relaxed condition and remove the
quantity from the orderline comparison. Given that the system checks
the payments and with the same product and price units, it's unlikely
that two orders will have the same payment amount.
opw-3735436
closesodoo/odoo#155612
X-original-commit: 9f1f8fcd272005eb2cba4bf6feee0ea0b2f2609f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
How to reproduce:
- Install hr with demo data
- Create a user without access to hr and turn it into an employee
- Create a user for Abigail
- Assign Abigail as manager of the new user
- Click on "onboarding plan" in the chatter of the new user
- Then in the dialog, click on "Schedule" button
You get the error "Assigned user test has no access to the document and is not
able to handle this activity." because the new user has no access to the record
employee on which those activities are scheduled.
As activities for which the user has no access to the underlying record are now
displayed in the systray (with no access to the record), we remove the check
that prevent assigning an activity to a user on a record he has no access to.
Technical note: before odoo/odoo#149965, activities scheduled manually were
created with the flag "automated" set to True and when this flag is set the
check that ensures that the user has access to the record is skipped. With
odoo/odoo#149965, as the "automated" flag is set to False when scheduling
activities manually, an error is trigerred if the user has no access to the
underlying record. Here we always skip that test and mark the method as
deprecated because the user can see the activity no matter the access he has on
the underlying record.
Task-3598836
closesodoo/odoo#155576
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit makes the CIUS-RO e-invoice emitted by a Romanian company
without VAT number compliant with the CIUS-RO requirements.
The validator for CIUS-RO (which extends the validations from the BIS3
Schematron) asserts a rule `[BR-CO-09]` where:
if the PartyTaxScheme/TaxScheme/ID == 'VAT',
CompanyID must start with a country code prefix.
In Romania however, there are multiple types of "Tax IDs", and it is perfectly
valid in Romania to have a Tax ID without RO (country code prefix) in front of
them. They are not a subject to paying VAT, and it should still be possible to
generate CIUS-RO XML with their tax identifications.
We have to handle their cases by changing the TaxScheme/ID to 'something other
than VAT', preventing the trigger of the rule and allow Romanian companies
without prefixed VAT to use CIUS-RO.
```xml
<rule context="//cac:PartyTaxScheme[cac:TaxScheme/normalize-space(upper-case(cbc:ID))='VAT']">
<assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ',substring(cbc:CompanyID,1,2) ) )">[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.</assert>
</rule>
```
This commit also fixes and clean some of the irrelevant constraints and tests
previously written in `l10n_ro_edi`.
closesodoo/odoo#155252
Task-id: 3649426
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, in a grouped kanban view with progressbars
and an aggregate field, after clicking on a bar to filter
records, the aggregate value was always 0 (at least when grouped
by a many2one or date(time) field).
This was due to a mismatch when trying to find the value of the
aggregate in the web_read_group result, as when grouped by a date
or datetime field, the key is `fieldname:granularity`, and we were
looking for the fieldname only. And for the many2one case, we were
comparing a pair [id, display_name] with an id.
This commit fixes the issue. It also fixes the mocked version of
read_progress_bar in the MockServer, s.t. we can correctly
reproduce the scenario in tests, as in the previous version, keys
in the returned object weren't computed the same way as in the real
read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A
similar fix has been done in [1]. This allows us to introduce a
test when grouped by many2one, which doesn't work as of 17.0.
[1] fd759f18d056844c486a68d0c394df5a03e789f0
closesodoo/odoo#155701
X-original-commit: 69b1809ed763d03560983bb0e4c996946dd694c5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
=======
The survey addon assets contain some global rules for print mode, that
are present in the global backend stack.
In Odoo 15.2, we put these rules in `survey_templates_results.scss`.
Then, in later versions of Odoo we updated it wih more 'print mode'
global rules.
As these rules are specific to the survey addon, we don't want them to
affect the (whole) Odoo backend.
HOW TO FIX
==========
It seems rules defined in `survey_templates_results.scss` are not
used in survey backend views, but specific to frontend views.
`survey_templates_results.scss` is also part of the
`survey.survey_assets` bundle. This bundle is loaded only for the
following frontend views:
- Survey: main page (take survey)
- Survey: custom 403 page
- Survey: void content
- Survey: login required
- Survey: expired
- Survey: Access Code page
- Survey: print page
- Survey: result statistics page
Among them, views that are not intended to be printed are not
negatively impacted by the css rules for print mode.
A solution would therefore be to remove
`survey_templates_results.scss` from the backend stack.
see 0364161
see #135683
see #146812
task-3666858
closesodoo/odoo#155126
X-original-commit: aba4b503b60b42c91191436491205a0c7575ecbd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- create an invoice with an invoice line having a big amount
- confirm
- print invoice
Issue:
The alignment of total is not correct
Solution:
In l10n_ar, we need more cols to be able to display the correct information. In the base report, the difference is not important visually (the line total is slightly longer)
opw-3670830
closesodoo/odoo#155670
X-original-commit: fca032c6cc2d6b7eb9f8c4bc71b7b259c4ce93ce
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Since Odoo v16, we also use grid in the form layout (inner group).
In a group we use the CSS `grid-template-columns` with the value of:
* `fit-content(150px)`: for the first column (TLDR: col max 150px)
* `1fr`: for the second column (TLDR: take the "remaining" max space)
```css
.o_form_view .o_inner_group {
grid-template-columns: fit-content(150px) 1fr;
}
```
These rules at the first glance seem correct.
But due to "big word"/language, some unbreakable text is overflowing,
to avoid this, we have added the `text-break` BS class.
So now all text can be "squash"/wrap if there is no space available.
The problem is when we have a text be too long and unbreakable in the
second column, the label (first column) is squashed to see only one or
two characters.
In our case, the bug happens when we upload a file with a big filename
to an "Attachement" (`many2many_binary`) field.
On the `many2many_binary` field there is a custom CSS rules:
```css
.o_attachment .caption {
white-space: nowrap;
}
```
that force the text to not wrap on the next line, and so the grid takes
the width of the file name as its min value for the width of the
second column, and "squash"/wrap the first column.
This commit fixes the issue by allowing the second column to be smaller
than the `max-content` width using the css `minmax(0, 1fr)`.
Steps to reproduce:
* Open "Marketing automation" app
* Create a New campaign ("New" button)
* Click on "ADD NEW ACTIVITY"
* Select the "Mail Template" field
* Create and edit a "Mail Template"
* Click on the "Options" tab
* Upload an attachment with a long name
=> BUG, all labels (first column) are "squashed"
Note:
* the `text-break` class is equivalent to:
```css
.text-break {
word-wrap: break-word !important;
word-break: break-word !important;
}
```
* when we use `Xfr` (X a positive numeric value `1fr` in our case)
outside a `minmax()` notation, the GRID specs[1] specifies that it
should be converted to `minmax(auto, Xfr)`.
* also the `auto`[2] in the case of `minmax(auto, Xfr)`the value
represents the largest minimum size (in our case, the file name).
[1]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-flex
[2]: https://www.w3.org/TR/css-grid-2/#valdef-grid-template-columns-auto
task-3644267
closesodoo/odoo#155650
X-original-commit: dbf1794799f2be54e0a0da7719cde3e5069fcdd9
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps to reproduce
------------------
* install `l10n_din5008_repair`
* set the document layout to din5008
* create a Repair order and attempt to print it
You should be met with a traceback.
opw-3718479
closesodoo/odoo#155597
X-original-commit: aca5b96a7ffd9811d8b90a04686eeeadc55156f5
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Phone codes for the Democratic Republic of the Congo (CD) and The
Republic of the Congo (CG) are the wrong way around, and ought to be
reversed.
This commit is based on a commit that was not merged in v14.0 in this
closesodoo/odoo#155680
Pr: https://github.com/odoo/odoo/pull/133287
X-original-commit: 230914dfce7de121ad81444d953a828620177eae
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Steps to reproduce:
- activate analytic
- Create two assets with different analytic distribution
- Open the first asset
- Navigate to the second asset via the arrow
Issue:
The analytic account will not be displayed correctly
Cause:
In `jsonToData` the record used is the previous one.
Solution:
Use the record that will efectively be displayed
opw-3698383
closesodoo/odoo#153681
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Steps:
- Open Timesheets
- Go to To Validate > All Timesheets
- Pivot View is rendered
Issue:
The validate button is not rendered when the pivot view is loaded
Solution:
The changes introduced in these files are aimed at enhancing the customization
and flexibility of the Pivot component in the web application. By adding the
buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer
template, developers can dynamically choose the template for
rendering buttons within the pivot view. This change is particularly beneficial
for scenarios where different button layouts or styles are required based on
specific use cases or user preferences. Additionally, the introduction of a
default value for buttonTemplate in the PivotView configuration ensures a smooth
fallback mechanism if a custom template is not explicitly provided.
Overall, these adjustments contribute to a more adaptable and extensible
Pivot component, catering to diverse application requirements.
Task-3623493
closesodoo/odoo#155547
X-original-commit: f7fa6d66758b7ccbb0ae44e9f977177e6b29da6e
Related: odoo/enterprise#57591
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
1. channel mention should work for channels, chats, and groups, even if
there is a group restriction for the channel.
2. channel mention in livechat is disabled because the visitor can't get
access to the channel.
3. remove the fetch and search for channel mentions in livechat so that
there is no extra rpc call for unuseful data.
4. add a test for the channel mention in thread.
closesodoo/odoo#155380
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since 83c52575d0, there
is no default pricelist in new database, and a magic
pricelist is created for each company when the pricelist
setting is enabled.
But, since this automatically created pricelist is restricted
to a specific company, you couldn't use it as 'Base' for
rules of other pricelists, which are, by default, shared
between companies, unless you set a specific company on them.
This commit changes that default behavior, to restrict
pricelists to the current company (unless the field is
manually emptied), to avoid those multi-company issues,
particularly in single-company databases where
multi-company issues are not expected.
Also, while testing this task, we discovered that a user
could change the company of a pricelist, even if it conflicted
with existing rules. To avoid this situation, we now trigger
the multi-company check on the pricelist rules when the
pricelist company is updated.
task-3610823
closesodoo/odoo#147014
Related: odoo/enterprise#55857
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Starshipit is the leading provider of integrated
and automated fulfilment solutions for online businesses
integrating with the main carriers used in Australia and
New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease and more
This PR will add support to integrate with starshipit directly in Odoo,
providing rates and shipping for users who need it.
Task ID # 3041982
closesodoo/odoo#135839
Related: odoo/enterprise#47569
Related: odoo/documentation#7798
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit, due to a recent change, the customer name was not
being printed on reprinted receipts. This was inconsistent with user
expectations, as they expected to see the customer name on the receipt,
regardless of whether a loyalty program was in place or not.
With this commit, we ensure that the customer name is always printed on
reprinted receipts, aligning the system behavior with user expectations.
opw-3760165
closesodoo/odoo#155543
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Commit[1] introduced a fix on the mandatory day style. But it also
creates another color issue: when we hover a mandatory day in the month
view the mandatory color dissapears.
This commit adapts the selector to handle this issue.
[1]: d75343d7d8
task-3758658
Part of task-3575827
closesodoo/odoo#155201
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit:
Users encountered errors when attempting to unsubscribe a phone number from
receiving SMS.
After this commit:
Now,issue has been fixed, allowing users to successfully blacklist numbers
and opt out of receiving SMS notifications. It is due to a missing parameter
when calling format method, followup of odoo/odoo@adfdf5ab33)
task-3658380
closesodoo/odoo#152638
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This reverts commit 789186a43c.
The fix is not necessary in 17+ since the new onchange only
sends the necessary information and not the whole x2m record
data.
closesodoo/odoo#155550
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
With this commit, overriding the `onWindowClick` function from `dropdown.js`
becomes much simpler. Previously, it necessitated overriding the entire function,
but now it can be done with minimal effort by just overriding this specific part.
task-3717014
closesodoo/odoo#155326
X-original-commit: edf3c7f5c566f530bed2f243a6f78fcf7d1196d2
Related: odoo/enterprise#57471
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit:
Squashed transient messages had date displayed in the sidebar of the message.
This was introduced by this commit: 631ae1c
After this commit:
Squashed transient messages would not have date in the message sidebar.
closesodoo/odoo#154594
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- Activate "Verify VAT Numbers" option in the Settings
- Go to Contacts and create a new one
- Enter a valid EU VAT Number
Issue:
It happens that VIES service could not process the VAT number for some reason
and returns an error.
That error is silently caught without notification to user and "Intra-Community Valid"
field is set to False.
The user will wrongly think that the VAT number is not valid, but it hasn't been
processed at all.
Here's the list of the potential errors returned by VIES service:
- INVALID_INPUT
- INVALID_REQUESTER_INFO
- SERVICE_UNAVAILABLE
- MS_UNAVAILABLE
- TIMEOUT
- VAT_BLOCKED
- IP_BLOCKED
- GLOBAL_MAX_CONCURRENT_REQ
- GLOBAL_MAX_CONCURRENT_REQ_TIME
- MS_MAX_CONCURRENT_REQ
- MS_MAX_CONCURRENT_REQ_TIME
Solution:
Log a note with the error (as it is done for some other error) to warn the user that
the VAT number hasn't been processed.
opw-3687968
closesodoo/odoo#155525
X-original-commit: a15e5430d46b48821f062ffe07fd979b2f19a234
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Steps to reproduce the bug:
- Create a delivery picking:
- product: P1
- Qty: 10
- Mark as todo
- Set “Quantity” to = 6
- Validate the picking without creating a backorder
- return the picking
Problem:
The qty to return is 10 instead of 6
opw-3726157
closesodoo/odoo#155508
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Current behaviour before commit:
When text is selected, applying table command through
powerbox makes toolbar appear along with tablepicker.
This happens because selection is not collapsed.
Desired behaviour after commit:
Now applying table command through powerbox opens
tablepicker only.
task-3482230
closesodoo/odoo#155504
X-original-commit: d090b889f648d1f454d7af0bab828dc57b2df167
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Current behaviour before commit:
When text is selected, applying table command
through powerbox throws error.
Desired behaviour after commit:
Now when text is selected, applying table
command through powerbox creates new table
without any traceback.
task-3482230
X-original-commit: a3384f8708c07b25d092b03b671198fd6877d1d1
Part-of: odoo/odoo#155504
On the contact kanban view, add as much tags as possible. The point is to make the right hand
part of the kanban card as tall as possible.
Before this commit, the image (on the left hand side) of the individual partner was taking all the space
in the y-axis, which was on purpose, but the cropping of the image made it so that the image
lost is sense: a face was too much cropped, or, if the image did not have sufficient pixel density, it was
pixelized.
What is specific to 17 that is barely applicable in earlier versions, is the changes in the display of many2many tags
in the kanban record: they now take more space and at a faster pace.
After this commit, we constrain that image to a maximum height and centering it.
opw-3748585
opw-3751016
closesodoo/odoo#155359
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce the bug:
- In Website edit mode, drag & drop a text-image snippet onto the page.
- Click on the image of the snippet.
- In the image options, select "On Hover" for the "Animation" option.
- Click on the "Undo" button in the top bar of the editor panel.
- Bug: The "Animation" option has not been deactivated, the "Hover
Effect" is still present when hovering over the image.
task-3495241
closesodoo/odoo#134979
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
This commit adds the possibility to preview the various effects
available in the "effect" option for 'on hover' animations when hovering
over the dropdown. The sub-options of these effects are also previewed.
This commit also prevents the user from seeing the different changes
that occur to an image with a shape while changing one of its options
(e.g., changing the shape, previewing hover effects).
task-3495241
Part-of: odoo/odoo#134979
This commit makes improvements as requested in the following pull
request [1] ("allowing the ability to flip/rotate image shapes" and
"adding an 'on hover' option for animations").
It mainly focuses on refining the code for better organization.
[1]: https://github.com/odoo/odoo/pull/119197
task-3495241
Part-of: odoo/odoo#134979
Background videos' dimensions are adapted according to the screen size.
This could lead to the video not showing in RTL languages, because the
computed position was coded for LTR languages.
This commit replaces the `left` and `top` CSS properties with logical
properties to account for language directions.
Steps to reproduce:
1. Add a Cover snippet
2. Add a video to it (use any sample videos from the selector)
3. Save > Check mobile view, video shows fine.
4. Add a Right to Left language to the website (Persian, Arabic...)
5. Switch to the RTL language > Check mobile view
=> video doesn't display properly.
opw-3688660
closesodoo/odoo#155478
X-original-commit: e75ff0792376621f5335a5955ce32a54a1a5c441
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
This commit prevents the sitemap from being translated when a website is
available in multiple languages. The sitemap should always be in the
default language of the website.
Steps to reproduce the bug:
- Set up a website in English and French
- Navigate to the French version of the website (/fr)
- Access the sitemap (/sitemap.xml)
=> The sitemap appears in French but should be in English.
Note: There is a cache for the sitemap. It is not regenerated if it has
been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`).
task-3743970
closesodoo/odoo#155472
X-original-commit: 809854c5d10735fb280141f5291bdb84d8d36569
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
When hr_gamification is installed, it's not possible to grant badges to
users that don't have associated employees.
Expected behavior: we should be able to grant badges to any users.
This is because user_id was related field with employee_id.
We remove that dependency.
task - 3593382
closesodoo/odoo#155007
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit [1] changed the behavior of `setTagName` to only carry the attributes of
paragraph related elements. Ideally, this should not carry the attributes of
`<li>` element only.
[1]: fcb3846
task-3764154
closesodoo/odoo#155448
X-original-commit: 0a47626dba4019fabaf4e399db3369b3db2e712e
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Issue:
======
Invisible whitespaces at the start gets deleted by one by one with
delete forward.
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add any text
- Make sure you have an empty line before it
- Change the html of the added text and add some spaces at the start
(this is the easiest way to reproduce it)
- Go to the line before and keep deleting forward
- The invisible spaces will be deleted one by one.
Solution:
=========
When the selection is at the start of the node and it contains
whitespaces, `parentState` whill have undefined node when deleting
forward since we are at the first leaf. We need to keep deleting forward
with the text node instead of parentElement because calling delete
forward with the parent will do a 1 delete backward call from the
specified offset and it will not propagate forward anymore.
task-3629743
closesodoo/odoo#155435
X-original-commit: 6cfe30b1f194f7c53e8f91dde3251d7ba327ec56
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Delete forward on emoji dosn't work
Steps to reproduce the issue:
=============================
- Go to knowledge
- Add an emoji and put the cursor on the left of the emoji and delete
forward
- only half of the emoji gets deleted
Solution:
=========
We need to get the correct offset and correct charsize because not all
of the items of the sliced string had char size equal to `1`. So we
slice the string and get the offset corrosponding to the target offset
and of course we need to handle the directions differently
task-3629743
X-original-commit: 80a5b41b85c7f6732407bec80c8e6117ae795333
Part-of: odoo/odoo#155435
Before this commit, when a salesman user without any access in other
apps (just has the `sales_team.group_sale_salesman` group) creates
an SO and adds a SOL for a product with `expense_policy='sales_price'`
and then confirm the SO, he will got a traceback because he does not
have access to `analytic.account.line` model. The reason is because
an analytic account has to be generated for the SO since there is an
expense product in its SOLs and so during the generated of analytic
account a check is triggered to be sure the company set on that
analytic account is correct.
This commit adds a sudo before calling the search method in
`analytic.account.line` model to do the check without checking
the access right since the user does not really want to read the
analytic account line.
Steps to reproduce
==================
1. Log in as Salesman user (without other access)
2. Create a product and the expense policy to Sales price.
3. Create a SO and add a SOL with that product
4. Confirm the SO
Expected Behavior
=================
The SO should be confirmed without any issue (and an analytic account
should set on that SO)
Actual Behavior
===============
Traceback is occured because the user cannot access to
`analytic.account.line` model.
Follow-up task-3256865
closesodoo/odoo#155238
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
for model_terms translated fields, for sake of typo fixing feature
if a term is removed after write its translations might be reused by another
close term which has totally different meaning
this fix removes the typo fixing if the matched closest term exists before write
closesodoo/odoo#155476
X-original-commit: 38ec36e9b5dde0c02a4ff47714b1056e0db76812
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Steps to reproduce
* Create a new SO
* Add a new line with a storable product and 15.12 as quantity
* change the price to X
* Save and confirm
* Set a scheduled date (Other info tab)
* Save
-> The price of the SOL is recomputed.
Cause
Because of floating point issues, the value returned by the onchange for
the product_uom_qty field is 15.1200000....1, therefore being considered
in the client-side as having been changed by the onchange.
The value is then sent to the server on save, triggering a recomputation
of the SOL prices.
Until there is a clear solution in the framework, this commit drops
'unmodified values' for the product_uom_qty field, only if there is
one updated line in the write call.
opw-3670318
closesodoo/odoo#155392
X-original-commit: ef1b59062266ee4ab58b5330ce0012dcee69f2b7
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The pot file of the base module hasn't been updated in some time.
This commit takes care of that.
closesodoo/odoo#155375
Related: odoo/enterprise#57503
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Commit [1] introduced a way to copy translations from a (view) record to another (snippets to their real life use).
The core function that was implemented is the low level `ir.ui.view:_copy_field_terms_translations`. However, that function
did not support inputting a hierarchy of views.
Indeed, since translations are stored on the view record, each view that is part of an inheritance tree has its own translations.
So, to copy the resulting translation of an inheritance tree to a record that contains all the tree in itself, as it is the case in web_studio's ReportEditor since commit [2], there was a need for that method to support the input of a record set of potentially many records.
Hence this commit proposes to modify that method that now takes a record set of potentially many records as input and
still copies to a single record.
opw-3746922
opw-3724701
opw-3719157
[1]: cfc90c0b2f30c9e5b6aae29958997298196ee952
[2]: odoo/enterprise@b7d0d3034dclosesodoo/odoo#155346
X-original-commit: 2d58b1c65be65297cb17818c0c21dbf2b84b664b
Related: odoo/enterprise#57490
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Fix a bug introduced by 67901a4429c69fbba96c32af5d8f58aff54f0be5
When an expense is submitted and for the steps after, there is no need
to recompute the product_cost as it may be confusing
or generate discrepancies with the account move by changing the totals.
task-3580004
closesodoo/odoo#155277
X-original-commit: 2427ac03806205f45084640c301b3dfb9011c22c
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Steps to reproduce the issue:
- Install `website_event_sale` module
- Create an event with a paid ticket
- Go to website and register for the event for 2 persons
- Go to the cart and remove one of the attendees
- Proceed to checkout and confirm the order
- On the checkout confirmation page, click on `Download tickets`
- Open the downloaded PDF file
Issue:
Two tickets are displayed in the PDF file.
Cause:
Not filtering out the canceled attendees.
Solution:
Display tickets only for `Attended` and `Registered` attendees.
opw-3718542
closesodoo/odoo#155125
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
Steps to reproduce:
- Create two companies:
(ex. Daughter Company)
(ex. Mother Company)
- Install Inventory app
- In the settings of both companies:
- enable Multi-Step Routes
- enable Dropshipping option
- Using the Daughter Company, go to Routes > Dropship route
- When You try to set Company to Daughter Company, it's possible to do so even thought the rules belonging to the Dropship route belongs to two companies: Daughter Company and Mother Company which is not consistant
Disscuss
- We constraint the route company to always be consistant with the rule(s) company and vice verca
opw-3648535
closesodoo/odoo#154403
X-original-commit: 0bc6057d986304a75ec0ba64141c965d9275f2f6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Versions
--------
- 17.0+
Steps
-----
1. Create a new company;
2. switch to it via the selector;
3. create a new product specific to the company;
4. create a sale order;
5. open the catalog via a sale order line.
Issue
-----
Access error
Cause
-----
The catalog controller does not receive the user context,
therefore fallbacking on the default user context, with
the main company of the user. Accessing a product from
another company will fail and raise an AccessError.
Solution
--------
Make sure that catalog requests are done in the company of the
order, the information is available and it makes no sense to
use another company for those requests anyway.
Also adds the missing license in the catalog mixin.
opw-3690226
closesodoo/odoo#153915
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since PR [1], which redesigned the headers, there are now two navbars:
one for the desktop view and one for the mobile view. This also means
that the different menus are in both navbars at the same time. However,
this causes some issues with the mega menus.
Indeed, since each mega menu is in both navbars, the changes made in one
are also made in the other (since it is a field in the database). This
causes issues when drag and dropping:
- Drag and drop a mega menu element.
- Re-drag it and drop it somewhere else.
=> We notice that the element was cloned and each drag and drop adds a
new clone. Moreover, when clicking on a link inside these elements, a
traceback appears.
This happens because since both mega menus are synced, the drag and drop
clones are also synced and so the dragged element is dropped multiple
times (after each clone).
This commit fixes these synchronization issues by adding the mega menus
only once in the DOM, in the desktop navbar. They are then moved from
one navbar to the other when we open them.
[1]: https://github.com/odoo/odoo/pull/119650
task-3609531
opw-3730165
closesodoo/odoo#146492
Related: odoo/design-themes#756
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).
This commit fixes these history issues by not observing some problematic
changes. Note that this commit only fixes the most "annoying" ones (i.e.
the ones that break things) that prevented the other commits of this PR
to work correctly. A second pass will be needed to remove other useless
mutations (i.e. that do not break things but should not be observed
either). This commit will also need to be backported, as these issues
are also present in earlier versions.
Here are the changes that are not observed anymore:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".
- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good.
- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.
- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.
task-3609531
opw-3730165
Part-of: odoo/odoo#146492
With the headers redesign in PR [1], the "collapse menus" (e.g. in the
"Hamburger menu" and the mobile menu) are now `Offcanvas` elements
instead of `Collapse` elements (see `data-bs-toggle="offcanvas"` in the
headers XML templates). As such, when they are toggled, it is now
`bs.offcanvas` events that are fired, instead of `bs.collapse`.
However, the code using these elements and handling these events has not
been adapted and is therefore never executed, which causes some issues.
1) First issue:
- In edit mode, drop enough snippets to have a scroll bar.
- Toggle the mobile preview and open the menu or resize the screen so it
is smaller than the `SM` screen breakpoint.
- With the menu still open, go back to the desktop view or resize it up
beyond the `SM` breakpoint.
=> There is no scrollbar anymore so we cannot scroll.
This happens because the selectors and event listeners managing the
collapse menus and the scroll do not target the right elements/events.
- On toggle, the `overflow-hidden` class should be added on the body to
prevent the scroll.
- On hide, this class should be removed to re-allow scrolling.
=> Here the scroll is prevented by chance thanks to commit [2] but it is
not the right flow.
- On resize, when the screen becomes bigger than `SM`, the collapse menu
should be closed and the `overflow-hidden` class removed from the body
(see the `_updateHeaderOnResize` function).
=> Not happening because the collapse menu selector is not the right one
and commit [2] does not take the resizing into account.
2) Second issue:
- Change the menu to "Hamburger menu".
- Set the background to a dark color (so that the text is white).
- Set the "Header Position" option to "Over The Content".
- Open the menu.
=> The menu is still considered as transparent so the text is dark on a
dark background, making it difficult to read.
This issue was originally fixed by commit [3], by adding the `o_top_menu
_collapse_shown` class when the menu is opened. It happens again because
since the event is not the right one anymore, the class is never added.
This commit adapts the menus public widgets code in order to consider
these `Offcanvas` elements/events and restore the needed behaviors.
Note that the `NavbarDropdown` public widget (added in commit [4]) is
now useless. Indeed, it was added in order to prevent the dropdowns to
be hidden when opened inside a burger menu, but this issue does not
happen anymore when following the steps. It has already been removed in
master by commit [5].
The same goes for the `TopMenuCollapse` public widget, which was added
in commit [6] to avoid having a scrollbar when opening a sub-menu after
resizing up the screen with the mobile menu open. It is not even started
because its selector is not valid anymore (the `top_menu_collapse` id
only exists in the "Hamburger menu", where the issue cannot happen), and
the issue is not there anymore when following the steps, which makes the
widget useless. It will be removed in master.
[1]: https://github.com/odoo/odoo/pull/119650
[2]: https://github.com/odoo/odoo/commit/f6d9f80e6e8458bdcf75fca9ff3b7e7e54d2a6ba
[3]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510
[4]: https://github.com/odoo/odoo/commit/ce9b350403ff7c1004b50b39588891ee652e0a3a
[5]: https://github.com/odoo/odoo/commit/39b79832a0cd3e191077a11a485de78365928feb
[6]: https://github.com/odoo/odoo/commit/b7a4538c51aacca666920bdd9496ee575ab12e7a
task-3609531
Part-of: odoo/odoo#146492
Djamel Touati