This way we keep the current behavior of the barcode client action but
we don't display move lines on receipt.
Users could edit the view, display "show_reserved" and check it to get
back the old behavior in the form views.
task-2028780
Co-authored-by: svs-odoo <svs@odoo.com>
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
A POC for a new ribbon widget has been recently introduced at 02fbb73.
It adds a ribbon on the top right of a form to make some status more visible
and more user friendly. This commit greatly improves the design of this
ribbon in order to have a real ribbon.
You have to specify the text attribute to show the text on the ribbon.
You can also specify a bg_color attribute to color the background with a
bootstrap background color class according to the business meaning of the
flag displayed in the ribbon.
CRM: Replace Won / Lost bootstrap badges by ribbon widgets in lead /
opportunity form view.
Various: Next to 883c96b and recent ribbon widget update some form
views have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to handle error.datetimepicker event of
datetimepicker element. If not handled then window.onerror will handle it and
give unexpected warning via crashmanager. Note that this issue comes from commit
e6d4ab84da which binds window.onerror in frontend
also and hence uncaught javascript error is also handled by it.
As we do not want to raise crashmanager if user enters wrong value in
datetimepicker let us handle it in survey.js correctly.
Task 2044512
Also see https://github.com/odoo/odoo/pull/32132closesodoo/odoo#35609
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Next to 883c96b781 and recent ribbon widget update some form views
have to be updated. It is best displayed following those rules
* after oe_button_box in order to fix overlapping;
* before image to overlap it cleanly;
LINKS
Task ID : 2032621
PR : #34662
Task
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
Replace Won / Lost bootstrap badges by ribbon widgets in lead / opportunity
form view.
LINKS
Task ID : 2032621
PR : #34662
PURPOSE
Have a nice ribbon widget to display state of records: part II
SPECIFICATIONS
A POC for a new ribbon widget has been recently introduced at 02fbb737b9.
It adds a ribbon on the top right of a form to make some status more visible
and more user friendly. This commit greatly improves the design of this
ribbon in order to have a real ribbon.
You have to specify the text attribute to show the text on the ribbon.
You can also specify a bg_color attribute to color the background with a
bootstrap background color class according to the business meaning of the
flag displayed in the ribbon.
LINKS
Task ID : 2032621
PR : #34662
* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale
Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.
cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.
task-2027274
closes: #34571
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, a discount could only target the whole order, the cheapeast
product or a specific product.
With this commit, it becomes possible to select multiple specific products.
This will ease some realistic ecommerce flows.
For instance, one might create a promotion targetting all his bikes by simply
adding all bikes products into the specific products field. This is easily done
with the many2many widget on the form view.
task-33737
closesodoo/odoo#35500
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Commit b62ebab58 refactored "all the brol" but left half the occurences
untouched.
It was therefore hard to read and understand the tests as the same items would
be referenced with 2 names.
In the favorites menu, it was possible to create two
favorites with the same name (contrarily to the
specifications). The root cause of the problem was that
the submenus of the favorites menu were not updated at
all. This commit fixes that situation.
closesodoo/odoo#34902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When toggling a favorite filter, the options used by
the active date filters/groupbys and the field created
via autocompletion were not correctly cleared, leading
to strange situations. This is fixed by this commit.
A previous commit modifies the way in which
date filters work in the Filters menu.
In particular, the attribute default_period of filters
with date attribute cannot take anymore values
like 'this_week', 'last_7_days',...
This commit modifies the xml acoordingly by replacing
the attributes date and default_period by a suitable
domain.
Task ID: 2028787
This commit modifies the functioning of date filters
in the control panel Filters and Group By submenus.
For a filter with date attribute set, the list of
proposed options is shorter but allows a bigger set of
domains to be quickly created (through combinations of the options).
The resulting list of domains is different of the previous one:
domains like "Today" or "Last Week" are left aside but many others
(and their unions) are now accessible.
The domains generated in that way are no more dynamic but it is still possible
to save dynamic filters in general.
This commit also reintroduces the multi selection of options for groupbys of type
date/datetime in the groupby menu.
Task ID: 2028787
Before this commit, when we use `testUtils.patchDate`,
the function `Date.now` was not using the fake date for reference.
This is an issue with the lib momentjs, which instantiate the
current date as follow:
```
new Date(Date.now())
```
Because of this, we were handling patched date and unpatched moment
objects.
Task-ID 1902848
If "force_create" is false and no account was
previously create, the function will raise an
error. With this fix, an empty recordset is
returned.
closesodoo/odoo#35664
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Selling a product you don't have in stock anymore triggers a message
without pertinent information about available quantity.
This commit adds a little widget on sale order line to inform the salesman
there are not enough quantity available. Clicking on it will reveal:
* The estimated delivery date
* The actual quantity on hand
* The quantity forcasted at the estimated delivery date
For kit product, the quantities are the maximum occurence of kit available
regarding components quantities.
Task 2003485
closesodoo/odoo#34336
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When updating the schedule date of a picking, the schedule dates of its
stock moves are updated. However, their date field isn't. According to
the help of the date field, its value should be equal to the
expected_date field until the move is done. That's probably why the
virtal_available computed field only take care of the date field its
`to_date` domain.
As this is a long standing issue, it seems safer to adapt the computed
field's domain instead of fixing the date should be equal to expected
date until done thingy.
task-2003485
The forecast report added in b311d9c always shows the stock in all locations
even in multicompany/multiwarehouse.
This commit change the SQL query that gather the product quantities over
time to take the warehouse into account and be able to filter on it.
regarding stock.move, the warehouse is the source location one in cast of outgoing
move and the destination location one in case of the ingoing move.
Furthermore, the SQL query doesn't filter the product on their type. That
means a stock move on consumable product will be shown even if this product
Task : 2003485
The stock module adds 4 quantities on products:
Quantity on hand
Incoming quantity
Outgoing quantity
and Forecast Quantity
Forecast Quantity is equals to Quantity on hand + Incoming quantity -
Outgoing quantity. Those two last ones are computed from the open stock
moves wainting to be validated but the reservation is not taken into account.
This commit introduces a fifth quantity 'free_qty' that acts like the forecast
one but only with reserved quantities.
Since ed18095127, some google fonts are included. The "Open Sans" fonts
prevents RPM packaging to work because of white spaces in file names. This
is a Python setuptools bug (https://bugs.python.org/issue809163) which is
not yet fixed.
With this commit, the "Open Sans" directory and ttf files are renamed
into "Open_Sans", solving the packaging problem.
closesodoo/odoo#35661
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Follow up of 61de1c263a
- Remove the dangerous **kw from the route in favor of specifying useful args.
- Use the existing method to link attachments to message instead of duplicating
the logic in an incomplete manner.
- Fix an issue where the actual email would not be sent if the message was empty
but an attachment was defined.
- Ensure the send attempt is done immediately instead of after the cr commit.
The goal is to show potential error messages correctly to the user with the
crash manager instead of a generic error page.
This also increases the send timeout and prevents the error in the first
place in most situations.
closesodoo/odoo#35263
Signed-off-by: Christophe Simonis <chs@odoo.com>
PURPOSE
Improve daily use of eLearning by improving backend actions (notably
attendees management) and performing a back2basics improvement
flow on front-end (duration computation, allow to install surveys directly
from frontend for certifications, various design improvements).
SPECIFICATIONS
See sub commits and tasks for more details.
LINKS
Task ID 2045620 (PR #35415) allow to remove attendees from backend
Task ID 2007294 (PR #35516) better duration computation
Task ID 2026846 (PR #34592) onboarding and back 2 basics
closesodoo/odoo#35635
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Ease discovering of eLearning features by allowing to install surveys
directly from frontend in order to allow certification.
SPECIFICATIONS
Add a button in Upload a document to install Surveys. This button only
appears if surveys is not installed.
When button is clicked, ask for confirmation before installing survey.
LImitate this feature to group system: system people should see the button
and use standard ACLS about module installation.
LINK
Task ID 2026846
The 'index_content' field was only filled when uploading from the frontend.
That would lead to inconsistent results when creating/updating 'presentation' slides from the slide.slide form view.
The field was also not cleaned if the slide content changed.
As it's usage was not very clear (only on a 'search', and not very intuitive), we simply removed the field.
The completion time of a slide now has default values for slides of type
* video (duration of the YouTube video);
* PDF (number of pages * 5 minutes);
This computation is done when uploading a slide in frontend or by an onchange
in backend. Field can still be given / modified by elearning people as
result may not be reliable (pdf parsing is not accurate, and/or you may
estimate time differently from strict page-based computation).
The course will sum up all durations of its (active) slides. Display has been
changed from "x minutes" to "x hours y minutes".
Task ID 2007294
Since af690f678f one can toggle the free preview boolean directly from
the slide list view in frontend. It is therefore not necessary to add
this checkbox when uploading it.
Task ID 2007294
PURPOSE
Improve attendees management by adding a button to remove them in backend
of eLearning.
SPECIFCIATIONS
In order to easily remove a attendee from a channel, we add a button in
the slide_channel_partner tree view, accessible from channels (attendees).
Remove a slide_channel_partner implies to remove the related slide_slide_partner.
Also code backtracking for the view of attendees of a course: we redirect
to the slide.channel.partner model instead of res.parter because
we want the possibility to create/remove/edit attendees for a
course and not making action on res.partner model itself.
Task ID 2045620
- Since commit https://github.com/odoo/odoo/commit/f5cd483216af01001f44a41f7d48f042b9f56ff9
the method `_lang_get` doesn't fallback on a language if the asked language
isn't found.
This causes issues with `formatLang` that uses the language on the
context, which is the language set on the client browser (in most cases).
Meaning, if 'en_US' is the only installed language and a customer
has set his browser to `fr_FR`, when calling `formatLang` this will
crash since no language has been found and `format` on `res.lang`
requires a singleton.
closesodoo/odoo#35633
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Provide documentation for the `form_view_id` attribute on gantt
view.
Task-2050019
closesodoo/odoo#35590
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
All views defined in the 'enterprise' addons have their validation done
manually in their respective addons. Each one ? No, one rebel still
resists to the standart way to work.
This commit moves the gantt validation to put it in its module. The idea
is (for developper) to have only one module to change when adding feature
in gantt view.
Task-2050019
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Purpose of this merge is to add Mass SMS application allowing to send SMS
in batch. It is build on mass mailing application but with its own menus,
views and flows.
See sub commits for more details. Here is a summary of main changes
in this merge.
PHONE BLACKLIST
Add a blacklist mechanism for phone numbers used to send SMS like
what already exists for email addresses when sending emails.
Define a new phone.blacklist model, holding a number and the state of the
blacklist (active field), as well as tools methods to access it. Make it
as private as possible, accessing it in sudo once access are granted.
Define a new mail.thread.phone mixin computing the blacklist status of a
record.
BLACKLIST / ERROR IN COMPOSER
Support blacklisted and already-done numbers when sending SMS :
* blacklist support: necessary to avoid sending SMS in batch to people that
asked to stop being spammed;
* already-done support: when performing mailing in batch or doing A/B testing
we may have already-done SMS;
When sending SMS in batch, already update state and error code of SMS that
should not be sent
* blacklisted number: set to canceled, with blacklist error code;
* duplicated number: set to canceled, with duplicated error code;
* invalid number (cannot sanitize): set to error, with either missing number
if void or wrong format if not void;
SPEEDUP BATCH LOGGING
Allow quick message creation by allowing create multi on mail.message.
Also introduce a new helper tool method to log in batch on records.
IMPROVE SMS COMPOSER ONBOARDING AND USE
Clean the use and options of sms composer after FP feedback, notably
* see https://s.nimbusweb.me/share/3167586/ap1xpy95rz29a5cys576 as basis;
* globally, do not display invalid recipients, only valid / invalid count
as well as current selection / active domain counts;
* consider logging a note as default behavior when using the composer;
* simplify code: when doing a mass SMS, send SMS and attach a simple note
to the document;
Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.
MASS MAILING PREPARATION
Prepare mass mailing module to addition of mass_mailing_sms.
Mailing model: mailing type
* add a mailing_type selection field;
* mass mailing contains only 'mail';
* synchronize medium accordingly;
* update actions of mass mailing application to add a domain on mailing
type being 'mail';
Mailing contact
* remove is_email_valid field as its purpose is achieved by email_normalized
field coming from address mixin (added by blacklist management);
Mailing contact subscription
* clean a bit fields and views as this should stay a technical model;
Trace model and report: trace type
* add a trace_type selection field;
* mass mailing contains only 'mail';
ADD MASS MAILING SMS
Create a new application called "Mass SMS" that follows the structure of
mass_mailing application.
General guidelines
* use the fa-comment icon for this module;
* add a "Notification type" field to the mailings: email or sms. Set it
invisible and set as domain from context when choosing mass mailing or
mass sms application (menus / action specific);
* adapt the metrics from Mass Mailing to SMS
* sent = received = whether the SMS was sent or not;
* opened => we don't have this information;
* replied => we don't have this information;
* clicks = from link tracker (no change of behavior);
* bounced = SMS that failed to be delivered because the format is wrong;
* exception = any issue when sending SMS;
* keep the Mailing Lists menu, hide email related fields on contact model;
* settings: hide the "Specific Mail Server" feature
Opt-out and blacklist handling
* we do support mailing lists because they could come from different sources
and are a way to communicate with a specific audience (and not just a list
we bought), e.g. subscribe to this list to be kept updated whenever this
product is back in stock, or to receive results of this ...
* if the SMSing is from a list, opt-out removes ourselves from the list;
* if it is from the contact ==> Sent to blacklist;
* allow to attach unsubscription links in sent SMS, redirecting to a new
route in mass mailing SMS allowing quick unsubscribe and/or blacklist
of phone numbers;
Error management
* if the user clicks on Send Now / Schedule / Test and does not have enough
credits, open the "Insufficient credits" modal in a lazy option (aka when
having failed statistics linked to insufficient credits);
* on the mailing, we however display this failure as :
* a message on the mailing kanban view
* a message on the top of the form view + same behavior as the mailing and
"Could not be sent" https://www.screencast.com/t/BExgd1Gc;
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* remove center buttons, corresponding features either moved to fields
list (handle / bin on exported, etc...) or removed
entirely (e.g. clear)
* replace XLS to XLSX format, increases rows# to 1048579
* add FAYT filtering of available fields
* sort available fields alphabetically (CI) always
* change export templates UI: remove buttons
TaskID: 1910953
closesodoo/odoo#32339
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- Clean form view
- Add a new widget to check if IBAN account number is correct
- On the res.partner model, default value for "is a company" is True.
TaskID: 2025362
closesodoo/odoo#34691
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to help discovering the new mass SMS application
by adding some data. Some mass mailing data is also udpated to be a bit
more interesting / up to date.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
svs-odoo