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
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
This override was always sending the document to all the recipients.
If the user is only a follower, he sees the button but cannot access
to My Account as he's not a user.
Some computed fields have been added in v9 and are calling the method
_compute_day. This method accesses the project related to the issue
So a user portal is able to see his own issue, but cannot open the
form view as the prefetching is loading the fields. Hiding them in
the group base.group_user doesn't have any effect as the compute method
is called on the read. These information may have their importance to
the customer too.
We decided to compute these fields on superuser access rights.
Also the field project_id is displayed on the project_issue form view.
As this information is internal, we're hiding this also under the employee
group.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
The access/follow/actions buttons on the notification email template
are sent only to employee. For this particular business model when
want all the users to receive them, as the portal users.
The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.
To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".
But with f7fe753 when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).
With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.
closes#11224
related to: #11216, opw-660269
When the stock.picking record is linked to some pack.operation records,
the move line state displayed has to be the move line with the same product as
the one in the pack operation record.
opw:671192
As it's done few lines below,
in `set_message_done`.
The user could have a notication associated
to a message he has not, or no longer, the
write access, but he should still be able
to mark it as read.
opw-671188
Adding an attribute with only one value does not recreate the product,
but write this attribute on every product instead. However, the current
filter is not correct: it checks if the given attribute value is not
already in the list of attribute values of the product.
The appropriate check is to verify that the attribute itself is not
already in the list of attributes of the product. Indeed, there is a
constraint to prevent the same attribute to have two different values on
the same product.
BTW, it's a new api function (`mapped`) inside an old api module. Not
the cleanest way to do it, but simpler to write.
opw-671114
Damien Bouvy