On the product_template, the stat button to indicate the purchased quatity
is buggy in several ways.
1/ The states in the read_group domain have been mistaken with the states
on the picking (clap, clap)
2/ The read_group is seeking the fields product_id and quantity. Too bad, on
the model the name is unit_quantity (clap, clap)
3/ The displayed PO lines weren't chosen from a domain. So the computed quantity
didn't correspond to the displayed lines from the button (small clap, clap)
4/ The action_purchase_line_product_tree linked to the stat button is selecting
the PO lines where the product is the product id. Too bad, on the PO line
this is a product.product and on the current object this is a product.template
(epic clap, clap)
1/ Two menus having same id, so changed id of 'Mail Schedulers' menu.
So 'Events Types' menu is visible.
2/ UI improvements(changed menu string: Events Types -> Event Categories,
no more create and edit options for category selection).
The installation of a new acquirer was a bit complicated : from settings,
check the acquirer, then apply (install the module) then list view of
acquirer and finally edit it in form view.
This needed to be simplified. The payment acquirers are pre-filled
in payment. From the kanban view an `Install` button installs and
redirects to the form field.
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.
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.
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
- 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
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
rpi