When (re)generating the stock.move.lots in the workorder,
it should use the unit_factor on the move like everywhere else.
This makes sure we do well with the explosion of phantom boms too.
It is also important that if there is no operation_id given
explicitly in the "consumed in operation" on the bom line,
that it still generates the necessary stock.move.lots in the last work order.
Also, in the work order it is better to set the quantities done already.
That way we don't forget to consume them.
* When an issue was set in stage that has a rating email template
and that the project was set on 'rating when changing state',
there was a warning with Failed to render template.
There was a small error in a condition that fired exception.
Review the subtypes
===================
- Add a subtype for the paid expenses
- Correct subtypes wording
Prevent expense report for several employees
============================================
- Can add lines from every employee, leading to account issues (payable / receivable)
Raise an error if you try to report several expenses for different employees
Don't track onchanges on journal_id
===================================
- Expense Sheet, click on Post Journal Entries: you have 2 produced messages, and
one is strange (Journal Entry: * 1 ?)
Remove useless message on chatter
=================================
- Remove the message to say that the expense report has been validated by ...
It's redundant as the visibility tracker already logs this change
Remove unused method
====================
- 'refuse_expense_sheets' is declared but never used
Log a link to the payment on chatter
====================================
Expense Sheet, click on Register Payment: you have a message containing the
payment name (SUPP.OUT/2016/0001). Add a link to the form view.
Expense duplication
===================
Do not copy 'sheet_id' on duplication. It's wrong and has as secondary effect
to duplicate the state too.
Expense Report tree view
========================
Display correctly the widget monetary
New feature in mail module
==========================
Currently, an email can be sent to an alias from:
- Everyone
- Authenticated Partners
- Followers
This commit is intended to add another category: Employees
The main purpose of this new feature is to allow employees to send an email
to an 'expense' alias in order to create automatically their expenses with
their mobile phones.
Use this new mechanism in hr_expense
====================================
Currenlty, we're overriding message_new to make a security check and create
an expense if the sender is an employee or bounce otherwise, which is not the
correct way to achieve this. A better way is to use the alias mechanism now
that it has been extended to employees too.
Don't hardcode email_from
=========================
The email_from of the bounce email is hardcoded to "help@odoo.com". I am sure
they will be happy to receive all answers from any odoo instance
Review the bounce email content
===============================
content: Your expense has not been created because your email address is not set
on an employee or on a employee's user. Configure your employee's information correctly and try again.
-> this is a message for the admin, not an employee or anyone else
Now the content is generical for aliase defined for employees.
This is simply useless and the open door to spam. The inital goal for this
option was to be able to create an expense from any email in the onboarding.
It was even commented with 'Don't use this in production' which is another
point to remove it.
It is wrong because:
- In a saas instance, the employee email = the admin email = the email you
entered while filling the form. So, if the user sends an email with his phone,
the expense will be created. If the user sends an email with another email address
then the expense won't be created but he'll receive an automated email explaining
that he should register his email address either on it's user information or on it's
employee information (professional on employee, private on user for example).
- With this modified behavior, if no email address is matching the sender email address
the system will create an expense with the-first-employee-linked-to-an-user as employee,
which is totally wrong. Furthermore, the guy that sent the email will not see the created
expense because it hasn't been assigned to him.
- Everyone can create expenses, I don't even imagine how fast we can overload the database
with a huge pile of crap
The previous implementation took the parent of the element to begin
the check, which was wrong when the initial element was the html root.
This commit changes the method to a recursive implementation, which is
clearer.
This function attempted to deduplicate states with same code in order
to force the unique constraint creation. This is the job of a migration
script and should not be execute at each update.
Moreover, the current implementation is flawed and may lead to crash in
some situations.
When calculating the stock quantity fields, we can put a
from/to_date in the context. This should work in the past too.
We see the to_date as the date in the past to calculate and calculate
backwards from the stock now to the date in the past.
This is done by doing an extra read_group on the stock moves,
with a similar domain except that it takes the moves done from
date_to.
When you backup 3 dbs with the database manager, you had 3 times the warning.
Underscore is not loaded, so _.once not available.
This commit closes#13173
This commit fixes two problems:
* Clicking on the save button of a web_editor dialog closed the dialog
two times because the button was created with the flag "close: true"
and binded to a handler which closes the dialog. This also prevented
to extend this handler by placing the this._super call in a deferred.
* Some web_editor dialog extended the save callback but forgot to use
the this._super, which prevents the "saved" event to be triggered
(currently not used anywhere but useful for custo and master).
When action_done is called with moves without pack operation, the pickings
linked to the computed moves must be in state done and the date_done must
be set on each picking.
opw:685145
In purchase, a special key is set in the context to simplify the name
of the picking type: instead of the normal name, only the name of the
warehouse is used. This is problematic if more than one incoming picking
type exists for a given warehouse, as it prevents you from being able to
differentiate them. Asking users to modify the view to remove the
context key seem a bit too much to ask for something that should be
simple.
It is my understanding that this was implemented only for cosmetic
reasons, but I am willing to assume that having to select
"YourCompany: Delivery Orders" instead of simply
"YourCompany" for people who only have one picking type should not
be too disruptive or obscure.
opw-685751
Steps to reproduce:
- Create a contact (Company).
- Create a "child" in this company.
- Select "Contact" as type of address.
- Create an individual child of the company.
Bug: instead of having the Individual icon (Human being), it gets the
Company icon (Building).
Fix: the behavior must be the same as in 8.0, the avatar must be used
for a contact which is not a company.
opw:683105
Commit 89a4774c21 changed the kwargs
debug value of the FieldTextHtml controller to let it be equal to
"assets" instead of True or False. The problem is that an empty string
was considered True before the commit and False afterwards.
In fact, the original code was wrong and the debug value should equal
the already processed kwargs debug value in the HttpRequest object.
Indeed, the kwargs.debug value is equal to the URL value while the
request.debug value is already processed and is only one of the 3
values: None, True or "assets".
Since a324b22d, the mass mailing body editor would:
- save english body in language Y if user had language Y,
- not allow to edit translations in another language
This is due to how html_translate is set as translation function of html
only if the field is set as sanitize==True.
closes#13196
opw-685629
Since it is not possible to create a timesheet entry on a issue without a
project_id, the timesheets page in the form view should be hidden if no
project is set.
This prevents the user from trying to create a timesheet entry on the
issue and receive a not so transparent message like:
mandatory field is not set: [object with reference: account_id - account.id]
Jeremy Kersten