addendum to commit da6b9d1be443999028f021ff81b4cf128a4eaaa2
- better employee name and image for default employee in data (xml-id: hr.employee_root)
- in demo data hr.employee_fp renamed to hr.employee_root to not have 2 employees linked to the root user
- renamed all occurences of employee_fp to employee_root
Before this commit, tours were disabled for mobile mode by returning
an undefined value in the web_tour.tour JS module. This made the use
of "tour.register" or "tour.run" crash, thus making the runbot go red
if this happened while phamtomJS was running.
As it happened, some of the frontend tours goes by "preview the site
on mobile mode" which then trigger this JS crash.
This commit makes the web_tour.tour module return a fake tour object
with a register method which does nothing and a run method which
warns the user that tours cannot be launched in mobile mode.
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
- rename models from hr.equipment.something to maintenance.something
- add concept of maintenance team and dashboard
- remove generic alias for maintenance
maintenance is not dependant on hr anymore. A new module hr_maintenance is
added that adds hr-related fields (employee owner, ...). This way maintenance
is a stand alone application.
hr_equipment module is renamed to maintenance. No change is performed to the
module itself. It prepares further changes, mainly splitting maintenance from
hr_maintenance.
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.
Denis Vermylen (dve)