Some accounting model (i.e. account.tax) are redefining the ORM search
method, but with misordered arguments (placing count as fifth argument
instead of context).
For the export function, this lead to have the "context" variable
associated to the "count" function variable. As "count" is then
considered as True, the method returns the number of records instead
of the list of record ids. This then exported the last record (the
count'th one) instead of all the records that matched the domain.
The solution here is to explicitly give the context variable by name.
This was possible to create custom fields `x_*`
but seen as base fields.
For instance,
- Go to Settings > Technical > Database Structure > Fields
- Select a field (any)
- Click on the model link, to be redirected to the model form
- Edit & add a custom field from there.
- Save
- Notice that the field you just added is saved as a base field.
We solve this issue by assuming that all created fields and models
are customs, except the ones created by the ORM, by the database
initialization, the fields coming from the modules in python.
We therefore remove the mechanism on which a field was set
as custom according to the fact `manual` was set to True within
the context: This is now the case by default.
No change was required for the base fields: The `state` `base`
was already forced for those fields, that are created using
direct SQL requests `INSERT INTO`.
opw-657312
When a portal user opened his quotation form,
all buttons of the regular form were available.
They were not working, due the access rights,
but it's better to hide them.
opw-657654
The drop ship address was missing from the view, making impossible to
specify the address where the products needed to be delivered.
The fix adds the missing field to the view, and make it visible (and
required) if the delivery must be done at a customer location.
opw-657054
It is now possible to follow tags in the forum app. When following tags you
will be notified for every new post linking this tag.
A small karma update is also performed. We now correctly use karma to retag
posts, and karma to create new tags.
Leads can be archived / unarchived. It is not necessary to keep the mark as
lost button. This button is used in opportunities but is redundant with
archive in leads.
The filter `Sales` in the sales orders search views
was defined as
`[('state','in',('progress','Done'))]`
but
- progress no longer exists. It's `sale` now.
- `Done` is the label, `done` is the value
opw-657552
Messages are required to be displayed in a smarter way: relative to the
current date, if it's a recent message, or absolute if not. This
commits rework most of the date processing code to comply with these
requirements.
Messages were preprocessed each time a thread is rendered, which is
stupid. It should be preprocessed only when the message is created.
This was a small problem because livechat does not use the chat manager,
so a simplified version of the preprocessing had to be done.
Locations were search & read each time you changed
the quantity of a product in a picking.
Once the locations loaded the firs time, this is unlikely
the locations will change during the operation. It shoudln't,
at least.
Therefore, for performances, we avoid to load the locations
each time the picking is reloaded.
opw-648529
Fixes#8344
- Remove _inherit = ['utm.mixin'] on some reports and models. It make no sense
to set campaign_id, source_id or medium_id on reports according to the
cookies.
- Add an inheritS on the source_id in the mass_mailing model. Naturally, the
source_id name is the mass_mailing name.
- The medium is hardcoded as beeing 'Email', which is rather easy to understand
- Remove the 'Tracking' tab on the mass_mailing view.
We do not want to set the medium,campaign or the source automatically
from the cookies on reports, or on mass_mailing creation.
The fields Total Receivable and Payable are calculated as debit-credit.
However, this leads to a wrong computation if, for example, a payment is
used to pay several invoices. For example:
- Create a customer invoice of 2500 USD
- Register a payment of 3000 USD
The Total Receivable will be 3000 USD instead of 500 USD.
At the same time, this commits changes the sign of the field. The help
depicts the Total Receivable field as "Total amount this customer owes
you". Therefore, one would expect that if the customer owes 250 USD, the
Total Receivable is 250 USD, not -250 USD.
The same logic applies to Total Payable.
opw-657053
>
> This merge adds some basic data to notification emails headers. It contains the related
> record of the notification. This allows users to classify / perform action based on
> headers.
>
> Headers :
> - X-Odoo-Objects: list of records
> - X-Odoo-db-uuid: database uid
In task and issue, we had the parent project and the tags in the headers.
`categ_sequence` are stored related fields, to `sale_layout_cat_id.sequence`.
Setting a default value for them has as side effect to rewrite
the value on the related field.
To reproduce the issue:
- Create a sale layout category, with 10 as sequence
- Create an invoice with one line, with this sale layout category
- Come back to the sale layout category,
notice that the sequence has been changed to 0.
Besides, as the sequence was rewritten on the sale layout category,
the sequence was rewritten on all sale order lines and invoice lines
having this sale layout category.
If you have a bunch of them, this could take a while.
The `categ_sequence` default value is supposed
to come from the sale layout category.
opw-651937
Activities in opportunities are now handled through a wizard and not through
the form view anymore. The wizard is called via a Log an activity button. The
wizard allows to log an activity and to schedule the next activity. It
replaces the various <next activities> / Done / Cancel link buttons on the
form view that nobody seemed to inderstand.
As atexit function are inherited by subprocess, the pidfile was always
deleted when the first worker (http or cron) died. Now, only the
process that created the pidfile will delete it.
This commit tries to correctly use messages from the cache instead of all
messages. This means that we need to correctly add messages to the
domain-specific caches, and correctly invalidate them when necessary.
Also, to avoid increasing the algorithmical complexity of the process,
particular care was made to avoid scanning too many lists. For example,
the channel caches have now a messages field, instead of message_ids.
Unsetting the URL of the menu `Home`,
in Settings > Configuration > Website Settings > Configure Website,
leaded to the unavailability of the website.
opw-657572
applied_on:
The field applied_on in pricelist rules is not taken into account:
- In the price computation
- In the name computation
When creating a pricelist item, if you select (applied_on = Product)
first and set a product, then select (applied_on = Global), and save the
rule, the computation will still take the product_tmpl_id in the price
computation.
Instead of fixing the whole _price_rule_get_multi method, this patch
sets the fields that should not be taken into account to False.
compute_price:
Add a behavior similar to the applied_on field, to reset unnecessary
fields to zero when the computation method is changed.
Original idea from @tgr-odoo
opw-657148
Closes#9671
The expiration date will now be set when installing the enterprise
'web' module instead of at the init of the database since putting
an expiration date on a community edition database doesn't make sense.
- Differentiate between the Community and Enterprise editions
in the version number. By adding this attribute on the global
odoo JS object in the web client bootstrap controller /web,
we can differentiate between versions easily on the client
side without extra RPC calls.
- Remove a couple of version-related RPC calls in case
the global version info is present in the JS environment
- Update "About" panel to display the edition info
- This commit also reverts 07fe5afc87
which implemented the idea in a more limited way.
Closes#9625
This window action did not open the create form
view as a leave allocation but as a leave request,
which was inconsistent with the very similar
open_allocation_holidays action. With the former,
the duration field was two dates. On the latter,
it was only a number of days, as it should be for
leaves allocations.
qsm-odoo