The button "Group By" and "Measures" were untranslated
opw-2421769
closesodoo/odoo#64015
X-original-commit: b4249c9125bd9b6077425636f67dec0303554da8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce the bug:
-Let's consider two vendor bills VB1 and VB2
-VB1 and VB2 have both a PDF in attachment P1 and P2 respectively (the original bills from the suppliers)
-Let's consider that P2 is encrypted
- In the list view of vendor bills, select VB1 and VB2 and print original bills
Bug:
An error was raised because it is not possible to merge P2 with P1 as P2 is encrypted.
opw:2389679
closesodoo/odoo#63999
X-original-commit: 0918b29ce765a159ba2b128bca9170f1230fdb78
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The call to reset() when simulating requests during HttpCase tests
leaves the test class into an inconsistent state. Indeed, the test
environment is no longer into Environment._local, and this may trigger
record cache errors, because new environments use a record cache that is
different from the test's environment.
As this issue only occurs in the context of unit testing, it is not
worth fixing on a stable release, because of the involved risk.
Instead, we modify the test so that the failing operation is made in
method setUpClass(), before any environment reset.
closesodoo/odoo#63730
X-original-commit: c8604df6e3eab4090ffcb4c3f311e72c8bceac7c
Related: odoo/enterprise#15439
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The Python constraint method `_check_unique_sequence_number` performs an
SQL query, and therefore needs to `flush()` the some fields before doing
so. However, it uses a generic call to `flush()`. In some situations,
the call to `flush()` ends up into recursive flushing, and that's the
beginning of a nightmare:
- write on account.move.state,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.line.qty_invoiced,
- which reads field purchase.order.line.invoice_lines,
- which calls flush() for account.move.line.move_name,
- which computes account.move.line.move_name,
- which computes account.move.name,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.invoice_status,
- which uses the not-yet-computed value of purchase.order.line.qty_invoiced,
and computes an incorrect value.
We fix it simply by making the call to `flush()` more specific: we only
need to flush 4 fields. This avoids the nightmare above.
X-original-commit: cf5f50a733ddfd87985a39ffe7daffc48cfb582f
This fixes an issue that occurs when marking fields to compute in the
following situation:
- it occurs before the actual modification,
- a relational field is marked to compute,
- the same field is traversed to inverse some dependency.
When the marking occurs after the modification, the traversal of the
field should actually recompute the field. However, if the marking
occurs before the modification, the inversion of dependencies must be
based on the current value of the field. This is the case with method
unlink(): we call method modified() to mark the fields that currently
depend on the records to be deleted, and the fields must be computed
only after the deletion!
X-original-commit: cd19c2d93db8911fe42802640ea32e5d87aadeec
Behavior prior to this commit:
- normally when editing the Scheduled Date on a MO, the date on the
related stock moves is updated. However this does not happen once the
MO is planned
- if the date is edited and the MO is planned, the MO is automatically
unplanned, but the date on the stock moves is not automatically updated
Behavior after this commit:
- when the date is updated on the MO and it is planned, the dates on the
stock moves will automatically update, so that the behavior is
consistent with how it would work if you clicked Unplan first then
updated the date.
Note:
- this commit is forward ported from 14.0. Only the unit test was
ported, as the behavior had already been modified to match the
expectation.
opw-2417108
closesodoo/odoo#64006
X-original-commit: 97f79960dbb3aa371378f576cfdce9670ca8ccce
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
When performing the onchange for the first time on a new record, if a
field has a default value, it could be two times in the `todo` field
list to compute.
closesodoo/odoo#64005
X-original-commit: cf2b0a505c117a50a91fa022bc1d6bf1eb6d9f77
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Commit [1] recently tweaked the way floats are generated in the
SampleServer, as they are now rounded to 2 decimals. As a
consequence it sometimes generates integers for float fields (e.g.
5 for 5.00). This is also what the real server does, so it's fine.
However, a test was asserting that float fields were floats, so
this test sometimes failed and thus needed to be adapted.
[1] https://github.com/odoo/odoo/commit/81f2bc7closesodoo/odoo#63992
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Problem
-------
Recruitment pipe is design to work better if you archive the
lost/refused candidate rather than moving them in a specific column
this practice is reinforced by hr_referral.
Therefore, the other application button should take into account
archive applicant
Solution
--------
- count archived applicant
- show archived applicant
closesodoo/odoo#63982
X-original-commit: f242160eb06067ad56dec1c9acfbfe068ad1c6a1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
for repeat_type = 'forever' recurrences.
Consider a recurrence creating a task every 15th day of the month.
When the cron runs, it updates the next recurrence dates of the
recurrence.
But currently, the updated "next_recurrence_date" can be set to an
earlier date than today, if the fixed day of the recurring task is
earlier than the current day.
This means that the recurring task to create every 15th of the month
will be created the 15, the 16, the 17, the 18, ... until the next month
begins (no task will be created when the cron runs before the 15th of a
month).
This commit enforces the next recurrence_date to be set after the
current cron run, to ensure a task isn't wrongly created multiple times.
This commit also includes the tests that led to the discovery of this
bug.
closesodoo/odoo#63989
X-original-commit: e4943afef0f66703bafd78780764ff6f0b039d3e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For recurrences of repeat_type = 'after', the daily cron would create
tasks infinitely.
* The cron creates recurring task for all recurrences for which
next_recurrence_date < today.
* next_recurrence_date was never updated.
This commit ensures that next_recurrence_date is set to False for
repeat_type = 'after' recurrences, when the last recurrence is created.
X-original-commit: e7be857bea964628b80d4d3c1314dc231e0da947
Previously, the transparency color for shapes was not taken into account
when handling the preview state transitions of the background shape
snippet option. This caused strange behaviours where the shape
transparency color would always get reset when it was a class color,
either when changing to a different shape (expected, all shape colors
should get reset) or when changing any other shape setting like other
shape colors or flipping the shape (not expected). On the other hand, if
the transparency color was not a class color, it would always remain
untouched, when changing other shapes settings (expected) but also when
changing shape type (eg Origins 01 -> Blocks 02, unwanted).
This commit fixes that by cloning the entire shape container during
preview, and restoring it on preview-reset.
task-2380815
closesodoo/odoo#63955
X-original-commit: 39baa6dadd8b34d4a210b6fedd1c20c5df2621f6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Themes define records which are used as templates for the creation of
base model records on theme installation on a website.
E.g. a "theme.ir.attachment" record's purpose is to be a template for an
"ir.attachment" record creation on theme installation on a website.
Those final records have extra fields to indicate from which theme
template they come from. If those records are ever to be duplicated,
they should not duplicate those links to the theme templates otherwise
it may cause issues when uninstalling/updating a theme (you want the
records linked to the theme to be deleted/updated but not the duplicated
ones, which do not act differently from user created ones).
Duplicate ones will be linked to the website anyway (just like "normal"
user created ones) and should only be automatically removed if that
website is deleted.
The issue is more visible from 14.0 where applying some modifications to
images via the editor (crop / filter / optimization / ...) will
duplicate the original image before modifying it.
closesodoo/odoo#63951
X-original-commit: 890935bbdf924b06b7dabd89802f6dd824159a4b
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
We add a index on the workcenter_id and workorder_id, both
have a One2many related to (`time_ids` of workcenter and workorder)
and both is in the some search domain in python (also in search view).
(Also change the `readonly='True'` into correct form `readonly=True`
of `production_id`, and remove duplicate fields `workcenter_id` in view)
task-2389380
closesodoo/odoo#63500
Related: odoo/upgrade#2042
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The `bom_id` field has a One2many inverse `byproduct_ids`
then it should by index to avoid bottleneck if byproduct is
highly used by a lot of different BoM
Performance improvements:
When there is 20K of Byproduct line, read a BoM is x1.8 faster.
task-2389380
Add index on the `product_id` of `stock.production.lot` for
several reasons:
- Lot of field domains depending of `product_id`
(e.g. `lot_id` of quant, sml, ...)
- Almost every search on this model contains the field `product_id`
- `product_id` is required and the sparsity is generally high
Performance improvements:
For a DB with 6000 lots, `search_read` with product_id is
x2 times faster.
task-2389380
The `date` fields is only used in the `_accumulate_amounts` of
point_of_sale and is set at now or by the `_prepare_picking` of purchase
(maybe will be remove in the futur).
In all case, and for now, the index is not
used (expected by at a custom search) and should be remove.
task-2389380
Remove index on fields `date_start` and `date_finished`. Both
has not used expected in the gantt view `view_production_gantt`
which not used anymore (and have no sense because it should use
`date_planned_start` and `date_planned_finished` instead.
Remove this old gantt view too.
task-2389380
The state of `mrp.unbuild` is a boolean value (`draft` or `done`) which
is already quite useless in the most of the case. Also this state is
never used explicitly in the code (in a search), then it seems legit to
remove it.
task-2389380
A index of a 2 values columns is quite useless, and it is a
lost of storage for nothing. Also, in this
case it will be never used (expected in manual search).
task-2389380
The `name` fields of `stock.move` is use differently (sometimes it is
contains info of related product, other time the parent document, ...).
But in all case we never search directly on the name of the move, then
we remove the index related to.
Also remove useless keyword `index=True` for the `backorder_id`
task-2389380
Indexed of boolean values is quite useless and the one of `priority`
(MO/Pickings) can be only used in filter search view (`starred`).
Then remove priority indexes from `stock_move`, `stock_picking` and
`mrp_production`.
task-2389380
The index on `create_date` was never used in standard expect in
the group_by of the search but onlu visible in debug. Then
remove the index related too (implies to remove the custom definition
in stock_move). Remove invisible create_date fields in views.
task-2389380
Currently, when we create time off and does not add 'Start Date' or
'End Date', it displays a wrong warning.
Issue is occur because date_from is required field at db level and it's
value computed based on visible field request_date_from which is
non-required field and when you keep that empty it will raisse the
contraint instead of required error.
So in this commit, we make request_date_field field required from view
and also make request_date_to visible based on condition so it should
fill the proper value inside the date_from and date_to.
closesodoo/odoo#63222
Taskid: 2352360
X-original-commit: c54f445ceae72518f787f43213ec78a9a7e1b1eb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- create 2 applications in Odoo Recruitments with the same email
- Notice how they both have a stat button that indicates that this
applicant has another application.
- Refuse one of the 2 applications
The stat button disappear because it ignores archived records, while it
should indicate if someone has already applied in the past
opw-2423158
closesodoo/odoo#63926
X-original-commit: caaef5829b51f7e5862a6d730ea978e19deadd42
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
- Create a new MO
- Remove the company name
The user see a traceback
This occur because the compute method does not check if the company is
set
opw-2422441
closesodoo/odoo#63917
X-original-commit: b7fa0cfad03a8319f03c1aa89eb67635e1200f67
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Issue
- Install "Time-Off" module
- Set user language to "Arabic"
- Open "Time-Off"
Traceback raised.
Cause
On update, JS send to backend date in arabic.
Python 'datetime' library does not manage arabic date.
Solution
Convert date format for the "server" on js-side.
In this case, it will also translate arabic numbers.
Also, adapt "dateToServer" to handle any format.
opw-2421268
closesodoo/odoo#63928
X-original-commit: c11e0fe2673fd18e6db45fd18a153042d525990a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Prevent crash while trying to subscribe to a non existing channel from
a misconfigured snippet.
Also now let the user create the channel linked to the discussion group
directly on snippet drop if no channel is available to select
automatically.
task-2356955
closesodoo/odoo#63854
X-original-commit: 5bb8821c0a78df5c03458a2c902e1a9c7a12f2f9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
those field sizes were deleted from orm definition in 2014 https://github.com/odoo/odoo/commit/026e38b48f3963aed08bba4e76a0a796d662f6a4
STEPS:
* set manifest's summary attribute to a long string
* create empty database
BEFORE: error
```
2020-12-28 10:44:51,325 1 ERROR ? odoo.sql_db: bad query: UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')
ERROR: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
^
2020-12-28 10:44:51,325 1 ERROR ? odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 86, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 338, in load_modules
odoo.modules.db.initialize(cr)
File "/opt/odoo/custom/src/odoo/odoo/modules/db.py", line 63, in initialize
info['sequence'], info['summary']))
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.DataError: value too long for type character varying(256)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 88, in new
odoo.modules.reset_modules_state(db_name)
File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 558, in reset_modules_state
"UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')"
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
return f(self, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
res = self._obj.execute(query, params)
psycopg2.ProgrammingError: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
```
AFTER: database successfully created
---
opw-2415057
closesodoo/odoo#63912
X-original-commit: 2a44e233deffd17460e0e9a8f8225602a28c24a6
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a sales team ST and a POS session PS
- Set ST on PS
- Open PS and make an invoice I from an order
Bug:
The sales team set on I was not ST
opw:2418806
closesodoo/odoo#63898
X-original-commit: 61e5389236ad767827ef2fe039aa78b20848298e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
`product_tmpl_id` of BoM line should be readonly,
there is no sense to change the product template from
the BoM line model. Also it avoids useless write on product
and inverse recomputation.
opw-2420830
closes#63631closesodoo/odoo#63890
Issue: odoo/odoo#63631
X-original-commit: 5a4746141670bdd241d85c7908a57ee9efa56c3f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commits adds kanban view for the 'Generated Documents' for better
readability on mobile devices. Also, for consistency, this commit
adds 'Upload' button on the invoice kanban view as well.
Task-ID: 2152183
Before this commit, there was no difference whether multiple invoices
were uploaded or not. The list view was always opened.
Now, the form view is automatically opened when a single bill
is uploaded.
Task-ID: 2152183
Steps:
- Install Time Off
- Go to Employees
- Click an employee (A)
- Change Work Information > Schedule > Working Hours to "Standard 38 hours/week"
- Go to Time Off > Managers > Time Off
- Click Create
- Select employee (A)
- In the title, select Unpaid
- From 2020-12-20 to 2020-12-24
Bug:
Float representation issue: 4.00 Days (30.400000000000002 Hours)
Explanation:
Changing formatting of `number_of_hours_text` from '%s' to '%g'. This affects the way this value is displayed: 0.0 Hours is now 0 Hours.
opw:2418740
X-original-commit: 0bbd31ca0a2c24fac55e2f6277d727a1d0c58c54
What are the steps to reproduce your issue ?
1. Install ELearning
2. Create a course
3. Add a video from youtube
4. Attempt to do the course from a user that is invited
What is currently happening ?
You cannot complete a video (turn the checkmark green) if there is not a quiz. Therefore you cannot complete the course
What are you expecting to happen ?
Turn the checkmark green to signify that video is completed after watching the video and then have the ability to complete the course
Why is this happening ?
Because of this commit https://github.com/odoo/odoo/pull/61581/files
that changes 'youtube.com' to 'youtube-nocookie.com'
How to fix the bug ?
Remove host
opw-2418545
closesodoo/odoo#63878
X-original-commit: 484957caf89e0f324dffda6f2ac0a1ca543b969b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Steps:
- Install "Belgium - Accounting" and "Accounting"
- Add the Dutch language in settings
- Select a Belgian company
- Go to Accounting > Configuration > Chart of Account
- Select an account like "755000 Financial income - Foreign currency translation differences"
- Change the translation of the account name in English and Dutch
- Create a new company in Settings > Companies
- Select this new company
- Go to Accounting > Configuration > Settings, set the Fiscal Localization to Belgian PCMN and save
- Return in the first company
- Go to Accounting > Configuration > Chart of Account and check the translations you previously set
Bug:
The Dutch translation has been reset and the English one remains the same.
Explanation:
`process_coa_translations()` uses `spoken_languages` as seen here:
https://github.com/odoo/odoo/blob/bb31ce3bc6c0c7e1e101d93924eccea995206733/addons/l10n_multilang/models/l10n_multilang.py#L67
The spoken languages are defined here: https://github.com/odoo/odoo/blob/f4e7e06a1ff9756471d55138575c758f456b5905/addons/l10n_be/data/account_chart_template_data.xml#L10
This is why English is not affected.
The bug appeared with https://github.com/odoo/odoo/commit/c346e7af3314ce504fe3add9e9f6a4839bcad64a
It was meant to apply Chart of Account translations on the current company but applied it on all the companies. This reset edited translations on the other companies.
This commit refactors `process_coa_translations()` so that we can use the same logic on a single company while keeping the definition of the original function intact.
opw:2376334
closesodoo/odoo#63866
X-original-commit: 45e6309aa1d79d06c7110c86205781874ab44e30
Signed-off-by: backspac <backspac@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider a product P with a blocking message BM
- Create a quotation Q and set P on it
Bug:
A traceback was raised.
opw:2421946
closesodoo/odoo#63853
X-original-commit: e0af10ccc92cb3b07f0eea6fa44ebf5a1bdc86aa
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When changing the crop widget from being inside of a modal window to
using an inline crop widget, the functionality to show the currently
active aspect ratio was lost. This commit restores that behaviour.
Linked to https://github.com/odoo/odoo/issues/57604closesodoo/odoo#63859
X-original-commit: df339cd0d65913548646abe6ca8182f06554333c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Kishan Gajjar <kishanegajjar@gmail.com>
Previously, when adding a shape to a child element of a snippet, the
colorpicker to configure the shape's transparency color would also
appear on the snippet itself. This was caused by the selector for the
option not being specific enough, and finding the shape of the child as
a target, and thus showing up in the snippet menu.
This commit fixes the selector so that it only finds the current snippet
own shape, and not shapes of its children.
task-2390341
closesodoo/odoo#63857
X-original-commit: 26abfd452dac2a778e4e2ba4c1c26a0896e82565
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When leaving the Jitsi meeting, if the participant is the last one, the
meeting participant count will still be 1.
To reproduce the error:
1. Go to Events
2. Create and Save an event
3. Go to associated Rooms
4. Create and Save room R
5. "Go to Website" (on R's form)
6. Join the meeting
7. Leave the meeting
- Use the "Leave" icon
8. Go back to R's form
=> "Participant count" is still set to 1.
This fix ensures the participant count will be 0 when nobody is in the
room. However, it will only work if the participant uses the "Leave"
button. So, for instance, if the last participant directly closes the window
to leave the meeting, the participant count will be incorrect. This is a
consequence of Jitsi which does not provide a way to get the number of
participants in a meeting (see file for more details, L119-142).
OPW-2416995
closesodoo/odoo#63852
X-original-commit: 07bb73f133db661f3061c679af15293dbcf8ba38
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
If a user has the portal access, when going to his documents, if one of
them belongs to an archived partner, it will raise a 403 error.
To reproduce the error:
1. Go to Settings > Invoicing > Customer Payments
2. Enable "Invoice Online Payment"
3. Create a customer C
- Set a name
- In Contacts & Addresses, add two contacts C_01 and C_02
- Both are "Invoice Address"
- Add a valid email for C_01
4. Go to Customers > C_01, Action, Grand portal acess
- Check "In Portal", Apply
5. Go to Settings > Users & Companies > Users
6. Remove the search filter, Select C_01, Add a password
7. Create an invoice INV
- Customer: C_02
8. Connect to C_01's account
9. Click on "Invoices & Bills"
- The invoice INV is listed
10. Connect to admin's account
11. Go to Customers, Archive C_02
12. Repeat steps 8-9
=> A 403-Forbidden page is displayed with a traceback.
For a user to have access to the "Invoices & Bills", one of the
followers of each invoice must be part of the same commercial partner:
`('message_partner_ids','child_of',[user.commercial_partner_id.id])`.
Here is the issue: if archived, the partner will not be in the
`message_partner_ids` list. This is the reason why, in our case, C_01
can no longer access the documents.
This commit allows the archived partners to be listed when getting the
portal transactions.
OPW-2417275
closesodoo/odoo#63790
X-original-commit: ad36feae0a1ee6fe0bdfbb622685a6b143ea4f2a
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Martin Trigaux