When working in multi-company, and each company using its own currency,
a pricelist for the second company should be created. For instance, our
default company is in Belgium -> € and there is a default pricelist in €.
Then you create a second company in US -> $. It is impossible for the us
company to sell in its own country because there is no $ pricelist.
When creating the second company, if the currency is different than the
first company one, the default pricelist in the currency should be created.
In all the cases, a ir.property should be created to link the
'property_product_pricelist' on the 'res.partner' to the new company.
Furthemore, a small usability improvement. The currency should be
activated before creating the company. So we change the label to indicate
that behavior and make the action in target new to prevent the creation flow
to be broken
This is a rather large change for developers: from this commit on, we
need to use debug=assets instead of just debug to split assets.
The About menu has been slightly improved as well (the link does not
appear when we are already in debug mode), and an option has been added
in the debugging menu to activate the assets debugging mode.
After a refresh or when opening odoo in a new tab, if view_type="form" is
specified in the url, RPCs to load the default multi-record view will be
performed if/when the user clicks on the breadcrumbs.
Moreover, the view manager is directly initialized with the res_id to load
after a refresh on a form view, to prevent the form view to fetch the defaults
values, to render in 'create' more, and then load the requested record and
switch back to 'view' mode.
Some code refactoring as well:
- don't propagate state to the view_manager, but directly the view_type and
res_id
- remove unused argument no_store from switch_mode()
- view_registry.get(): remove unused second argument
- no need to switch_mode in do_load_state() as the correct mode is now loaded
directly, even if it is a mono-record view
Also adapt code in dashboard.js according to changes in view_manager.
Always initialize a view_manager with its dataset and views, but without the
action (at least explicitely, as the action might still be given within the
options).
This is a backport of changes in enterprise to keep the view_manager's API
similar in both repository, which is required the large refactoring that will
arrive.
Since 27a7cab52b, it may happen that the
stock.history view contains duplicated id (mutliple quants with
different lots for a single move).
Regroup serial numbers in order to keep a unique id per row.
opw-669349
On the event page and on the event list page on a website, add a
label "participating" for the logged users that are participating
to the event to avoid mistakenly double-subscribing. But we don't
hard-prevent it, because it should still be possible to subscribe someone else.
Small improvement: The portal group in general settings was hidden. We set it
visible because it contains some useful options like 'Allow external users to
sign up'
This field was relevant before the salepocalypse, it is no longer.
Replaced by generic payment providers instead of putting paypal payment methods
in account.
Remove it from the res.company and res.config model
Remove the method `_migrate_paypal_account` as it was used to find paypal
accounts based on the removed field
Closes#11231, task-22286
Specifying the partner_id in the search does not give the same
result as the portal_sale module, which actually lists all the
SOs/Quotes/Invoices where you or anyone from your company is the
partner_id. To make the backend and frontend listings consistent,
let the ACL and ir_rules do their job (these are defined in the
portal_sale module).
When creating work center, a resource.resource record is created.
Then a member of group_mrp_manager is allowed to create resource.resource record.
opw:671218
Edge >=12 throws an error (code 800a025e) when calling the select()
method on an input element that is not currently part of document and
has a non-empty value.
When adding a paymentline a "change:selected_paymentline" event gets
triggered which in turn triggers the focus_selected_line function before
the actual paymentline gets rendered.
opw-671426
`account.move.line.company_id` is a related
to `account_id.company_id`
`account.bank.statement.company_id` is a related
to `journal_id.company_id`
Any attempt to set the `company_id` value
when creating or writing records for these models
will result to the update of the value in
the related record (the update of `company_id` in the
`account.account and the `account.journal`), which
will result in the update of the `company_id` value in all
records in which this related record is used
(in all `account.move.line` where this `account_id` is used,
in all `account.bank.statement` where this `journal_id` is used).
In other words, the more a database had `account.move.line`
or `account.bank.statement` records, the more
it took time for the pos sessions to be closed.
To force a company for an `account.move.line`
(`account.bank.statement`), you must just
set the correct `account_id`(`journal_id`)
in the first place.
For instance, for the `account_id`, passing
`force_company` in the context ensure to choose
the `account.account` from the right company
property.
See
`local_context = dict(context or {}, force_company=company_id)`
which is set in `_confirm_orders` just before calling
`_create_account_move_line` which retrieve
the account from the
`property_account_receivable_id` property.
opw-671362
The versionning has not been created for editing view with the website
HTML Editor, it can leads to several issues, among which are:
- getting the wrong view (good key but bad version) in the HTML Editor,
- losing view inheriting the modified view
So this commit remove the HTML Editor when a version is currently shown,
if a view needs to be edited with the HTML Editor it should be done only
on the 'master' version.
opw-667225
customize_template_get which gets template inheritence informations was
not taken into account by website version, so at one time we could get
an erroneous view version instead of the wanted one.
This commit refactor some of the code adding a function to sort view and
find the most suitable one (based on website and version in request).
This function is then used in ir.ui.view `_view_obj`'s function to
select the correct view.
related to opw-667225
- The test for %f/%d is useless, eveybody has been using %s for
ages, and the psycopg2 error is pretty explicit if you don't.
It can introduce a small but useless delay for long queries.
- The duplicate except block was redundant with the generic `except
Exception` block, with only a different log prefix.
+ the logging for the type testing of `params` was useless too,
raising a error is enough (though that particular test is still
relatively useful because the psycopg2 error isn't very clear
when you mess up the parameters)
That way queries are visible at DEBUG level while they
are executing, rather than after the fact, making
the log less confusing to watch when long-running queries
are involved.
Closes#11182
For a message to be considered as a private message,
the message must have:
- `no_auto_thread` set to `False`
in other words, it must not be attached to a thread
- no `model` or `res_id` must be set on the message
meaning the message is not attached to a specific
record thread.
See `_get_message_id` in `mail/models/mail_message.py`.
Before this revision, the mails sent from
`Discuss` > `Send mail` were not regarded
as private messages,
but as a kind of mass mailing messages,
with a `reply-to` wrongly set.
Any attempt to reply to these mails
failed with a delivery failure notification.
This was because the `message-id` of these messages
contained `reply-to`, and such message-ids are
treated as a special case in the messages routing
(basically, the match on the mail references is disabled
for these messages containing `reply-to` in
their message-id).
opw-669241
Commit bfa68b433 adds the field `date_planned_end` in the Gantt view.
However, the Gant view will perform search on this field, which is an
issue since it is a computed field without any `fct_search` defined.
opw-669042
To reproduce the bug:
- Create a partner.
- Set it state "Alaska".
- Country becomes "United States".
- Set a country for YourCompany, such as Spain.
- Create a partner.
- Set it state "Alaska".
- Country remains blank.
Also, `node.xpath("//field")` was running over every `<field>` in the
view, not just those inside the `<div class="address_format">`. Now it
only traverses the right nodes, which renders every affected view
faster.
1) Configure the warehouse "Your company" to pick-pack-ship operation
(you'll need to activate the advance route on WH config + set up the
correct process through the warehouse configuration wizard.
2) Create a SO with a product (on stock) and confirm it
3) Display the deliveries, you'll have 3 : pick, pack, ship
4) Take the pick, force availability if needed, and confirm it
5) Return the pick and validate (e.g. imagine you missed something like
puting the lot, so you want to reverse the pick).
6) Go back to the SO, click to view the deliveries
7) You create another, new, pick here (which is correct). Take it and
confirm it.
8) Look at the pack => his state is "Waiting another operation"... This
is not good ! We should have it "Ready to transfer" (now "Available")
because we just (re)confirm the pick operation.
Odoo don't know he should make the next operation (pack) available.
When there are no available action buttons on the email (as Follow, View Task,
Convert to Opportunity), i.e. when the user/partner is not an employee, and
when the message subtype is 'Discussion', send a plaintext mail instead of
a formatted one.
Use case: Strange to receive a mail like this when you're on a lead and you
receive formatted mails.
The ERP managers (users with 'Access Rights' rights) cannot even click on
the Settings app menuitem. Because of 2 things:
- The Dashboard settings is accessing the model ir_module_module. So
we set a groups 'group_settings' on it.
- The Users view is accessing the model ir_module_category to groups
the aggregate and display the settings. So we change the security rules
by giving the access to the group_erp_manager instead of group_settings
- The global rules opn companies was applied to the erp managers. We
splitted this ir.rules into three new ones on portal,public and employee
users to allow the erp managers to access the companies
- Writing on the res_groups was calling the method _update_user_groups_view
in all the cases. This method should be called only when the view was
needed to be modified, i.e. when the category_id is modified for this
group.
- The 'Extra Access Rights' is now hidden out of debug mode
- The fields 'company_id' (current company) and 'company_ids'
(allowed companies) are hidden if there are no more than 1
company in the database.
- If there are more than 1 company, the fields are displayed
on the user form view and setting more than 1 company on the
user will add him into the group 'group_multi_company'. On the
same way, setting only one company on a user will remove him
from this group
- The group 'group_multi_currencies' is displayed on the General
Settings. Enbaling this feature will add all the users into this
group. This is more accurate as this feature is more global
than per employee.
This additional administration group was formerly used to hide
the configuration menuitems for the common users.
Being manager should be enough to access these items
Yannick Tivisse