Fix error where if no email_from was in openerp.tool.config, notif by mail was not sent
Add optionnal param 'missing' to allow to have missing alarm.
Missing field is the date from the last time that cron had run.
Now we stop to process the next 30 minutes, but we process all alarm since the next cron.
So, an email alarm will be always in delay, but a mail will be sent !
In v8 we use ICP to save the date, but it should be changed in master, maybe we should
save the last execution time in the ir_cron model directly ?
This is possible to set a partner as a free member
simply by checking the "free member" box, in the partner form
This leads to the fact there is no membership lines for this partner
Before this rev., only partners having membership lines were displayed
on the website members page.
When creating and deleting (disabling, actually)an event without syncyng with google,
this is possible that Google returns a 404 status page,
meaning the event we are trying to delete google side do not exist.
We can safely ignore these 404 pages, as the event are not anymore existing
in Odoo side either
opw-627767
When having an invoice with multiple lines having the same
product_id and account_id, the residual amount was wrong.
This is due to the fact the residual amount of each line
was computed on the residual amount of the invoice divided
by the number of lines of the invoice, and the fact the main
select of the sql view was grouped by product_id, account_id.
So, for an invoice defined as
Product Account Total
A 1 10
A 1 10
B 1 10
The invoice analysis, grouped by product, account, computed
Product Account Total Residual
A 1 20 10
B 1 10 10
The residual amount '10' of the first line being
30 (the residual amount of the invoice)
divided by 3 (the number of lines in the invoice)
The residual amount of the invoice should actually be divided by
the number of lines in the invoice * the count
of occurences in the group by clause
So, in this case, (30 / 3) * 2 = 20
Replacing the big jointure by
SELECT count(*) FROM account_invoice_line l where invoice_id = ai.id
to get the number of lines in the invoice
is just an optimization for performances
opw-621672
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
When using %(date)s in the follow-up text in the follow-up levels configuration
the date was formatted within server date format
instead of the partner language date format.
Closes https://github.com/odoo/odoo/pull/5168
The onchange() on new records processes fields in non-predictable order. This
is problematic when onchange methods are designed to be applied after each
other. The expected order is presumed to be the one of the fields in the view.
In order to implement this behavior, the JS client invokes method onchange()
with the list of fields (in view order) instead of False. The server then uses
that order for evaluating the onchange methods.
This fixes#4897.
The module analytic_user_function allows to define a specific product
to use, when creating timesheet activities for a specific employee
with a specific contract
Nevertheless, the product was not set accordingly to this feature
for the first timesheet activity, because,
when initilialing the timesheet line,
the on_change_account_id, which returns
the product to use according to the user and contract, was called
without passing the user.
Besides, by default, on_change_account_id does not have a user_id parameter,
this parameter is added by the module analytic_user_function, overriding
this onchange, and adding a new user_id parameter (which is not a good pratice).
We therefore use multi_on_change_account_id, which allow to pass the user_id,
within the context
A record rule exists on currencies but not on rates.
If creates multiple currencies with rate = 1, we could fetch the wrong one in
the search and get a security exception while trying to convert rates.
Fixes#3323, opw 626353
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
Most pop servers don't perform deletions until QUIT. If for some reason
the process is killed while fetching a large quantity of messages, the
quit method isn't invoked, while the commit method has been. We may thus
end up with duplicated messages the next time we try to fetch. It therefore
helps to fetch the messages in small subsets and call the quit method between
those subsets.
In 7.0, prevent changes in activities of validated sheets was done thanks to the constraint
_check_sheet_state.
In 7.0, python constraints were checked at each write operations
whatever if the fields on which the constraint is were altered or not
This is no longer the case in Odoo 8.0: The constraint is checked
only if the fields on which the constraint is are altered.
As this specific constraint must be applied anytime, whatever the altered fields,
we now do this constraint check in the "write" method.
Besides, it was already the case for the unlink method.
opw-627415
Once a timesheet confirmed, the activity hours should not be modified,
for any reasons.
The constraint _check_sheet_state prevents to modify activities
for confirmed timesheets, but does not prevent the addition
of new activities within the current, but confirmed, timesheet.
opw-627415
fixes#5128
Since rev. 1ce0b70a02, ir.ui.menu
was readable for employees and portal users only
Since rev. 74aa7406bf, the navigation menus
were displayed for employees and portal users only.
Therefore, when sharing a record with the share feature, nothing was
displayed when following the link.
This rev. introduces a new group "Shared group", implied for all shared groups
created through the share feature.
Read access to menus is given to this group
The possibility to display the webclient navigation menus as well.
When sharing a record to a share user (for instance, the quotation),
the action in the url was set to "action_id=" instead of "action=",
therefore, the link sent just leaded to nowhere.
Add country != False in main domain will be not the right fix, because if people doesn't activate the sort by country in customize, they are no reason to hide customer without country_id.
Previously, if you registered enough images to push the ipad one on page two, the test would fail to find it. Now it chooses the image with index 4, whatever it is.
In saas-3, at rev. c7afc04be3
an assert has been introduced, asserting the record_id of the record class
is an integer.
Therefore, write operations using a string as id lead to a crash
if they trigger a workflow
If the list view had a default order,
for instance, default_order="create_date desc",
setting a groupby filter kept this default order
and the groupby list was therefore not ordered on the groupby field
In general, when setting a groupby filter on a list
we expect the list to be grouped by the groupby field
The reset of the orderby is done only when the list is not grouped
and a first groupby filter is applied.
The orderby is not reset when adding a new groupby,
when one was already applied.
It doesn't reset either when passing from 2 groupby clause to 1.
It doesn't reset either when passing from 1 groupby clause to none.
opw-627233
If the date_done field of the model stock.picking is already filled in
it means the user do wanted to have this date of reception date
instead of the moment when the user clicked the receive button.
opw-627219
The creation of a country is not something to create at flight !
The impact could be bigger that what people was expected (no accounting configured, ...).
The bad manipulation is more often the responsible, eg 'Belgium ' was creating a new country with a trailing whitespace, while the user didn't see the difference and use both country withtout making the diff.
This rev. is related to 6641c61ce6
During the above revision, a new jointure has been added
with product_uom, on product template uom_id
The join link was wrong, it was:
- LEFT JOIN product_uom u2 ON u.id = pt.uom_id
and it must be:
- LEFT JOIN product_uom u2 ON u2.id = pt.uom_id
as the alias 'u' is the previous jointure, not this new one.
Besides, the uom_name is now the name
of the product uom of this second jointure
As the uom is now the product default uom
instead of the category reference uom
The groupby clause has been adapted, as the selection was slightly altered
Besides, grouping by u.uom_type, u.category_id was pointless
This rev. is related to 67443b5b17
onchange_template_id returns the attachment_ids as a id list,
not as a *2many command list
The conversion from id list to command list has to be done manually.
At the moment, attachment_ids is the only 2many fields of email.template
Prevent creating/modifying accounting entries made on close periods.
The period_id and journal_id field on a account.move.line is a related so was
silently (without write call) updated so did not triggered the call to
_update_journal_check while modiying the linked account.move
Force the check in the validation of the move. As the move can not be balanced
without going through this method, this will prevent posted entries in closed
accounting period.
Fixes#1633, opw 615886
When converting a datetime field to date, using the widget date,
the date time value was just cropped, removing the hours,
therefore ignoring the user time zone.
For instance, if the user was in UTC + 1, for a date time 02/02/2015 00:30:00,
applying the widget date on this datetime had as result 02/01/2015,
due to the fact the UTC value of the datetime field was 02/01/2015 23:30:00
fixes#4420
opw-621281
Correction of c3c7aa79a0, apparently the tour system doesn't click on the a if the selected element is not the a or an element inside of it, even if the selected item only has the a as child.
This is related to rev. d17f22cde7
Compare float values using float_is_zeor only
if the key is 'value',
meaning the changed value is the actual value of the field,
not another variable of the field (widget, etc.)
For instance, changing the currency_info of a float field
using the monetary widget should not compare the old and new value using
float_is_zero (the values are not even floats).
opw-627166
Field date_order of sale.order model was changed from date to datetime
during rev. 56cbc9421d
When converting the opp to a sale order, we must therefore use fields.datetime.now
which returns a datetime
instead of fields.datetime.context_today
which returns a date
It makes no sense to allow inventories in supplier locations as it won't anyway
reduce the Inventory if we want to downsize the inventory. This makes
the Inventory act weird.
Ex:
1. Initial situation: 20 units of stock A at supplier's location
2. Makes an inventory stating there is in fact 0 qty of product A at that
location (in the hope to remove some quants).
3. Still 20 units in Suppliers location + 20 units in Inventory loss...
Managing specific suppliers destination is currently not supported.
Same issue with production locations.
Fixes#5052
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
Not passing the context should be exceptional, in almost all cases you should pass it.
In this specific case, not passing it will, for instance,
prevent the use of the key 'active_test' in the context,
and there is therefore no way to count all variants, including disabled ones.
This rev. is comparable to 0b18a5afec
The action action_order_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes the active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should probably be performed in master.
On one hand, when a product attribute is shared by several
products, some may use different subsets of its possible values.
On the other hand, when less than 2 values are enabled for
a given attribute on a product, no choice is displayed for
that attribute on the shop page, as there is none to be made.
The way those "visible attributes" were computed in
get_attribute_values() was wrong: when counting the
number of values it used the whole range of possible
values for this attribute (cross-product), not just
those enabled for that product.
This lead to inconsistencies vs the website_sale.variants
template, and products using a single value out of a larger
range of values were constantly marked as "Not available"
in the shop.
The next post button at the bottom of an article was stuck when getting to
the last page. A cookie storing the *all* the visited posts was used
to determine the next one according to a non-stored (so not working) and
unexpected criteria 'ranking'. Also could get articles from other blog.
Instead of this whole broken logic, simple loop through articles by classic
order and go back to first one when at the end.
Better looping algorithm can be used in master where ranking is stored.
Fixes#3097, opw 614559