Mass mailing option is activated on attendee and track models. Using
the _mail_mass_mailing parameter on class allows to see those models
in the mass mailing application without having bridge module.
This commit also improves the scheduled mail form view and slighty
improve labels related to scheduling mails on event.
When computing default recipients to mail on some records, take into
account models having a partner_email field. Indeed this method checks
for some commonly-used partner or email fields to find recipients.
This allows to avoid having custom methods in each model. This commit
adds support for partner_email email field used notably in event and
track management.
Currently when scheduling activities, duplicate logs are created. Indeed
a message is posted when scheduling an activity, editing it and marking it
as done. This leads to a lot of noise being created on records.
This commit remove logs when scheduling and updating an activity. A sole
message is posted when the activity is marked as done.
Scheduled activity display in chatter is also improved to better
differentiate the user creating the activity from the user who is
assigned to the activity.
Once it is deleted, the expense is blocked in the "posted" state.
Accounting entries should rarely be removed but never when linked to expenses
Closes#15704
All the fields defined in model "product.product" from module product_margin
are computed and not stored with the same function which is _compute_product_margin_fields_values.
This function has a deprecated argument which is field_names and this agrument is only used in
function read_group overwritten in this module in model "product.product. This overwrite of
read_group uses a variable "fields_list" with almost all the fields defined in "product.product"
in this module (excepted: date_from, date_to and invoice_state which are read from the context).
Each time, the fields total_margin, expected_margin, total_margin_rate, expected_margin_rate,
date_from, date_to, invoice_state were needed, nothing was returned due to the empty argument
field_names passed to this method. For example, when opening product.margin.form.inherit form
view.
In old API, it works because the compute was called with the list of the fields and in new API, it is not the case.
Closes#15604
opw:709962
The timezones are already managed in the JS.
So on the attendance check in/out screen when a user clocked out
after 8 hrs he got a message saying that he has been in for more than 12 hrs.
opw:710161
In case an exception (programming, out of memory or any other unexpected
failure), the cron_thread would crash and not recover until server restart.
Issue #15666 was an example of failure.
Courtesy of Nils Hamerlinck
If postgresql database is temporarly down, the cron thread may fail.
The cursor creation fails when trying to connect to the server which leads to
the cron thread to die (uncatched exception) and will not restart when postgres
is back.
Fixes#15666
The fuzzy search score algorithm is quite simple, but had an interesting
problem: for the search string 'AB DEF', the result 'XXAXXBXXXXXXX DEF' had
a higher score than the result 'ABX X DEF", because it has 4 consecutive
matching characters.
This commit slightly tweak the algorithm to take space into account, but
to make sure they are not used to compound the score for a string. This
means that space characters are not ignored, but are not really
as important as a normal character.
The signature _check_recursion already exists in odoo/models.py
So calling _check_recursion, the function which checks the constraint on
associate_member overwrote _check_recursion in "res.partner" model and
the function _check_parent_id defined in "res.partner" was completely
wrong because it needs _check_recursion defined in models.py
opw:710524
Fine tuning this commit: 95038f0bf3
standard_price is company dependent.
Writing the standard price in sudo because a warehouse manager may not
have the right to write on products.
opw:709329
The boolean field `is_mail_thread` on `ir.model` allows to create custom models
that inherit from model `mail.thread`. The selection field `track_visibility`
on `ir.model.fields` allows to add tracking on custom fields.
Also change the order on model `ir.model` to make mail thread models appear first.
Steps to reproduce in runbot 10.0:
1.Create a new sale order and use the Odoo Monthly quotation template.
It will set the Odoo SAAS product on the sale order.
2.Go to the Odoo SAAS product form view, check "Can be expensed",
then on Invoicing tab, choose "At Cost" for the "Re-Invoice Expenses" field.
3.Confirm the sale order so it is in done (Locked) state.
4.Create an invoice, try to validate it, a UserError is raised:
'The Sale Order SO0158 linked to the Analytic Account must be validated before registering expenses.'
This UserError only makes sens when new SO lines are created.
NB:Now it's possible possible to update an analytic line linked to SO in other state than 'sale'
but it's still forbidden to create a SO line when the state is different than 'sale'.
opw:708661
As message_post is defined on mail.thread abstract class its api.returns
is not automatically added on overridden versions of the method. This
commit add missing api.returns on all overrides of the method.
Change the condition from
[...] and debit != and credit != 0
to
[...] and (debit != or credit != 0)
as at least one of debit or credit may have an unaffected value
Without this patch a past unpaid entry will not be included in the report.
Closes#15550
The separator in the debit/credit columns of the report must contains coma
instead of dots for decimal separator (fr).
All the other columns (cf SQL query) contains coma but not this one.
Inverse the currency sign of the credit column. Otherwise the credit is negative
and sum of the balance is wrong (sum credit != debit)
Closes#15550
Main features
* removal of old saas-3 compatibility layer
* removal of pseudo-default calendar computation
* cleaning and improvement of code
* correct management of timezones
* new mixin class replacing inherits on resource model
* more tests
* removal of hacks in stock_calendar
As standard code of resource module now includes attendances and leaves
in computed intervals, there is no need to keep hackish overrides of some
resource methods. Everything should work from base module.
Purpose is to replace existing inherits of resource.resource by an inherit
on the mixin itself. The mixin offers several methods to compute working
intervals, attendance, hours, ... This mixin will be improved in future
commits when new methods that will be required with future improvements
of various service apps.
This commit also adds tests for the mixin itself. A new model is defined
only for testing purpose to test the mixin.
Currently timezones were not or incorrectly taken into account in resource
computation. Indeed complexity comes from attendances being expressed in
naive timezones valid for all users, whereas dates and leaves are computed
into UTC. Computation should always be done in user timezone so that there
are no overlapping days and all time intervals are correctly computed.
A new timezone field is added on leaves to know in which timezone they
were originally encoded. Indeed putting them in naive user timezone
require its original timezone, not the current user timezone, as those
can be different.
This commit also contains code cleaning in resource to be a bit more
pythonic, simplify method parameters and offer a more simple api to
other modules.
Eventually code field is removed on resource as it is not really necessary
for resources. It is explicitly added on workcenter model who use it.
Calendar and resource scheduling work on time intervals. However in some
cases it is useful to have info about attendances and / or leaves linked
to those intervals. Internal interval tuples is thus extended to keep
records about resource.calendar.attendance and resource.calendar.leaves.
This will notably allow to remove some hacks in stock_calendar module.
Hooray.
Old methods are still present since a long time and are deprecated since
saas-3. This compatibility layer adds unnecessary complexity to the module
API. Those methods should now be removed. Some renaming is also performed
to ease resource api understanding, notably to better differentiate
internal methods from other methods.
All addons are updated accordingly.
Mitali Patel