Before this patch, if the current stage was common to all sale_teams, at merge, it was removed
because we was searching only in the stages dedicated to this sale_team without the common stage.
Purpose:
1/ In the lunch app, previous orders list: the products are not displayed.
It is written X Records but you don't see the products name. Therefore
the information is useless.
2/ It is dangerous to be able to delete a previous order that has been
received (it changes the lunch account amount)
What is done:
In Previous Orders list :
- The view should be based on the sales orders lines. In that case, each
line = 1 product.
- add a note column (between product and status)
- add a user column (between status and total)
- Rename Total into Price
- If order.line status = ordered or received, it shouldn't be possible
to delete it. An ir.rule has been added to achieve this.
- An additional group access right check is made in the actions 'confirm'
'cancel' and 'order' because they can be called in batch under the
Action button.
Before 3959afc the `node` tested would be the selection containing node,
but since then it may have been a `<br/>` which has some damaging
effects: now entering double enter at the end of a list, quote or code
block doesn't end this block.
Testing the use case corrected by 3959afc, the said change seems to have
no effect so this commit reverts it.
opw-667618
When a "Drop Shipping" route is used on a product, the origin document
is duplicated on the PO created. This is because in this case,
po_rec.origin and procurement.origin are the same.
opw-671039
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.
Hitesh Trivedi