Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset security_lead when use_security_lead is unchecked to avoid it to be used in further computations
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Various code using the sale_note field (default terms and conditions)
is updated to check the use_sale_note field that is the setting
enabling it.
This is a preferred solution compared to resetting sale_note each time
use_sale_note is set to False in order to avoid loosing the data
users may have entered in sale_note field.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, reset po_lead when use_po_lead is unchecked to avoid it to be used it further computations.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, correctly reset manufacturing lead time
Settings now correctly use an ir.config_parameter telling whether to
use or not manufacturing lead time. An onchange is added in order to
ensure that lead time is not still used by code although the settings
is unchecked.
This commit fixes
* `default_alias_email` is now called use_mailgateway to better reflect its use. When
unchecked the alias_prefix value is set to False in order to
reset the alias.
* empty list message displays receipts alias only if the mailgateway
option is activated
* some code cleaning so that get_default_ and set_ methods are put
into a sole method in order to lessen code size
Fields like `default_foo` still used ir.values although those are system-wide
parameters and should therefore be stored in ir.config_parameter
table.
When no default_model is set on a field, don't prefix it by `default_`.
Also, remove deprecated generation of alias on sales team.
According to usability experts configuring a sales team alias should
be done directly on the sales team view and not through an hidden
and strangely configured settings.
When several user run a production on a workorder, things go awry.
For example the end of the "productive" production is computed based on
ProductiveStartTime + DurationExpected - Duration
so if the duration was bigger than the time expected, we easily get a
productive end before the start, and start of the "reduced speed" before
the production actually happened.
eg:
productive time is 30 minutes
user A: start production at 10:00
user B: start production at 10:10
production is set to done at 10:50
=> result before the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has been productive from 10:10 to 10:00
user B has not been productive from 10:00 to 10:50
this is totally erroneous.
=> result after the patch:
user A has been productive from 10:00 to 10:30
user A has not been productive from 10:30 to 10:50
user B has not been productive from 10:10 to 10:50
this is a measure of right, we could argue about wether one or the other
should be productive or not but this is anyway an edge case.
In master we are considering only allowing one user to run a production
at a time but we prefer not to change such a behavior in stable version.
opw-709223
closes#17528
The tab navigation was only working in edit mode. Entering a readonly form
view with input fields was causing a traceback.
As the default browser behaviour has been overriden with custom navigation,
we need to specify which widget can be focused (e.g.: url, many2one, etc.).
In an empty kanban view, when moving a freshly created record from
the second column to the first one, then moving it back again in to
the first one, the record was mysteriously duplicated.
When moving the record, it should be removed from the old column.
In this case, the second column was not found (and thus the record
not removed) because the iteration was on `parent.count` (which is
the count of records in this datapoint (1 in our case)) and not
parent.data.length (the number of columns).
The mentioned commit exposed a `Dialog` instance thanks to a return and
an event triggering. The forward-port failed in saas-14 as the code
landed in the wrong function.
As the event trigger seems to be useless code without any context and
that this code has been hugely refactored in recent versions, this
commit simply removes it.
Feel free to expose variables again in version 11.0.
opw-748027
* portal, sale
Some primary buttons had both the 'btn-primary' and 'btn-default'
classes, which is wrong. In standard bootstrap, the 'btn-default'
class seems to be masked by the use of 'btn-primary' but it is not
the case in some of our themes.
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
When the user processes a picking with a large amount of pack operations
but validates a few lines (the remaining goes to a backorder), the
operation can fail due to timeout.
Closes#17670
Add the TZ to the datetime tracking. At the moment, the TZ is fixed: it
is UTC. However, this avoids any ambiguity when the tracking message is
sent by mail, since in this case, the datetime is not converted
automatically to the TZ of the user.
Adding a simple 'Z' makes the datetime compliant with ISO 8601, so it is
supported by the web client as well.
opw-747367
Set up:
- Use the usual working schedule from 8:00 to 12:00 and 13:00 to 17:00.
- Set the OS and user TZ to Australia/Sidney TZ (restart your browser)
- Create a BOM with 3 work orders, taking 1, 2 and 3 minutes (you can
use the 'Assemble Furniture' routing)
- Create a MO using the previously created BOM, e.g. for '[FURN001]
Computer Desk'
Case 1: Plan to start the next day at 08:00, e.g. 2017-06-08
The result is amazing. The system probably hit a flaw in the space-time
continuum, which can only be explained with M-theory:
- WO1 is planned from 2017-06-08 08:00:00 to 2017-06-07 08:01:00
- WO2 is planned from 2017-06-07 08:01:00 to 2017-06-06 08:02:00
- WO3 is planned from 2017-06-06 08:02:00 to 2017-06-05 08:03:00
Case 2: Plan to start the next day at 11:00, e.g. 2017-06-08
Once again, the result is literally a piece of art:
- WO1 is planned from 2017-06-08 11:00:00 to 2017-06-08 08:01:00
- WO2 is planned from 2017-06-08 08:01:00 to 2017-06-07 08:02:00
- WO3 is planned from 2017-06-07 08:02:00 to 2017-06-06 08:03:00
To solve the problem, a first commit is made in MRP to force the end
date to be larger than the start date. That hides the issue, but it
doesn't solve it.
To prevent the system to hit the 88 mph and go back in time, we force a
'hard limit' to prevent any selection of intervals starting before the
requested start time.
opw-745905
The mock server had to be modified in order to test this behavior
since it used to throw an error for invalid ids, while the actual
server just ignores it and continues forth with the other ids.
Previously, the button was completely invisible when no icon
was given, which is a regression from saas-15 where the string
attribute is used to write the button label.
Version 2.7.1 is not yet available in most distributions,
but is now considered the recommended version.
Odoo will work just fine with any psycopg2 version >= 2.2, though.
Thibault Delavallée