MRP module is migrated to the new API. It excludes mrp models that will change
quit a lot during the new MRP conversion. Actually most of the code is not
migrated, but at least side models and their methods are already migrated.
This should lessen the diff when writing the new MRP.
Split files and move them according to the new API guidelines. Containing
- mrp splitted into its main models and files
- stock code moved into its own models and files
- various renaming
Change checkout process.
- Billing address is always the connected partner_id or neww partner_id.
- Shipping address is contact of current commercial_partner_id
- New checkout design for address selection
- Add delete a line in my cart
- Fix input quantity size
- Refactor/Reindent xml template from website_sale
- Improve the modularity for checkout (preprocess, posprocess, required fields, ...)
- Allow to use form builder in extra step for OEE (No edit mode)
- Add route to have states according country selected (need to be overridable for website_sale_delivery)
- ...
Now we drop the test where a user is created via the checkout form (public user).
These tests should be rewrite in new api later an test flows for a new customer.
In psql, use LIMIT and OFFSET together without a fully specified and uniq sort order
will generate unexpected behaviour.
Eg:
> id id_dept name
> -------------------
> 1 1 Tom
> 2 1 Mike
> 3 2 Meggie
> 4 2 Marge
> 5 3 Bart
> 6 3 Lisa
> using LIMITed selects like:
> SELECT * FROM employee ORDER BY id_dept LIMIT 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 3
> SELECT * FROM employee ORDER BY id_dept LIMIT 3 OFFSET 6
> You can have some result missings from the 3 requests, and others duplicated.
> Because id_dept is not a uniq order.
res_partner now have a new concept of company_name. (duplicaed of parent_id)
That allow to a frontend user to have a company name without create a useless
tree of "Company -> Partner -> Contacts"
Before this commit, we was using street2 or street field to do the same thing.
That was confusing in some screens because according from where the partner has
been created, the company name was stored in distinct field and that was like
a bug for some users.
commercial_company_name is based on the same behavior of commercial_partner_id.
It is base on the field company_name.
In Partner form wiew, a quick button has been added in edit mode if however
the user want to create the partner tree to add new collegues.
Some address have required state.
We add by default moreover 500 new states.
We try also to merge duplicated states
wich have the same country and code.
Once merge is done, we try to had the unicity constraint
to avoid futur duplicates.
Merge code, should be removed in v11.
We are able to create a currency on the fly. A user should not be able to
create a currency when entering master data, currency should only be added
through the currencies menu item and a part of configuration.
[IMP] rating: website rating page: reviewed design, rate on click, update on submit
[IMP] rating_project: rating_status: 'no' instead of False
[IMP] rating_project/issue: smileys insteaf of thumbs for consistency in kanban
[IMP] rating: allow to update an existing rating (feedback + rate)
[IMP] rating: consistency on rating names (statisfied, not satisfied, higly dissatisfed)
[IMP] rating: avoid deadend after rating, button to go to Odoo
[IMP] rating: res_config better sentence
Setting the env of the qwebcontext is not sufficient because the closure
of the `loader` carries its own contexts and lang, so subsequent t-calls
may still use the original language.
This was broken by the new API conversion at commit
4ddc323139,
and further broken by the forward-port
6c8141a1dfa9fa44067d052b368e3851972d836cA with a wrongly indented line.
Replace employee linked to base.user_root (administator) in data
by employee_fp (Pieter Parker) from demo data in order to avoid having 2
employees linked to the root user.
This prevents a model extension from:
- changing an abstract model to a non-abstract one,
- changing a transient model to a non-transient one or vice-versa.
Using a frozendict as context breaks the `t-lang` mechanism, as
the `loader` is not aware of the changes of a copied frozendict
and thus is still using the values from the original context,
including the lang one.
This reverts commit e1deae7eab.
The form_save payment type is used by acquirers (currently only ogone)
to return a reusable payment token on successful payments. These can
then be used to charge the customer again.
Purpose:
For our internal project management, we would like to track the customer
satisfaction on the open projects. We send them an email every one or 2
weeks allowing them to give a feedback by clicking on one of 3
smileys: Happy, Average, Angry. They can also put a additional explanation.
We already have something similar which is working on livechat with a
unusable reporting, and on issues but unusable. Our project are managed by tasks.
Specification:
- On the project : Selection fields : (Periodical Rating or Rating on Stage)
+ Fields to choose the period if periodical
- On the stage : email_template_id field.
- IF :
---> Periodical : Send an email to all the customers for the tasks on this stage periodically
---> On Stage : Send an email to the customer's tasks when the task reaches the stage
- That way, it's impossible to send a satisfaction request both periodically and sequentially.
FP request
- Who is the customer : The customer on the task OR the customer on the related sales order
OR the customer on the projet OR nobody
- The last feedback is displayed on the task kanban card (Thumb up, down, or neutral)
- On the project kanban card, the customer satisfaction is displayed. This is the simple
mean of all the previous ratings.
When a kit is sold, the unit price of the COGS recorded is the sum of
the unit prices of each component multiplies by the quantity sold.
Obviously, this is not correct since the unit price should not take into
account the quantity sold.
opw-681403
The protection prevents fields to be invalidated/recomputed on some records.
This mechanism is useful against accidental cache invalidation when computing
or inversing fields. It also prevents to trigger the recomputation of fields
before and/or after their inversion.
Add a test on stored field with compute and inverse methods: the test checks
how many times the compute and inverse methods are invoked in several cases.
Essentially, the field should not be recomputed when it is written.
The previous wording was inaccurate and made users think it
was impossible to setup "Net EOM" payment terms.
Updated POT file accordingly, but not PO files because this
requires a proper new translation.
When the kitchen ticket is printed, the order lines appear jumbled in
comparison to what is displayed on the PoS interface. This is an issue
since the kitchen cannot link main and side dishes for a given guest.
For example, the following order:
- Steak
- Fries
- Salmon
- Pasta
- Chicken
- Salad
On the kitchen ticket, this could appear as:
- Salmon
- Salad
- Chicken
- Steak
- Fries
- Pasta
The order actually depends on the product id.
The fix is to use the order line id instead of the product id in the
resume dictionary. Although a dictionary is an unordered collection,
most browsers keep the dictionary ordered. For example:
```
var a = {"18": "18", "1": "1", "21": "21", "14": "14"};
for(var i in a) { console.log(i) };
1
14
18
21
```
opw-680796
The field bom_count appeared twice in product.template form view and
then the smart button for "Bill of Materials" always displayed 0 as
number of BoMs.
opw:681830
Thibault Delavallée