This commit applies multiples things:
- Fix PLS settings that were not loaded correctly (was not using technical field names)
- Add data for PLS settings to check all optional fields and set the start date.
- use null value instead of empty for phone and email state fields to lessen the DB storage
- set pls start date required
Task ID: 2044539
PR #37413
This commit adds two buttons on the link.tracker tree view:
- Visit Page : Redirects the user to the visited page
- Statistics : Redirects to the page statistics
(with the '+' at the end of the shortened url)
In this commit we also add some padding to the graph of the page statistics
LINKS
closes odoo/odoo#37378
Taskid: 2075858
Pr: #37344
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds support for the parameter 'add_direction' on the '_format_time_ago' method
from tools.
This will allow formatting to '25 minutes' instead of '25 minutes ago'.
Preparation commit for the social 'feedback' task.
Task#2075858
PURPOSE
Sending SMS is sometimes required as an immediate marketing tool.
Using delayed crons is not always the best user choice. Implement a
Send Now mechanism in batch SMS.
Allow people to edit sms templates. Limit that rights to some main
application managers.
Provide some fiximps on sms dependent applications.
SPECIFICATIONS
Allow to send directly SMS when doing SMS marketing
SMS Application
* in sms composer, in mass mode: rename Send SMS to Put in queue and
add a Send Now button by-passing the queue;
* set Put in queue as primary, Send Now as secondary;
SMS Marketing Application
* in mailing view for SMS: rename Send SMS to Put in queue and
add a Send Now button by-passing the queue;
* set Put in queue as primary, Send Now as secondary;
Tests of SMS marketing with 400 contacts to SMS indicates it takes about
10 secondes to be completed with is considered as viable.
SMS Template access rights
GROUP-------------R-W-C-D-Note
Internal User-----X
Admin / Settings--X-X-X-X
Stock Manager-----X-X-X-stock.picking
Sales Manager-----X-X-X-crm.lead, res.partner
Event Manager-----X-X-X-event.registration
Sub Manager-------X-X-X-sale.subscription, res.partner
MarkAut Manager---X-X-X-no limit
Account Manager---X-X-X-res.partner (followup)
Other groups
* Online Appointment NO TEMPLATE USED
* Accounting Manager NO TEMPLATE USED
* SMS Marketing NO TEMPLATE USED
* Studio Automated Action Need Technical Settings Anyway
* Scheduled Actions Need Technical Settings Anyway
* Server Action Need Technical Settings Anyway
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR odoo/odoo#37298
PR odoo/enterprise#5750
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Failed SMS should stay in error state and not be sent to IAP as we already
know it will fail. No pain, no gain.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
PURPOSE
Allow people to edit sms templates. Limit that rights to some main
application managers.
SPECIFICATIONS
SMS Template access rights
GROUP-------------R-W-C-D-Note
Internal User-----X
Admin / Settings--X-X-X-X
Stock Manager-----X-X-X-stock.picking
Sales Manager-----X-X-X-crm.lead, res.partner
Event Manager-----X-X-X-event.registration
Sub Manager-------X-X-X-sale.subscription, res.partner
MarkAut Manager---X-X-X-no limit
Account Manager---X-X-X-res.partner (followup)
Other groups
* Online Appointment NO TEMPLATE USED
* Accounting Manager NO TEMPLATE USED
* SMS Marketing NO TEMPLATE USED
* Studio Automated Action Need Technical Settings Anyway
* Scheduled Actions Need Technical Settings Anyway
* Server Action Need Technical Settings Anyway
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
PURPOSE
Allow people to edit sms templates. Limit that rights to some main
application managers.
SPECIFICATIONS
SMS Template access rights
GROUP-------------R-W-C-D-Note
Internal User-----X
Admin / Settings--X-X-X-X
Stock Manager-----X-X-X-stock.picking
Sales Manager-----X-X-X-crm.lead, res.partner
Event Manager-----X-X-X-event.registration
Sub Manager-------X-X-X-sale.subscription, res.partner
MarkAut Manager---X-X-X-no limit
Account Manager---X-X-X-res.partner (followup)
Other groups
* Online Appointment NO TEMPLATE USED
* Accounting Manager NO TEMPLATE USED
* SMS Marketing NO TEMPLATE USED
* Studio Automated Action Need Technical Settings Anyway
* Scheduled Actions Need Technical Settings Anyway
* Server Action Need Technical Settings Anyway
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
PURPOSE
Allow people to edit sms templates. Limit that rights to some main
application managers.
SPECIFICATIONS
SMS Template access rights
GROUP-------------R-W-C-D-Note
Internal User-----X
Admin / Settings--X-X-X-X
Stock Manager-----X-X-X-stock.picking
Sales Manager-----X-X-X-crm.lead, res.partner
Event Manager-----X-X-X-event.registration
Sub Manager-------X-X-X-sale.subscription, res.partner
MarkAut Manager---X-X-X-no limit
Account Manager---X-X-X-res.partner (followup)
Other groups
* Online Appointment NO TEMPLATE USED
* Accounting Manager NO TEMPLATE USED
* SMS Marketing NO TEMPLATE USED
* Studio Automated Action Need Technical Settings Anyway
* Scheduled Actions Need Technical Settings Anyway
* Server Action Need Technical Settings Anyway
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
PURPOSE
Allow people to edit sms templates. Limit that rights to some main
application managers.
SPECIFICATIONS
SMS Template access rights
GROUP-------------R-W-C-D-Note
Internal User-----X
Admin / Settings--X-X-X-X
Stock Manager-----X-X-X-stock.picking
Sales Manager-----X-X-X-crm.lead, res.partner
Event Manager-----X-X-X-event.registration
Sub Manager-------X-X-X-sale.subscription, res.partner
MarkAut Manager---X-X-X-no limit
Account Manager---X-X-X-res.partner (followup)
Other groups
* Online Appointment NO TEMPLATE USED
* Accounting Manager NO TEMPLATE USED
* SMS Marketing NO TEMPLATE USED
* Studio Automated Action Need Technical Settings Anyway
* Scheduled Actions Need Technical Settings Anyway
* Server Action Need Technical Settings Anyway
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
Retry was not working for SMS marketing as it was actually not really
implemented. It now correctly unlinks failed sms and traces and reschedule
the mailing accordingly
It is also possible now to force send while being in queue mode to avoid
having to switch too much between states.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
PURPOSE
Sending SMS is sometimes required as an immediate marketing tool.
Using delayed crons is not always the best user choice. Implement a
Send Now mechanism in batch SMS.
SPECIFICATIONS
Allow to send directly SMS when doing SMS marketing
SMS Application
* in sms composer, in mass mode: rename Send SMS to Put in queue and
add a Send Now button by-passing the queue;
* set Put in queue as primary, Send Now as secondary;
SMS Marketing Application
* in mailing view for SMS: rename Send SMS to Put in queue and
add a Send Now button by-passing the queue;
* set Put in queue as primary, Send Now as secondary;
Tests of SMS marketing with 400 contacts to SMS indicates it takes about
10 seconds to be completed which is considered as ok.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
Sending void SMS marketing is not considered as a valid use case, more
something we should prevent as each sent SMS consumes credits. Required
is put in view as we have to support void sms body for mail mailings.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
There is no need to keep traces when unlinking mailings, being mail or sms.
Indeed even with marketing automation unlinking mailings means traces will
be lost and won't serve any statistics or reporting purpose anymore.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
Batch of 10 text messages was ok for testing. Production environment should
be able to handle more of them.
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
Purpose of this commit is to have recipients of an incoming email being
present only once in recipients / to. Indeed there is no need to have
duplicate entries, for example if Delivered-To is set with same content
of To.
Followup of 7b79045fab .
LINKS
Task 2076366 (send now)
Task 2067873 (template access)
PR #37298
PR odoo/enterprise#5750
Steps to reproduce:
1) Enter a vat number in a customer field (for exemple Sales Order)
2) Click on the suggestion
=> Traceback
Task-ID 2059940
closesodoo/odoo#37180
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
assertRaise do not rollback and continue with a broken cursor
which could cause problem during the remaining part of the test.
closesodoo/odoo#37421
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
1/ Write a form view with a o2m field that has its own inline tree view
(no other view exist in db for the target model)
2/ Open that view in a mobile environment
3/ Instead of having a list view, you get a kanban view. No luck for
you, since the default kanban generated by `models.py` is an empty one,
your records are *invisible* \o/
From what I can tell, the previous condition made no sense:
```
if (there is a list view and a kanban view) <-- this seems absurd
then (use the list mode)
elif (there is no list view but a kanban view)
then (use the kanban mode)
else (use both modes)
```
The first condition seems absurd: it *actively* ignores a kanban view
if there is one. Even better, the list view whose existence it checks
is never there: it checks for a `tree` when it should be checking for a
`list`. In short, the first condition was *never* met, and you ended up
either with exclusive kanban mode or with both modes - even if you had
no existing kanban view for the target model...
This commit moves the normalization of `tree` into `list` before
attempting to process the x2many field's subviews. It clarify the usage
of `tree` vs `list` (cf. only use `list`) which prevents weird edge
cases like described above.
closesodoo/odoo#36237
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>
Suppose uploading an attachment with res_id = 0, res_model = 'existing.model'.
Suppose also there a one2many having 'ir.attachment' as co_model and res_id as co_field
in 'existing.model'.
This setup leads to an error since the record with id=0 doesn't exists.
This commit ensures the res_model is not set when uploading the attachment.
closesodoo/odoo#37414
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
* base, web
Google now recommends a TTL of one year for static contents. We used to
use 1 week in almost every case. This commit increases that value to one
year for safe resources, like assets bundles which contain a specific
hash in the URL which changes if the bundle is recomputed anyway.
Note: this commit refactors the code so that both the one week and one
year durations are defined in http.py and used by others apps. Loading
the library "locale" file used to be done with 10-hours-cache, this has
been increased to 1-week-cache by using the http.py STATIC_CACHE var.
closesodoo/odoo#37402
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Implement group_expand for workcenter_id so that all workcenters are
visible in the planning by workcenter gantt.
Implement some constraint on write because anything can be moved in the
gantt view.
When changing the workcenter of a workorder, make sure the leave is now
set on the new workcenter.
closesodoo/odoo#37386
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Go to Accounting > Accounting > General ledger. The view is grouped
by account. There is a layout issue as the first column (date) is
positionned after the group names, leaving a large blank space.
This is because the date field is considered as an aggregated field
(for sorting purpose, in python), but the JS can't (and we don't
want to) display it. This rev. ensures that such field types are
completely ignored by the JS, s.t. they do not impact the layout.
closesodoo/odoo#37113
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
Setting 'overflow: hidden' on the (hidden) textarea used to compute
the (visible) textarea height ensures that there is no vertical
scrollbar, which would lead to a not so precise computation of the
height. The bug could be observed in sale.order form view, in the
order line x2many (description field), and had been introduced by
ef46378cd3.
Changed the information dipslayed by the confirmation modal in multi edition
in list views.
Before this commit, the modal simply showed a one-line message with the amount of valid records.
Now, there are 3 elements:
- If all of the fields cannot be changed, a first line warns the amount of valid records.
- A second (or first if all fields can be updated) line ensuring that the user is aware of
the occuring changes.
- A table displaying the affected field and the updated value (readonly widget with the new value).
Part of task 1967602
Since the commit allowing all list views to be editable, there are some
views in which we need to ensure that certain fields are always readonly.
Affected modules:
- account
- crm
- product
- purchase
- sale
Task 1967602
In an editable list, select a very long value in a many2one...
Before this commit, the table stretched as much as it needed to to
display all of the columns content.
Now, the largest columns are trimmed in order to keep the table
as wide as the list container (meaning it won't overflow anymore
unless there is a huge load of columns).
Also ensured that values trimmed by this feature are followed
by an ellipsis.
Task 2068261
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, resizing a column would cause the
list to develop a mind of its own and to grow/shrink random
columns according to its own will.
Now, resizing a column does not "freeze" the list anymore and simply
gives a static width to the resized column.
When the content of an autocomplete dropdown (e.g. many2one field)
was long, the dropdown could overflow the page. For instance, this
was the case of the intrastat_id many2one.
Task 2068261
Let's assume an editable list view with at least two rows. Before
this rev., the column widths were re-computed and frozen each time
a record was switched into 'edit' mode. As a consequence, if the
user clicked on a row, and then on another one, column widths might
slightly change.
Task 2068261
ClassNames 'oe_read_only' (resp. 'oe_edit_only') can be used in
x2many lists to hide columns in 'edit' (resp. 'readonly') modes.
However, before this rev., there were two issues:
1) Having such a className on a <button> tag didn't work well as
the 'display: none' rule didn't apply on the body cell (it only
applied on the button). Same could be observed on <widget>
nodes.
2) Having more than one invisible column (with those classNames)
didn't work either, because the footer cells weren't hidden.
We didn't notice it with one invisible column, because the
footer contained one cell less than the header and the body.
Those two issues could be observed on the mrp.bom form view.
Task 2068261
The tax lock date no longer blocks the user when creating a journal entry priors to it.
Instead, the accounting date is moved automatically during the validation to the next
available date.
This commit also brings more flexibility when dealing with the tax lock date. Indeed,
the error is now shown only when adding something impacting the tax report that was not
always the case before (e.g. adding a new line not affecting the tax report must not
raise something).
Others check has been also refactored to be more consistent with the "fully editable" mindset.
closesodoo/odoo#36304
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit deletes account_cancel module and squash it into account.
The 'update_posted' field is changed by 'restrict_mode_hash_table' field.
If 'restrict_mode_hash_table' is true, you have a hash chain on your account journal.
These hash chains prove the inalterability of your accounting.
l10n_fr_certification module is deleted and all hashing method are moved in account module.
Now, you can download a PDF report about your inalterability in the company settings.
If you have l10n_fr or l10n_post_cert installed you have more information on this report
like the inalterability of pos orders, etc.
Task ID: 2039160
On Mobile the byproduct One2many only empty line.
It's due to default kanban view using the _rec_name
in order to display the byproduct name. On byproduct the
_rec_name is not defined nor the field name so the kanban
is empty.
closesodoo/odoo#37403
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a BoM was composed of a phantom BoM, there was mutliple bugs:
- if not routing was set on the phantom BoM, the components were never
consumed
- if no operation was set on the BoM, its components were to be consumed
on the last workorder of the BoM and of the phantom BoM.
closesodoo/odoo#37304
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
PURPOSE:
Default analytic account should be used wherever possible. This wasn't
the case because the module didn't implement a default_get and only
filled the fields on product_id change, which isn't set by the OCR
task-2067097
opw-2068110
closesodoo/odoo#37389
X-original-commit: 2c450015154f8ba2384fb1f0ad1d4075785009c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
David Beguin