currently the module is named as LT, where as it has to be Lithuania according to odoo localization module standards
closesodoo/odoo#109240
X-original-commit: 84291b92655a260bd75669466c8f66d421fa3e7b
Related: odoo/enterprise#35488
Signed-off-by: Laurent Smet <las@odoo.com>
This commit removes the title attribute on navbar items.
The title was only repeating the content so it was useless.
closesodoo/odoo#109230
Task: 3097276
Related: odoo/enterprise#35562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit makes the kanban group header sticky, it means that when
the user scrolls the headers will still be visible on top of the view.
closesodoo/odoo#109060
Task: 2050014
Related: odoo/enterprise#35611
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some cookies were left around even when the user logged out
The next user should log into the default company instead of the company
of the last user.
task-3077421
closesodoo/odoo#108998
Related: odoo/enterprise#35685
Signed-off-by: Julien Castiaux <juc@odoo.com>
Problem case :
- Create a product with MTO and Buy route activated.
- Create a Sale Order containing this product.
- Confirm the Sale Order, this will generate a Purchase Order for this
product.
- Go to Alternatives -> Create Alternative -> Select another vendor &
select "Copy products".
The alternative PO won't be linked to the Sale Order, as this link is
done through the relation `created_purchase_line_id` <-> `move_dest_ids`
respectively on the `stock.move` and the `purchase.order.line`.
The only way to enable multiple Purchase Order to be linked to a single
move is to extend the number of `created_purchase_line_id` linked to a
move, hence changing it to a Many2Many relation.
Then, when an alternative PO is created, we link the original PO lines
`move_dest_ids` to the newly created PO lines, which correctly links the
SO and the alternative PO.
closesodoo/odoo#106411
Related: odoo/upgrade#4116
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a service that is subcontracted `service_to_purchase` = true
- Create a SO containing this service
- Go to the newly created RFQ
- Go to Alternatives -> Create Alternative and select a new vendor
- The alternative RFQ doesn't show a link to the SO, nor the SO to this
RFQ
Initially, when the alternative RFQ is created, only the `product_id`
and its quantity is copied to the new RFQ. Now we add the reference to
the SO as well so the RFQ is properly linked to the original SO.
Part of task-2985735
Part-of: odoo/odoo#106411
*=hr_timesheet,sale_project,sale_timesheet,spreadsheet_dashboard_hr_timesheet
The main goal of this PR is to minimize code duplication for the search and list views for tasks and projects.
Task search views
-----------------
The most important change was to merge the search views used in the task reports with the "normal" corresponding search view. The reporting search view should now be almost identical to the normal one in both project and fsm.
The `project.task`/`project.task.user` search views are now following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
┌──┤4│ │7├──┐
│ └┬┘ └┬┘ │
│ │ │ │
┌▼┐ ┌▼┐ ┌▼┐ ┌▼┐
│5│ │6│ │8│ │9│
└─┘ └─┘ └─┘ └─┘
```
1. `view_task_search_form_base`: Base search view containing all the fields/filters common to project, project sharing and fsm
2. `project_sharing_project_task_view_search`: Search view for project sharing.
3. `view_task_search_form_project_fsm_base`: Base search view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_search_form_project_base`: Base search view for project only, with fields/filter common to the normal search view and the one used in reporting.
5. `view_task_search_form`: Search view for project.
6. `view_task_project_user_search`: Search view for the project report.
7. `project_task_view_search_fsm_base`: Base search view for fsm only, with fields/filter common to the normal search view and the one used in reporting.
8. `project_task_view_search_fsm`: Search view for fsm.
9. `report_project_task_user_fsm_view_search`: Search view for the project report.
With this organization, we can easily add a field to both fsm and project at once, and even to project sharing at the same time. Since the goal is to keep the reproting search views identical to the normal ones, it'll also add the field to both of them.
Task list views
---------------
Similarly to the search views, the task list views were also refactored to minimize code duplication, following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
│4│ │5│
└─┘ └─┘
```
1. `project_task_view_tree_main_base`: Base list view containing all the fields/filters common to project, project sharing and fsm.
2. `project_sharing_project_task_view_tree`: List view for project sharing.
3. `project_task_view_tree_base`: Base list view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_tree2`: List view for project
5. `project_task_view_list_fsm`: List view for fsm.
Project views
-----------------
The search and list views for projects in fsm now inherit the ones from project, since our goal moving forward will be to keep those as similar as possible.
Other changes
-----------------
- Merged and removed many filters/fields from the task search views.
- Changed `total_hours_spent` and ` subtask_effective_hours` labels in `project.task` model to avoid changing them manually in many views.
- Renamed `state` into `kanban_state`, `hours_planned` into `planned_hours` and `hours_effective` into `effective_hours` in `report.project.task.user` to make it consistent with `project.task` (so we can keep the same views for both of those models).
- Moved the sale line filed in the "Settings" tab in the project form view (so that the `sale_line_employee_ids` field in "Invoicing" takes the full width).
---
Enterprise: https://github.com/odoo/enterprise/pull/34106
Upgrade: https://github.com/odoo/upgrade/pull/4216
Task-2746370
closesodoo/odoo#106015
Related: odoo/upgrade#4216
Related: odoo/enterprise#34106
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).
Related tests worked fine because mocked server responses were different from
real server responses. So, we need to adjust mocked server too.
opw-2870937
closesodoo/odoo#103926closesodoo/odoo#104613
X-original-commit: e6ca3ef1b38dec964dab416c6058d4c1b7161614
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
The account_predictive_bills module is merged into account_accountant.
With this change, the context key
`account_predictive_bills_disable_prediction` is not used anymore.
closesodoo/odoo#104625
Related: odoo/upgrade#3918
Related: odoo/enterprise#31640
Signed-off-by: William André (wan) <wan@odoo.com>
When changing quantities of raw moves after MO confirm,
procurement is run to fulfill updated need.
Since procurement creates new moves, some fixes were also done to allow
moves to be merged with older ones, including:
1) `date_planned_start` of merged MO included microsecond which
blocked merging new moves created by procurement with orig moves.
Removed microseconds.
2) `_set_date_deadline` did not allow a simple date update to moves with
orig or dest moves. Added context to hard set all moves in self to specific
deadline.
3) `_update_candidate_moves_list` when merging moves, did not return candidates
from pickings that were merged to same MO. Usually just mattered when decreasing
quantity. Added explicit check for sibling pickings in MO
closesodoo/odoo#93712
Task: 2859547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, there was no way to instanciate a Record component and be
able to handle changes occuring in that record.
After this commit, a simple props is added, making this use case possible.
closesodoo/odoo#109846
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Dates in FatturaPA are in ISO 8601 date format: `[-]CCYY-MM-DD[Z|(+|-)hh:mm]`
Data like `2021-01-01z` or `2021-02-05+01:00` did break the checks.
closesodoo/odoo#109838
X-original-commit: 9e50fa08a74fa842aa3a2f37dfe5b38707a50cba
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
We add a QR code to the invoice PDF report
and we add references to the json to the customer reference
(PO of the customer in ref) and to our Sale order (invoice_origin)
closesodoo/odoo#109837
X-original-commit: 25bc19dc1351b64505d8a2d41dd2b90afd7c117a
Signed-off-by: Josse Colpaert <jco@odoo.com>
We just set a place of supply(state_id) from partner_id in the Invoice/Bill if partner country is india because there are many complex cases so we can't get it automatically in all cases like
(a) where the supply involves movement of goods, whether by the supplier or
the recipient or by any other person, the place of supply of such goods shall be the
location of the goods at the time at which the movement of goods terminates for
delivery to the recipient;
(b) where the goods are delivered by the supplier to a recipient or any other
person on the direction of a third person, whether acting as an agent or otherwise,
before or during movement of goods, either by way of transfer of documents of title
to the goods or otherwise, it shall be deemed that the said third person has received
the goods and the place of supply of such goods shall be the principal place of business
of such person;
(c) where the supply does not involve movement of goods, whether by the
supplier or the recipient, the place of supply shall be the location of such goods at the
time of the delivery to the recipient;
(d) where the goods are assembled or installed at site, the place of supply shall
be the place of such installation or assembly;
(e) where the goods are supplied on board a conveyance, including a vessel, an
aircraft, a train or a motor vehicle, the place of supply shall be the location at which
such goods are taken on board.
we add new state "Other Country" to set place of supply(state_id) incase of partner country is not India
for more details check CHAPTER V here https://www.cbic.gov.in/resources//htdocs-cbec/gst/igst-act.pdf;jsessionid=63D695F612B9972934E8131415FEBA28closesodoo/odoo#82011closesodoo/odoo#109286
X-original-commit: https://github.com/odoo-dev/odoo/commit/b76ee098e2a4c4d26d6d1c689bb0750e770201dc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, test "click on the progressBar of a new column"
deterministically failed on split builds. It only passed with all
addons installed, and passed by chance with all addons installed.
The reason is that the flow of quick creating a record in a grouped
kanban with progressbars wasn't concurrency proof at all. Commit [1]
simply added a hook at the end of the `_save` function of the model,
which highlighted the problem: the progressbars were updated before
the group's count was incremented, so if the quick created record
was the only record of the group, the progressbar was still empty
after the quick creation.
This commit makes the quick create code more robust.
We couldn't find a way to write a qunit test for this, but it still
fixes an error in nightly builds.
[1] a882b725bbclosesodoo/odoo#109818
X-original-commit: cbfad9c36f4e52309903702f21cea457acc55ecb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behaviour:
If a user is making a donation with one amount,
but changes that amount on the payment page,
he lands on a 404 when processing the transaction.
Expected behaviour:
The transaction shouldn't land on a 404 if you just changed
the amount of the donation mid checkout.
Steps to reproduce:
- Install Website and the Donation widget from the website editor
- Add the Donation widget to a page
- Add add a payment method (for ex: Test)
- Make a donation for example of $10
- On the payment page, change the amount to another value
- Checkout, you land on a 404 page.
Reason for the problem:
When generating the `access_token`, it is based on the amount paid.
So at the beginning of the transaction, it is based on $10.
But during checkout, we have a new amount, therefor a new `access_token`
is generated upon ending the transaction. Since the 2 tokens are
different, we return a 404.
Fix:
During checkout we regenerate a new `access_token`, before going on
the landing page. This way the `access_token` will take the value of
the amount from the payment form, not the donation widget.
(The default value for the amount on the payment form is the one
selected from the donation widget)
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3059462
closesodoo/odoo#109817
X-original-commit: 78bc873eef6768cec87c7f2eb0d5324ccc9d6af5
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Note:
This is not fixed earlier because this in invalidates
template translations and this isn't a major issue.
Invalidating translations on 16.0 should still be
fine as of writing this.
Issue:
Google recently added a requirement for an API key
to their static maps API. This means we can no longer generate
<img> tags linking to the google API without using a key.
As we send that key inside emails, it cannot be protected
by origin policies to prevent people from using the key outside
of the domain of the database. Protecting it would require
implementing signed google API requests, which cannot be
done both quickly and sanely on stable.
Fix:
This commit replaces the image with a generic string to get rid of the
'missing image' icon. A better fix/imp may be introduced on the master
branch at a later time.
task - 3079113
closesodoo/odoo#109797
X-original-commit: a730c9920bc82a6637882f325ca3d947ca0ddd78
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
In a list view containing n records, apply or remove a filter.
Then edit the pager to reduce the limit to m, with m < n.
Before this commit, the pager was indeed updated, but the list
still contained the same number of records as before applying the
filter.
This was due to a kanban specific logic to handle the "load more"
feature. We stored the number of loaded records, and forced the
limit to be at least that number.
This commit fixes the issue by changing the way the "Load more"
works. Instead of loading the "limit" next records (i.e. with a
limit and an offset), we now reload the previously loaded records
+ the "limit" next ones (i.e. we leave the offset to 0, and
increase the limit).
This also prevent potential weird behaviors where the same record
appears twice, or records are skipped, when the recordset changes
between the first load and the first load more, or between 2 load
more.
closesodoo/odoo#109693
X-original-commit: 217d1191750d03918055610ba0e61f0f7522f475
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The title is aligned to the right on mobile. This is the result of the
two rules of Bootstrap:
```css
.modal-header {
display: flex;
justify-content: space-between;
}
```
To avoid this we add `margin-inline: start`, to force start alignment of
the title.
Steps to reproduce:
* Open Customer (on small/mobile screen)
* Create a new Customer
* Click on Tags field => BUG title of dialog on the right
Note: on desktop there is no problem as there is the close button on
the right.
closesodoo/odoo#109796
X-original-commit: 7809abb1dcf1b0d384c0cad4065cdf15adf56081
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
To reproduce on runbot:
- Log in a Marc Demo (demo):
* Go to Calendar app
* Create a event, and set privacy to "Private"
- Log in a Laurie Poiret (lauriepoiret):
* Go to Calendar app
* Add "YourCompany, Marc Demo" in attendee filter (sidebar) => crash
TypeError: attendees is not iterable
updateAttendeeData@https://22697845-16-0-all.runbot174.odoo.com/\
web/assets/2283-d20ef14/web.assets_backend.min.js:13915:603
This commit ensure that `attendees` is a list.
closesodoo/odoo#109819
X-original-commit: 28ee9cd8a88a36c7f837cc50923fa01d7e804544
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Since https://github.com/odoo/odoo/commit/3752b3166ec6bbb5c6ea55f96bb521381bf2b2d9,
the currency of the test architecture is not fixed anymore to USD (but is by default).
Therefore, the nightly runbot tests of the localization (l10n_* modules) all fail
when verifying the company currency is USD (because the localization sets the company
currency to the country one).
This commit adapts those checks to stop enforcing the USD currency as base,
only enforcing that the currency used is the company one.
closesodoo/odoo#109807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose
=======
Make sure we display a correct progress number.
Specs
=====
When configuring a survey as one page per question and the random selection
of the questions, the numbers near the progress bar where not correct.
With this commit they now are.
task-2988062
closesodoo/odoo#109802
X-original-commit: 9487495e5e9a3f6ce899249f7eab6c7074c64464
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Current behavior:
In the PoS base dashboard there is a "Top Orders" section that shows the
top orders by amount. The orders are shown in ascending order when it
should be descending.
opw-3116114
closesodoo/odoo#109799
X-original-commit: 3e7109827ce285f6204c80e66b5e38a71dd61fd1
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
In order to plan a certain Ship Later pos order, a user must go to the backend and find the correct picking linked to the order he made. The date picker can be useful to not have to go back to the backend and continue selling to customers.
Now, when pushing on the button Ship Later, a date picker appears with a default date set as the current date and the user can chose another date after the default date.
closesodoo/odoo#107115
Task-id: 3078526
Related: odoo/upgrade#4200
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Tag color is already handled in tags_list.scss
Also, `$min-contrast-ratio: 2.2` was creating contrast issues and was
therefore dropped
part of task-3085081
closesodoo/odoo#109740
X-original-commit: 5517e41663ece74e5dc13d9ab4edf9938cfe5c4b
Related: odoo/enterprise#35701
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Issue # 1:
Before this commit, copying an empty selection (collapsed range)
produced a Traceback. Making onClipboardCopy return when the selected
range is empty serve as double purpose: avoid that trace and not
overwrite clipboard content with an empty string (leaving the
previously copied content available for pasting).
Issue # 2:
Before this commit, copying a selection that spans over two or more lines
was producing a text/plain content without line breaks. This happened
because the text was obtained getting the innerText property of a detached
element (thus, not being rendered). In such case, the returned value is
the same as textContent, which just concatenates the text content of
text nodes (thus ignoring BR elements). Selection.toString(), for
instance, represents line breaks in the selection as '\n' in the
resulting string.
This commit also removes 2 harmless but useless lines:
if (!clipboardEvent.clipboardData.getData('text/plain'))
if (!clipboardEvent.clipboardData.getData('text/html'))
A copy event handler cannot read the clipboard data.
(see https://developer.mozilla.org/en-US/docs/Web/API/Element/copy_event)
The expressions in the if-conditions above always return true,
as getData will return an empty string.
Finally, this commit also adds basic unit tests for copying and cutting that
were missing.
task-3114102
closesodoo/odoo#109757
X-original-commit: 3a4be5116c23e12129d6e8c9d841a17a57a710a9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Due to changes in errorService added in dd6f103b, a traceback was shown due to
our (handled) "unhandled" rejected promise that wasn't an "Error" object.
Using the original error works now for our handleSurveyError function. The only
additional requirement was to restore the buttons of the dialog when saving is
blocked due to our validation process.
Task-3128957
closesodoo/odoo#109648
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
To Reproduce
============
- add event on calendar
- edit the event and remove the user from participants list and add another one.
- save the record -> traceback
Problem
=======
we try to read `hasReadAccess` from `this.followedThread` that is `null` in this case.
Solution
========
check if `this.followedThread` is `null` or not
opw-3126545
closesodoo/odoo#109721
X-original-commit: f9a23af63bb5fe882f0d42f06ef1406910836115
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since its introduction with [1], there is an issue about the full link
URL which is never set.
The preview has 2 URL elements:
- The main one, for which the text will either be the URL itself for
external website or the page title for internal pages.
- The "full one", which will simply be the full URL for internal pages.
It's basically the text of the "main one" which is moved here when
there is a title to display.
But the "full one"'s url was never set, always being "#", meaning that
when you click on the title you land on the correct page but when you
click on the URL itself you don't go to that page.
[1]: https://github.com/odoo/odoo/commit/8fcf930a6b6b7ffb0965b0a689c7a3117962ce7e
task-3129267
closesodoo/odoo#109716
X-original-commit: 015c9bf111899b2a86c39b24cd1ec2d4e5278204
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When installing both documents and fleet and then, add a translation to
the database. Both fleet and document will be translated the same way.
This is due to the fact that both of them share a lot of similar value
inside of the PSQL database.
opw-3120320
closesodoo/odoo#109700
X-original-commit: fff53f845398ee0f8632cf7cb392f108388f3dc4
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce:
- install l10n_eg_edi_eta and website_sale modules
- add any product in cart
- try to add an egyptian address on checkout
- it fails with an internal server error
Bug:
the `address_format` for `egypt` doesn't have a city field while it is
actually important for egypt addresses and it is also required in the
l10n
Fix:
add the city field
OPW-3098006
closesodoo/odoo#109577
X-original-commit: f1e9635ee7e086582c5e0ffbac6c52e2f62937a0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The function write must return True when it ends.
opw:3121809
closesodoo/odoo#109713
X-original-commit: 6adeabf6445c72e7ddfd540ceaea8c01473e062d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
Before this commit, cut/copy operation in non-html fields will trigger the _onClipboardCut/_onClipboardCopy handler as long as there is html field in the same form view.
This will cause cut/copy fail when using chrome or edge.
Only bind cut/copy event to html field as these event handlers are not related to non-html fields.
closesodoo/odoo#109624
X-original-commit: 494f8300f848cf258ba8ba0132af104346083b3e
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This is used together with the audit features defined in account_reports (and fixed in the enterprise counterpart of this branch).
closesodoo/odoo#109521
X-original-commit: 5b8686526e0faeee38cac6e2017a8f840aac041c
Related: odoo/enterprise#35616
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
In this commit, the following points are covered
- updated error messages
- remove renaming the `Customer Invoices` journal name
- updated Fiscal Opening Date and Year End for Indian localization
- updated Indian E-Invoicing report and settings setup
Part-of: odoo/odoo#109396
In this commit, set the company's country vat label instead of 'VAT' in the error
message if the vat label is not available in the company's country then the default
value is 'Tax ID'.
Part-of: odoo/odoo#109396
In this commit, I have added a new module for TCS/TDS Tax Report in India.
It will load TCS/TDS-related taxes for an Indian Company.
Added a new character field PAN on the partner.
Added post_init_hook to load these taxes in current company.
closesodoo/odoo#109338
X-original-commit: 367c32684e572dbc9413dc4bc2ba30b14f730541
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, there was a crash if you quickly dragged&dropped
twice the same record from a column to another (i.e. before the
first write was done). This was because we couldn't find (yet) the
record from the column we were dragging it.
This commit prevent the crash from happening.
closesodoo/odoo#109694
X-original-commit: b57238b577342d9a4c824b90eb7fa2a4b8e00a8e
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a user imports a bank statement, reconciles some moves,.. later on,
he does not have the ability to easely go back to the bank statement
and see the others items / continue his work.
This commit enable the user to move from the journal entry to the bank
statement reconciliation widget where he will see all items (if any).
task-id: 3116184
[community](https://github.com/odoo/odoo/pull/109039)
[enterprise](https://github.com/odoo/enterprise/pull/35580)
closesodoo/odoo#109039
Related: odoo/enterprise#35580
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Following 90af85c2e4, the management of the compatible providers
was modified by their available currency. Some tests weren't adapted to that change.
closesodoo/odoo#109665
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When redirecting the SML of byproducts, the capacity constraints of
the locations are not considered.
To reproduce the issue:
1. In Settings, enable:
- By-Products
- Storage Locations
- Storage Categories
2. Create three storable products P01, P02, P_comp
3. Create a storage category SG:
- Max Weight: 1000
- Capacity by Products:
- 2 x P02
4. Create two locations L01, L02:
- Parent Location: WH/Stock
- Storage Category: SG
5. Create a putaway rule:
- From: WH/Stock
- Product: P02
- To: WH/Stock
- Having Category: SG
6. Create a BoM:
- Product: P01
- Components: 1 x P_compo
- By-products: 1 x P02
7. Update on hand qty of P02:
- 1 x P02 at L01
8. Create and confirm a MO with 2 x P01
9. Set the producing qty to 2
10. Open the detailed operations of P02
Error: The destination location is L01, this would break the
capacity constraint. The location should be L02
When setting the producing qty, we also set the done quantities of
the finished moves and we redirect them thanks to the putaway rules:
https://github.com/odoo/odoo/blob/cc6e31efe6fdd9dee16de1565afe9e1b502de45d/addons/stock/models/stock_move.py#L1885-L1888
However, the SML created only has the `qty_done` defined and, when
applying the putaway rules, we consider the `product_uom_qty` which
is equal to 0 in such a case.
So, when trying to redirect the SML of P02, we check if the capacity
constraint of L01 would be exceeded with the quantity of the SML.
But, as explained above, that quantity will be 0, so we conclude
that the capacity constraint is ok and we return L01 as best solution.
This is the reason why this commit suggests the use of the maximum
between done quantity and reserved quantity. This logic is already
used in the putaway application process, when we check the forecasted
quantity by location:
https://github.com/odoo/odoo/blob/a217ba27600c64c9104f8c1f003afd74ad06bd05/addons/stock/models/stock_location.py#L297-L301
OPW-3100322
closesodoo/odoo#109669
X-original-commit: 4ee8f974f993d2bbea7d9fc00779ebb1c1fa047d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit, the byproduct and putaway feature do not work
together. More specifically, changing the quantity to produce on a
manufacturing order will create automatically a byproduct move line (or
update the existing one with the new quantity) but never look for a
putaway rule to apply.
This commit makes use of `_set_quantity_done()` method on `stock.move`
that *do* call the putaway strategy mechanism
X-original-commit: d4a968412e68cc9da3ec2d9725caa90830287c48
Part-of: odoo/odoo#109669
When applying the putaway rules, if we redirect a package (with a
specific type), we don't check the category of the package products.
To reproduce the issue:
1. In Settings, enable
- Packages
- Multi-Step Routes
- Storage Categories
2. Edit the warehouse:
- Receipt: 2 steps
3. Create three categories C1, C2, C3
- Parent: All
4. Create three locations L1, L2, L3
- Parent: WH/Stock
5. For each location Lx, create a putaway rules PRx:
- From: WH/Stock
- Category: Cx
- To: Lx
6. Create a product P
- Type: Storable
- Category: C2
7. Create a planned receipt R with 1 x P
8. Mark it as todo, set the done quantity and put it in pack
9. Set a type on the package
10. Mark R as done
11. Open the associated internal transfer
Error: the destination location of the package is not L2 -> an
incorrect putaway rule has been applied
When we try to apply the PR on the SML "input to stock", because
this is a package with a type, we don't provide the list of the
products. Therefore, we have no idea about the product category.
This is a shame in case of a package that contains some products of
the same category. We should be able to apply the putaway rules
related to that category.
Moreover, this commit also fixes two other issues explained in [1]
and [2]. The FW of these commits have been stopped for the current
one because they didn't fix the above use case. Moreover, this commit
simplifies/clarifies the filtering and sorting of all putaway rules
[1] 03e47b165e7f6c59b41509d9229e8e2074aa3f34
[2] e0098eb281d886797a888a6f8fac474bbacb1b09
OPW-3098452
X-original-commit: c99523bc3a4a5a335f1928cf9bb53bb8483b492e
Part-of: odoo/odoo#109669
Before this commit, the bus service would fail to initialize its worker
when loaded from a different origin than the worker script URL.
Moreover, the websocket URL was assumed to be on the same domain that
the bus service.
This PR fixes both issues:
- When the bus service is loaded from a different origin than the worker
script URL, create a data URL and use "importScripts" inside the worker
since it is not restricted to same origin scripts.
- Pass the websocketURL to the worker during its initialization.
opw-3118394
closesodoo/odoo#109701
X-original-commit: c1a480bb9ec133b9f94a5bb505380216a7f9c4ce
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When you have a journal configure to create add e-fff xml file to
integrate into the invoice, you get an access error when the user that
prints the invoice is not the same as the user that has posted the
invoice.
To avoid this issue, we are calling the '_prepare_invoice_report' with
an edi_document in sudo. The issue comes from that the attachment_id on
the account.edi.document has no res_id and res_model (to be hidden in
the chatter of the invoice). So to get access to such attachment, you
need to have the same 'create_uid' or being a 'Setting' user.
The issue was not present in saas-15.3 because the reports were executed
in sudo, so everything was accessible.
To easily reproduce:
- create a company in belgium
- activate E-FFF edi on the sales journal
- create and post an invoice with the user A
- print it with the user B (that is not an administrator
closesodoo/odoo#109702
X-original-commit: 87716488670b0ba4619d7e8c49e99dfd61ff88d7
Signed-off-by: William André (wan) <wan@odoo.com>
niyasraphy