Have a purchase tax with cash basis payment enabled
Have a product with said tax
Create a bill with the product, save and confirm
Register a payment
Check CABA entries
There should be 4 entries, but only 2 have been generated
opw-2782561
closesodoo/odoo#89101
X-original-commit: d8d255ec68ab4f220da51fb2be7292dcc74d5783
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: oco-odoo <oco@odoo.com>
PURPOSE
This commit slightly modifies both the slide's backend form view and the
website form to use the certification (survey) title as default name for this
slide if it does not have a name configured yet.
We also removed dead onchange code as the survey_id field is not visible if
slide_category is not set to certification.
LINKS
Task-2810395
closesodoo/odoo#87672
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Currently, when creating a survey through the 'quick create' feature of a
many2one field, the name input by the user is lost and not propagated to the
survey title (the default behavior expects a 'name' field).
This commit correctly takes the passed default_name into account and uses it to
fill the survey title.
LINKS
Task-2810395
Part-of: odoo/odoo#87672
Before this commit:
There is a obsolete method _action_remove_members in tests which is not
needed now
After this commit:
Removed this obsolete method
Task-2824921
closesodoo/odoo#88988
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds missing translations in the 'Print' and
'Action' items of the action menu. It also fixes the
current translation (env._t must not be used in the
template directly).
closesodoo/odoo#89094
X-original-commit: c16194c1449edaaf994cb49d2173bdb27253c0cc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: SplashS <sergey@shebanin.ru>
Usecase to reproduce:
With BoM structure
- Product A (RR 1-20)
|
Product B (MTO)
|
Product C (RR 5-50)
|
Product D (Buy)
Launch the RR. The MO are:
Current Behavior
- Product A 20
- Product B 20
- Product C 50
- Product C 70
Expected Behavior
- Product A 20
- Product B 20
- Product C 50
It happens because the MO are created as draft during the
`_run_manufacture` and are confirm at the end of
`_procure_orderpoint_confirm` in '_post_process_scheduler`.
However at the first MO for product A, it creates a MO for product B
and since it consumes product c, it checks if the orderpoint should be
trigger. MO for product C still "draft" and the orderpoint forecast is
now -20, so it will create a new procurement for product C with 70 units
To fix it we take the MO draft linked to the orderpoint for the
forecasted quantity.
closesodoo/odoo#89079
X-original-commit: 199a0dd0f013655a3c2345a41bc7c721e09bfc68
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In a project burndown chart, we currently have two measures, "Count" and "# of tasks".
Those measures are identical, but the default "Count" one is less explicit.
We only want to keep "# of tasks", but rather than discarding the default measure,
we could rename it and remove the other one.
This commit removes the "# of tasks" measure, and renames the default "Count"
into "# of tasks".
Task-2734458
closesodoo/odoo#86110
Related: odoo/upgrade#3357
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When invoicing a tracked product, the lots/SN delivered (or the related
quantities) are not always the correct ones displayed on the printed
invoice
To reproduce the issues:
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create a product P:
- Storable
- Tracked by lot
3. Update its quantity > 5 with lot L
Use case 01:
4. Create and confirm a SO with 5 x P
5. Process the delivery
6. Create an invoice
7. Edit the invoice line:
- Quantity: 1
8. Post and print the invoice
Error: The quantity related to lot L is 5, it should be 1
Use case 02:
4. Edit P:
- Invoicing Policy: Ordered quantities
5. Create and confirm a SO with 1 x P
6. Create and post the invoice
7. Process the delivery
8. Print the invoice
Error: There isn't any information about delivered lot L
Use case 03:
4. Create and confirm a SO with 3 x P
5. Deliver 1 x P (with backorder)
6. Invoice 1 x P + Post the invoice (-> INV01)
7. Deliver 2 x P
8. Reset, post INV01 again and print it
Error: The quantity related to L is 3, it should be 1. Moreover, if the
user then invoices the 2 others P, posts and prints this second invoice,
it won't contain any information about L
OPW-2730270
closes#81444closesodoo/odoo#89088
X-original-commit: 3598c0c8cda813efa1aebc17f041e4c0a1a29f06
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
`o_editable` is not supposed to be removed.
Example of a problem if o_editable can be removed:
In translation mode, when deleting the text of the `o_editable` container,
that container could be removed but shouldn't.
See https://drive.google.com/file/d/1U_NUFBvUninOuFKn2H2c4BDcka3OetlD/view
task-2810332
closesodoo/odoo#89071
X-original-commit: 2010c0e2c402f5bb423a0fe683e51923e1e14042
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit
The items of the megamenu were not saved after being translated
After this commit
The items of the megamenu will be saved after being translated
task-2810332
X-original-commit: d159e7ffd30645d346a8a04ca281a728878c83ed
Part-of: odoo/odoo#89071
The function `setContenteditableLink` makes all the `contenteditable=true`
that are not the link or in the link being `contenteditable=false`.
Before this commit:
If we click on a link A then we click on link B, and if link B has
elements being `contenteditable=true`, the first click makes them
`contenteditable=false` and the second do not makes them
`contenteditable=true`.
After this commit
If we click on a link A then we click on link B, and if link B has
elements being `contenteditable=true`, the first click makes them
`contenteditable=false` and the second click now makes them
`contenteditable=true`.
task-2810332
X-original-commit: 72dd8d6e3c95f614353b1e87322a67c877c255c7
Part-of: odoo/odoo#89071
Order of karma needed is ascending now.
closesodoo/odoo#89087
X-original-commit: b29bfd65c6f55cd9ff4f8a899d8648bb8ba000ca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit moves some business logic from component AutocompleteInput
To model AutocompleteInputView, as a step to move further to having essentially
all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2817076
closesodoo/odoo#89077
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Python library currently holds a limitation when we use a formatted email
that is longer than 78 characters (e.g. "Long Company Name With Long Record
Name <email@domain.com>"). Python folds address if is longer than 78 chars
and a bad management of quotes breaks the reply-to. Even if anything should
technically be ok with the RFC python seems to incorrectly handle it (please
refer to [1] for more details and discussions).
Until this is finally sorted out we decided to avoid issues by shortening
reply-to. To avoid that issue when formataddr would return more than 78 chars
we return a simplified name/email to try to stay under 78 chars. If not
possible we return only the email and skip the formataddr which causes the
issue in python. We do not use hacks like crop the name part as encoding and
quoting would be error prone.
Task-2602862
OPW-2733513
[1] See https://bugs.python.org/issue44637closesodoo/odoo#89081
X-original-commit: d2d705708a11de68d8dd9d9edf62e0a33ddb066b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.
Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.
Task-2579306
closesodoo/odoo#89076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently, when accessing a URL with a sorting encoded value,
the system will raise an error with a specific message, which
feels unfriendly to the user as well as saves unnecessary logs
in the log file. So we decoded that value, if except then sort
a page without sorting.
closesodoo/odoo#89072
X-original-commit: 33356fcc9867ee23fee2a032dcca7daea1ada4c5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, the settings recovered from the localStorage were
incorrectly loaded to the model fields.
This commit fixes this issue.
taskId-2823292
closesodoo/odoo#88828
X-original-commit: 5b429e54b732257075e0925211e9ab9b0b827ca1
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Project app
If a user has Project/User group but does not have any Timesheets group
or Analytic Accounting group, he cannot access the Project app (a
security error message appears).
The problem is some of 'project.project' model's fields is computing
based on 'account.analytic.line' model, which the Project/User group
does not have the right to read it.
This PR adds corresponding groups to these computed fields, or changing
the computing method to make sure there is no error if project user
reads on the 'project.project' model.
closesodoo/odoo#87393
X-original-commit: 9df63eb25bfe65bce43a557b8635d967fa5a8d6a
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
** = hr_timesheet_attendance,project_timesheet_holiday,
sale_timesheet
Purpose of this commit to improve generic usage of
timesheet app.
So, in this commit done following change:
- change no content helper for reporting menu actions.
- change no content helper for attendance report menu action.
- make timesheet editable in batch.
- add suspicious duration filter in timesheet search view.
- add analytic tags in timesheet views only visible when analytic
tag feature enable from accounting settings.
- remove group group_no_one from section_leaves div.
- remov group group_no_one from timesheet group in leave type
form view.
- improve search view.
- remove form view reference from project_id of timesheet.
- add a condition for decoration danger in o2m tree view for
timesheet_ids in project form view.
task-2725525
closesodoo/odoo#82305
Related: odoo/upgrade#3355
Related: odoo/enterprise#23284
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In some cases, it is not possible to produce a tracked product that has
been used as a component of another product.
To reproduce the issue:
1. Create three products A, B, C:
- A storable
- B storable and tracked by lot
- C consumable
2. Update on-hand qty of B
- 10 x lot L01
- 5 x lot L02
3. Create two bills of materials
- Product: A
- Components: 1 x B
- Product: B
- Components: 1 x C
4. Produce 15 x A (MO01)
- Note: it should use 10 L01 and 5 L02
5. Produce 15 x B with lot L03 (MO02)
Error: When marking MO02 as done, a user error is displayed: "Cannot set
the done quantity from this stock move, work directly with the move
lines." The user should be able to mark the MO as done.
When confirming MO02, it confirms the associated SMs. Since the
conditions are respected, we try to assign both consumed and finished
moves. Because of step 4, there are two quants for the product B in the
production location (one for L01 and another for L02). Therefore, when
reserving the qty of the finished move, two SML are generated. As a
result, when marking MO02 as done, we write the `quantity_done` on the
finished move. This triggers the inverse method and leads to
`_multi_line_quantity_done_set`, where the error is raised because the
done quantities are not defined on each SML:
https://github.com/odoo/odoo/blob/1354081e43b71edbd434dccc6df6d0881c672a81/addons/stock/models/stock_move.py#L363-L364
Thanks to `_set_quantity_done`, we can write these done quantities on
each SML (and then the incorrect lots will be replaced by the producing
lot).
OPW-2752436
closesodoo/odoo#89015
X-original-commit: 65efb3ec5416fab6bb9ba0a015565b2abb3928cd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
With this commit: we are changing fiscalyear_last_month to March if
chart template is Indian chart template as fiscal year ends in 31 March
in India.
task-2723849
closesodoo/odoo#81982
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
1. pos.config is in company1
2. create a partner with company = company2
3. change pos.config to limited partners loading
4. open the pos ui (to call load_pos_data)
old behavior: access error
closesodoo/odoo#89013
Now: method is called without error
X-original-commit: eade911354dac775b3b96212698dbb7e2d644390
Signed-off-by: Masereel Pierre <pim@odoo.com>
In res.partner the Fiscal Information Tab content was broken than to a
bad adding of the Gross Income fields. This PR solves the problem.
closesodoo/odoo#88704
X-original-commit: 23f5aa3c105ca33f0146ba21d7f463a8310688c4
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit fixes "box-shadow" assignations added by default when using
Bootstrap's `.btn` classes, which result into an undesired "outline"
effect on selected buttons.
Task-2821469
closesodoo/odoo#88458
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Current SCSS is replaced with global Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2821469
Part-of: odoo/odoo#88458
In case the karma gained for the quiz is 0, avoid showing:
"Amazing! You earned 0xp".
Instead, show a standard completion message ("You did it!").
Task-2790997
closesodoo/odoo#86497
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently when uninstalling SMS notifications linked to SMS are kept but set as
email notifications. This makes no sense as they are not linked to any outgoing
mail.mail or email address. As the SMS are removed and as the SMS feature is
not available anymore it is better to simply remove existing SMS notifications.
Task-2778461
closesodoo/odoo#88970
X-original-commit: f307a6c19a2dbe64ba6120a00610063f256102d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
``CRM`` application calls ``phone_get_sanitized_number`` on partner model to
synchronize lead values to its partner values. This method is defined in
``mail.thread.phone`` mixin. ``Partner`` model inherit from this mixin in
``SMS`` application which is auto install after mail and IAP. If this app
is removed, code is not reachable anymore and lead synchronize fails.
How to reproduce
* install CRM and its automatically installed dependencies;
* uninstall IAP;
* run lead unit tests -> synchronize crashes due to missing method as partner
does not inherit from the mixin anymore;
In this commit we define the missing methods on Partner model directly into
phone_validation. In SMS the inherit order is fixed so that the mixin method
takes over the manually defined one.
Fixes#79460.
X-original-commit: eefac25da8d8a01e5f7da8fab35810da402c0bd9
Part-of: odoo/odoo#88970
Co-authored-by: Thibault Delavallée <tde@odoo.com>
In some cases, due to rounding errors, the state of a MO is incorrect
OPW-2753598
closesodoo/odoo#88964
X-original-commit: d349743c99e042ecd798aa2079695339cc9e80c5
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
If the user triggers several orderpoints one by one, some purchase order
lines may be merged while they shouldn't.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a product P:
- Type: Storable
- With a vendor V
- Route: Buy
3. Add two reordering rules to P:
- Min=Max=1 at WH/Stock
- Min=Max=2 at WH/Stock/Shelf 1
4. Inventory > Operations > Replenishment, trigger the orderpoints of P
(one by one)
5. Open the generated PO
Error: There is only one line with 3 x P, there should be two lines (1 x
P + 2 x P, one for each orderpoint). If the user confirms the PO and
receives the products, the destination location will be Stock or Shelf 1
(depending on the last orderpoint triggered)
Running the orderpoint leads to `_run_buy`, where we try to find an
existing PO line so we can update it (else we will create a new one):
https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129
Here is the issue: the filter in `_find_candidate` contains an `or True`
that makes a whole condition useless.
Considering [1], the condition on `move_dest_ids` is only relevant when
an orderpoint is defined. Therefore, we can remove the `or True` and
improve the condition
[1] 63fffa0bee
OPW-2720868
closesodoo/odoo#88959
X-original-commit: 0802d4c61d7b47f0b32a36c5bb0ec49a0f425043
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce the bug:
- Create the workcenter_1:
- Time Efficiency: 100%
- Capacity: 2
- Setup Time: 1
- Cleanup Time: 1
- Create the workcenter_2:
- Time Efficiency: 100%
- Capacity: 4
- Setup Time: 10
- Cleanup Time: 5
- Alternative Work centers: workcenter_1
- Create a storable product “P1” with BOM:
- Add any product as component
- Add operation:
- Duration: 60
- Work center: Workcenter_2
- Create a MO:
- select “P1” as Product
- Qty to produce: 4
- Confirm and Plan
Problem:
The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time
while workcenter_1 must do two cycles
As the Time Efficiency = 100%, so:
Total duration = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle
Work_center_1 = (1 + 1) + 60 * 2 = 122
Work_center_2 = (10 + 5) + 60 = 75
The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM
in the calculation for the alternative work center
opw-2821749
closesodoo/odoo#88945
X-original-commit: deb87a6abf8b8ccc4328eaac21430eedc2536361
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Go to inventory > Reporting > Inventory report
- Click on “Inventory At Date” > Select a date > Confirm
Problem:
The date is not displayed in the breadcrumb, like in inventory valuation
opw-2791566
closesodoo/odoo#88943
X-original-commit: d7a09a257bfb3690a4b580ed26bbf2894a74a6c3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Step to reproduce :
-set your company country in Italy
-install accounting
-install contacts
-create a new individual contact
-set the country address of this contact to Italy
Expected Behavior:
No problem
Current behavior:
Error message in function _l10n_it_normalize_codice_fiscale
Explanation:
In this fix commit https://github.com/odoo/odoo/commit/702c01661f255fe9ebbfc04c90b2cd0fa194d1e8
the case where vat is unset but the country is Italy is not rejected
anymore and a unset value is passed in _l10n_it_normalize_codice_fiscale
opw-2822259
closesodoo/odoo#88846
X-original-commit: fb5c8adc8aa86491cd2175f60c17d17bbd60b57b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
1. _get_payment_method_codes_to_exclude was not considered on _compute_payment_method_line_id
2. to avoid duplicating code on _compute_payment_method_line_id we can directly call available_payment_method_line_ids
3. to avoid re-defining dependencies (and make inheritance easier) we can use 'available_payment_method_line_ids' on _compute_payment_method_line_id
4. fix docstring, _compute_payment_method_fields does not exists anymore, it's called _compute_payment_method_line_fields
5. fix using "self" instead of pay when calling _get_payment_method_codes_to_exclude
closesodoo/odoo#88666
X-original-commit: 63d46ba547c3b0fbadd7c076451659734ad767ae
Related: odoo/enterprise#26167
Signed-off-by: Florian Gilbert <flg@odoo.com>
This commit is to prevent "AttributeError: 'NoneType' object has no
attribute '_name'"
When an xmlid does not exists, the _xmlid_to_obj returns None and the
condition was failing when trying to retrive the model name.
Closesodoo/odoo#88273closesodoo/odoo#88503
X-original-commit: e1be4b5c2dca0ca11bad724a4714f5f71c16de4f
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
