Sale orders created through the website that have to be automatically
invoiced should ignore the delivery invoicing policy.
Otherwise you can end up with either an invoice not being generated at
all. This means the user has to manually generate and add the payment to
it. Even worse is if only some purchased products have invoice policy
delivery. In this case a partial invoice would be generated to which the
payment would be added, leading to a mismatch between invoice total and
payment amount.
-*- coding: utf-'8' "-*-"
is not a valid encoding. Introduced by
666387a274 I think. It was probably a
typo/replace gone bad and it got copy-pasted everywhere. Emacs complains
every time you try to save changes to files with this invalid encoding.
This changes all of them to
coding: utf-8
adhering to eae045949d.
Done with:
find . -name '*.py' -print0 |\
xargs -0 sed -ie 's/-\*- coding: utf-'"'"'8'"'"' "-\*-"/coding: utf-8/'
Introduces two new options:
- confirm_so: to confirm the sale order on acquirer confirmation
- generate_and_pay_invoice: confirm_so + generation of invoice and
payment registration
website_sale and website_quote both did their own
form_feedback. This causes issues because:
1. it would force upcoming features to have to be duplicated as well
2. there's a risk that improvements/bug fixes will only be applied to
one module, an example of this happening is
46c5f93b6c.
NB:
- The option no_delete is not working, a fix will come from chm
- The many2many widget on a sheet creation is not working correctly as
the called command is a (1, id, values) without a (4, id, _) before.
A fix will also come from chm, but a disgusting hack has been
provided for this particular case (to remove after chm fix)
The former algorithm was incorrect: when checking two related nodes together,
it returned as if a cycle was found (even when no cycle was present.) The new
algorithm computes the transitive closure of the relation from the root nodes,
and stops as soon as a cycle is found.
The third parameter expects a list of field, not some random string.
This made the constraints for the fields tagged with required_if_provider to be
never checked.
Closes#12458
Purpose:
Registration form needs some improvement : When there is lots of question
and answer and sometimes question is too long then view is mashed/weired
Improve the view and show one question and one answer on line, next question
and answer will come on next line,
Also change the common question/answers view, put question answer in
inline and each question/answer should come into next line
Mockup : http://bit.ly/1zpoWju
- Deletion of addon web_tip
- Creation of addon web_tour (a tour being a succession of tips)
- Creation of onboarding tours for several apps:
- Accounting
- CRM
- Discuss
- HR Expense (first step only)
- HR Recruitment
- Project
- Sale
- Various usability improvements (mainly onboarding-oriented)
Also:
- creation of a (archived by default) sample project with tasks, that the
user can activate to discover the project app.
- improvement of the simplified form view to create a new project
* Improve the JS/LESS so that its content makes the tip grow
with a bubble effect (instead of using a popover).
* Avoid flickering when the mouse leave/enter the tip or move
between the tip and its anchor element.
* Use text-align:left instead of justify
* Set the content width in JS (to a larger width) to be customizable
* Round LESS variable to avoid values like 266.6666666666
* Set opening direction according to viewport:
- Top and bottom tips open towards the right except if they overflow
the window on this right
- Left and right tips open towards the bottom except if they overflow
the window on this bottom
* Improve the 'Skip these steps' mechanism (which is easier as we don't
use bootstrap's popover anymore)
Joren Van Onder