Previously, if you double-clicked an image in the web editor with the
intention to change it, but the image had already been optimized, and
then repicked the same, already optimized image, the image would be
optimized again even though it had not changed. This commit fixes that
by making the media-dialog not trigger an image_changed event in those
cases, and by leaving the initial image untouched.
Linked to issue #57604closesodoo/odoo#64038
X-original-commit: 4d3655304205cc9785ef696a47a17a41242d297a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
There is no way for _error_checking() to detect conflicts in work
entries that have been introduced in concurrent transactions, because of the transaction
isolation.
So if 2 transactions create work entries in parallel it is possible to create a conflict
that will not be visible by either transaction. There is no way to detect conflicts
between different records in a safe manner unless a SQL constraint is used, e.g. via
an EXCLUSION constraint [1]. This (obscure) type of constraint allows comparing 2 rows
using special operator classes and it also supports partial WHERE clauses. Similarly to
CHECK constraints, it's backed by an index.
1: https://www.postgresql.org/docs/9.6/sql-createtable.html#SQL-CREATETABLE-EXCLUDEclosesodoo/odoo#64028
Taskid: 2357844
Related: odoo/enterprise#15546
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, we check if the bill_type in the project is equal
to 'customer_type' but this field can only be either 'customer_task' or
'customer_project'. Thus, this condition will always be False.
This commit changes the condition to check if the bill_type is equal to
'customer_project'. Then, this condition can be True if the project has
a SOL and his bill_type field is equal to 'customer_project'.
closesodoo/odoo#64012
X-original-commit: d8f7d7369f060f444bcebc0118cc5a2a650f6361
Related: odoo/enterprise#15540
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
No need to force a new title on duplicate if something is already given.
Task ID-2265556
PR odoo/odoo#52391
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, if a badge is set on the survey, duplicating it always
results into a traceback due to sql constraint. Indeed due to uniqueness
constraints between survey and badge having the same badge for a duplicated
survey was leading to an error.
We had two options
* duplicate the badge itself;
* remove sql constraint and add a required on badge in view when having
a certification (aka, survey giving a badge);
First solution is somehow limited. It means updating badge name, checking
its goal, ensuring all parameters are ok. Moreover it is quite hidden when
duplicating survey. End users will maybe not see what to are doing.
We choose to remove copy flag on flag and badge. That way end users have to
manually re-check the flag, and create a new badge. We remove the hard
constraint and set a required in the view so that functionally behavior
is the same.
Task ID-2265556
PR odoo/odoo#52391
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
Samuel Degueldre