PURPOSE
Improve user experience of report model build on mailing traces.
SPECIFICATIONS
Add scheduled count to reporting. Indeed we have number of sent and delivered
traces but it lacks count of scheduled. Some traces are not sent for example
when email or sms is missing or obviously wrong. Those are currently not
counted in reporting, this is fixed.
Views are also improved to add relevant metrics and measures. Notably add
a list view on report model, allowing to see some metrics at a glance. Improve
SMS related views, hiding opened / replied metrics as we do not track them
currently in SMS.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
PURPOSE
Improve user experience by correctly contextualizing trace display when coming
from a mailing.
SPECIFICATIONS
Display relevant fields, hide other one (sms number when coming from a mail
mailing, email when coming from an sms marketing). Set some technical fields
as optional (message ID, status update). Use badge for status. Allow to open
recipient document directly from list view.
Improve wording (mail -> email). Reorder form view to try to have less noise
by hiding void fields and replacing the status bar (not clickable and any not
a business flow) by a classic field.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Purpose of this commit is to keep blacklist and optout lists computation
at mailing level and correctly call it in composer. This allow to have
a clearer and more readable code as well as more robust.
Currently it is done by adding this information in context before invoking
the mail composer. It is now correctly done in composer: if a mailing is
linked to the composer, it calls both blacklist and optout lists methods.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
RATIONALE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Purpose is to prepare future changes by easing its grep. Notification is too
much heavily used through the codebase and finding it was quite hard among
other noise.
Rename ``notification`` field to ``is_notification``.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently most of mail related failure types are computed in mass mailing.
This is mainly due to historical reasons. We could move some of this
computation directly at mail level and store failure information directly
in mail.mail records.
SPECIFICATIONS
Overall purpose is to get near SMS implementation where base composer prepare
more advanced pre computation: blacklist, optout, seen list.
Detect and store failure types directly on mail.mail: blacklist, optout,
duplicates, missing email, wrong email, ...
State computation is moved from mass mailing to mail. It is also improved as
currently everything is based on "first recipient found". This is globally
valid for mass mailing who uses default recipients (customer). However when
dealing with generic mailing this is not true anymore.
We choose to store and update status on mail.mail records only when having
a single recipient. When several recipients are defined on a given mail.mail
we cannot really decide a status prior to sending it and skip this computation.
Mass mailing override now uses information from mail.mail to update its linked
traces as computation is now delegated to base composer model.
LINKS
Task ID-2377974
Community PR odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Prepare code cleaning and optimization in mail, mass_mailing and SMS by
cleaning models for readability and code complexity and footprint reduction.
SPECIFICATIONS
Be aligned with mail_mail and mass_mailing naming where failure_type is used
instead of error_code.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Clean mailing code and ease understanding by replacing some old selection
keys by new ones better highlighting their use and aligned with other keys
used notably in mass mailing or SMS.
SPECIFICATIONS
Use shorted and mail-related keys. Indeed we already have sms_ and sn_ for
sms and snailmail related failure type. We therefore update failure_type for
mail as
* "UNKNOWN" -> "unknown", a generic unknown of uncategorized error;
* "RECIPIENT" -> "mail_email_missing", indicates email address is
invalid;
* "SMTP" -> "mail_smtp", connection issue;
"BOUNCE" key is never used and removed. Actually we use a bounce state for
bounced emails / traces so this key has no use.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
PURPOSE
Be aligned with mail_mail model naming as well as convention used in SMS
application (sms_sms_id, sms_sms_int) and mass mailing application (using
mail_mail_id on mailing.trace model).
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Improve modeling and performances of mass mailing by manually updating trace
status instead of using complex computed fields and lessening fields usage.
Remove some fields and keep only relevant metrics to simplify and clean trace
model.
SPECIFICATIONS
In this commit we clean the way trace state is managed. Currently it is a
computed field based on several datetime fields. However this generates a
lot of noise in the table as well as unnecessary computation
* there are several columns (one for each state) storing datetime at
which status was reached. Generally only 2 or 3 contain relevant
information;
* state could be set in code directly to avoid a computed field based on
many triggers;
* recomputing it each time a date changes is not necessarily necessary;
* state value can always be updated manually as this is main done through
some automated server update (mailgateway, link clicks, ...);
As trace states and its triggers should not be updated manually it is better
to synchronize it in code flow. When there is an exception or update done
through sending or gateway status is updated as well accordingly. Various
datetime fields are also updated at the same time. In order to align with
notification model mail and sms trace status are updated to a classic field.
Only last status update is now kept as there is no need to store the entire
history of status change.
We keep only a datetime for relevant metrics: open, reply and click. Other
datetime bring no real value. Knowing when a trace was in error or bounced
is not necessary. Indeed exception generally indicates a server issue (at
sending), cancel indicates a data issue (at sending) and bounce depends on
customer email server.
Status update is removed as using write_date is sufficient. Once created
traces are updated only when an external event occurs (opened, replied, ...).
It allows to simplify trace model.
We also rename ignored field into canceled to match naming use through mail
and sms.
QUERY COUNTERS
This change has some positive update on query counters when sending mailings
as traces have less unnecessary status update compared to priori this change.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
RATIONALE
Currently there are differences between mail and sms error management
especially when sending them in batch (mass mode). Moreover cancel
(ignored) and error (exception) states meaning is not clear. Finally
some failure types management between mail and sms can be cleaned.
SPECIFICATIONS
Meaning of ignored / error we want to enforce now is
* error: there was something wrong at sending and user has an action to
perform, i.e. server failed -> check its logs;
* canceled: invalid recipients due to contact information or mailing
configuration (blacklist, opt out, void or invalid email or phone number).
In indicates issues linked to records themselves;
In this task we also add failure information granularity on mailing traces
linked to email like what is done currently on SMS. This can be related to
mailing (blacklist, optout, duplicates) or related to recipient (no recipient,
incorrectly formatted).
We also correctly distinguish optout from blacklist when sending SMS.
SPECIFIC USE CASES
* recipient without email / number: mail / sms is set as canceled, trace is
ignored;
* recipient with invalid email (no @) / number (formatting impossible):
mail / sms is set as canceled, trace is ignored;
-> we now distinguish when possible a void email from a wrong email using
a newly-added selection key (mail_email_missing);
* recipient with email / number blacklisted: mail / sms is canceled, trace
is ignored;
* recipient with email / number that optouted from mailing: mail / sms is
canceled, trace is ignored;
* recipient with email that bounces: mail is sent and will be set as bounce
when receiving bounce in gateway; trace follow same path;
* recipient with number that bounces: not supported as currently no support
of bounce through IAP;
* mail server error, IAP error: mail / sms is set as exception / error,
trace is set in exception;
This means we introduce new failure types on mailing.trace model to reflect
those failure types
* ``mail_missing``: missing email (different from wrong value);
* ``mail_bl``: blacklisted;
* ``mail_optout``: optouted;
* ``mail_dup``: duplicated email skipped during mass email send;
We introduce ``sms_optout`` on SMS and trace models as it was merged with
blacklist previously. Now both errors are distinguished.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Upgrade PR odoo/upgrade#1907
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
A python file is not imported anymore and contains dead code since its content
is now managed elsewhere. Oversight of odoo/odoo@ed508ee1bd (odoo/odoo#67322).
Task ID-2377974
Community PR odoo/odoo#61467
Purpose is to better understand the use of email_re regex (find emails in a
text) and email_split_tuples (find name and email in a string used in email
headers or as email_from / email_to / email_cc).
Task ID-2377974
Community PR odoo/odoo#61467
Since a few time, test_mail holds tests linked to specific test models.
Generic testing of mail features are located in mail. Followup of fix done
in 12 and forward ported until odoo/odoo@b7af68590e
Also rename test_mass_mailing_server.py unit test file to test_mailing_server
to match current naming of files.
Task ID-2377974
Community PR odoo/odoo#61467
Update query counters according to last runbot state. This helps spotting
query counters change linked to this PR.
Task ID-2377974
Community PR odoo/odoo#61467
This tool function is deprecated. As explained in docstring: "since OpenERP 6.1
please use ir.mail_server.send_email()". Seems we are allowed to finally remove
it.
Task ID-2377974
Community PR odoo/odoo#61467
Purpose of this commit improve kanban_state field layout in
kanban view of task.when user_id doesn't set on task it show
blank div for m2oAvatar which move kanban_state field to left
of that div.
So, In this commit show m2oAvatar only when use_id
is set on that task.
closesodoo/odoo#75258
Taskid: 2557892
X-original-commit: b22d0eaadd8875cc6c5286fe037c199160b65726
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the commit is to fix the translation buttons layout on
stages form view.
closesodoo/odoo#75257
Taskid: 2605763
X-original-commit: c52647b8828cc4904f44ba2d1919915aa8258f0a
Related: odoo/enterprise#20323
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
On the purchase dashboard(s) the context would never be passed on the
rpc calls that load the upper panel, which caused the result to always
be as seen from the default company.
Closesodoo/odoo#74882
Task ID: 2610547
Related: odoo/enterprise#20145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of this commit is to display the value of
timesheet_min_duration and timesheet_rounding fields
center in the setting of the timesheet app.
So, In this commit add a text-center class for that fields in
XML of the setting in the timesheet app.
closesodoo/odoo#74849
Taskid: 2616165
Related: odoo/enterprise#20135
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously if one of the text in the project's kanban view's setting
pane was too long, the setting pane would overflow and display a
horizontal scrollbar in order to fit everything.
Closes: odoo/odoo#74822
Task ID: 2618321
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Previously the settings pane toggle (on the project's kanban view) would
disappear when the cursor would not be hovering the kanban record.
Closes: odoo/odoo#74822
Task ID: 2618321
Tasks that are blocked by other tasks don't get any other information
from those tasks.
In order to get updates on the state of the blocking tasks we now track
some fields (determined by the `task_dependency_tracking` attribute) in
the parent's chatter.
Task ID: 2601448
closesodoo/odoo#73965
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps:
1. Create new time off allocation
2. Set type to accrual and set start date other than present day
3. Set the accrual to add every month
4. Validate and run the scheduled action for Accrual Time Off
5. Check the field 'nextcall' with Studio or editing form view
Result:
Nextcall date is set to 1 month after the date of creation of allocation record instead of start date.
Solution:
Nextcall is now based on start date.
opw-2558480
closesodoo/odoo#75234
X-original-commit: 3f7f0feb31d80c5cb3364c3a7d530c80b6278b40
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: Audric Onockx <auon-odoo@users.noreply.github.com>
*: hr_holidays, im_livechat, sms, snailmail, website_slides
Most messaging related components have common needs concerning
subscribing to model changes, and not needing to be rerendered unless
their props change. Previously, most components would call the hooks
"useModels" and "useShouldUpdateBasedOnProps" individually. Messaging
components also depend on one another quite a bit, requiring a lot of
explicit imports of other components. It would also be useful to be able
to have cyclic dependencies between component (eg Message renders a
component that allows to delete the message, and the delete component
renders the message in a confirmation dialog), but that doesn't work
with explicit imports (the odoo module system doesn't support cyclic
dependencies).
This commit adds a Component decorator that:
- Registers the component in an internal registry
- Makes all components in this registry available at render time to
components that have been registered in this way
- Calls the useModels and useShouldUpdateBasedOnProps hooks during
component initialization (setup)
enterprise PR: odoo/enterprise#20304closesodoo/odoo#74982
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
We need quantity in tax line and we added from this PR https://github.com/odoo/odoo/pull/73402
but after it creates a problem in tax amount
because in tax line, the unit price is set base on quantity and by default is 1 but after PR 73402 it's the same as invoice line so rounding issue is there and this rounded amount is multiplay by quantity so this creates a big difference
before PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 1 | 8000 | 2220 |
```
After PR 73402:
Name | unit price | quantity | taxable amount |
=====================================================
Product A | 5.55 | 8000 | 44400 | (invoice line)
Tax 5.0% | 0.27 | 8000 | 2160 |
So in this PR we remove quantity from grouping key
closesodoo/odoo#74818
X-original-commit: aa160f4c0a04500bd91eea8da2cec165a15270a6
Signed-off-by: Josse Colpaert <jco@openerp.com>
Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter
Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.
Solution:
Add multi-company rules for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access
A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70
opw-2535709
closesodoo/odoo#75220
X-original-commit: a6f951845d5de869b2e138403aecfd4c653bf8b3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Steps to reproduce the bug:
Go to your computer's date settings
Change region, e.g: (US or choose a region with a negative UTC)
Go to the preferences settings in odoo > Change the timezone to US too
Go to Time Off app > Manager > Allocations > Create a new one
Allocation type : "Accrual Allocation"
Set the end date to, e.g: "04/07/2021"
save
Problem:
The end date moves back by one day.
The field " date_to " is of ”datetime” type, so we use in the view "widget="date"
Therefore, the user can only choose the date. We save the time in the database at" 00: 00:00 ".
But as we use in the view "widget="date", after saving the record,
the datetime will be converted to a date, based on the user's UTC.
For example, in our case:
in database, date_to = "2021-07-04 00:00:00"
user UTC = "UTC-6"
result = "2021-07-04 00:00:00" - 06:00:00 → "2021-07-03 00:18:00"
Solution:
Remove the widget date to allow a user entering the full date (eg: 2021-07-04 23:00:00), that
will be stored correctly in UTC afterwards, instead of having the widget making the date switch to
another day.
opw-2607082
closesodoo/odoo#75218
X-original-commit: 2ddabf087004e14ac77aa397eb345d750026dd20
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
PURPOSE
Fix issues generated due to conversion of text field into Html field.
SPECIFICATIONS
Improve integration of HTML fields as well as "empty html" management.
See various commits for more details.
Followup of odoo/odoo@cb4f597 and odoo/enterprise@971f3ed
Task-2558824
closesodoo/odoo#74795
Related: odoo/enterprise#20117
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before commit[1] there was only one field image_1920 in group with 'colspan=1'.
In commit[1] a new invisible field avatar_128 is added in this group. But due
to this an empty 'tr' element is added in view and it breaks the view.
With this commit we move avatar_128 field outside of the group and placed it
with other invisible fields, so it doesn't break view. And also adding comment
field in new group because it is html field now so it displays nicely.
Followup of odoo/odoo@cb4f597410 and odoo/enterprise@971f3ed9ae
commit[1]: c53724ebc3
LINKS
Task Id-2558824
PR odoo/odoo#74795
PR odoo/enterprise#2011
Followup of odoo/odoo@cb4f597410 and odoo/enterprise@971f3ed9ae
We have converted string into markup string in repair as we cannot concatenate
strings directly to Markup string. And if we try to do it we will see the
html elements '<br/>' in field value, so we have to convert '<br/>' string
into markup language to avoid this.
Also avoid adding pseudo-void html content in narration.
LINKS
Task Id-2558824
PR odoo/odoo#74795
PR odoo/enterprise#20117
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In 14.0, when adding a form to a website and selecting "Create a Task" without
an active project, an error pops up because no projects are found.
In this commit, we prevent an error from popping up when adding the form
without projects, by allowing the field to be empty (not required).
task-2580436
closesodoo/odoo#75221
X-original-commit: a5d8648531f9a0e9616f23b66c67ff32fdb0f0ea
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When clicking on the 'New quotation' action,
if no current customer is linked to the lead,
a popup opens with the following options:
- Create a new customer
- Link to an existing customer
- Do not link to a customer
If odoo found a potential matching customer but we decide it is the
wrong one and select the first option, a new one should always be
created
opw-2545065
Task-2622793
closesodoo/odoo#75213
X-original-commit: 728f8611caa8fe3f3bdc88a9650f7edb05321a87
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: When closing a PoS session, the user can Cash In/Out of the
register but it requires Accounting/Billing group or Purchase/User
group. However with Purchase/User group, there was an access right
error (not allowed to create account.move.line
Steps to reproduce :
1) Install PoS Module
2) PoS > Your Shop > Settings and enable Advanced Cash Control
3) As administrator and in debug mode go to
Settings > Users & Companies > Users
4) Remove Accounting, Inventory and Purchase group of [User A]
5) Log in with [User A], open a PoS Session, close it, and in Cash
Control form, click Cash In/Out
6) Remove or add money
-> Access right error, you need to be Accounting/Billing or
Purchase/User
7) As administrator, add the User group to Purchase for [User A]
8) As [User A], click Cash In/Out, removed or add money
-> Still access right error
Why is that a bug:
The first warning asks us to give the Purchase/User group to the user
if we want to Cash In/Out but even when doing that, the access rights
are still not enough to allow the creation of the entry
opw-2611298
closesodoo/odoo#75156
X-original-commit: a28c9c1dd773f26151d6734d476e7f8d5a3d971b
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
*: web
After this commit pre-configured gradients can be used as snippet
backgrounds, snippet filters or as text effects / highlight effects.
The background colors (and now gradients) are now possible to add
*alongside* a color combination class (editing one does not remove the
other). Background colors and gradients are mutually exclusive.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
closesodoo/odoo#73611
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
All background-color classes (bg-XXX) were defined before the color
combination classes. Except for the Odoo colors ones (bg-o-color-X)
which were defined after. That inconsistency was not a real problem
before as those two type of classes could not be combined but this will
change in the future.
Part of https://github.com/odoo/odoo/pull/73611
task-2599770
Currently, track proposals are submitted through an HTML form with an "action"
attribute, which requires that the associated route returns a redirect
response.
However, redirecting to a different page comes with its set of issues.
Indeed, when the track is submitted, the user that just submitted the track no
longer has access to it (because it's not published).
In 157a1d77058da97954edc9efba6ab9f43c7d13a2
We attempted to resolve this issue by checking if the partner set on the track
is the same as the partner set on the website.visitor record.
However, this does not handle every use cases since when specifying different
contact information, we create a different res.partner, making the check fail.
In this commit, we rework the track proposal submission to use AJAX instead.
This allows to dynamically show a "success" message while staying on the same
page, removing the need for redirects and "complex" ACLs checks.
While the main goal of this change is to avoid the need for that security
check, it also has a few additional minor advantages:
- Slightly faster UI, as you don't have to wait for a full page reload
- Fewer routes to maintain
- Easier and more thorough validation handling (current code returns a ugly
error page if validation fails server-side)
- Code makes a bit more sense, as we don't have a template that varies from
"form" to "success message" depending on the presence of a "track" variable
Task-2618734
UPG PR odoo/upgrade#2722closesodoo/odoo#74848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does not change anything, it simply applies linting on the track
proposal JS files to match our current guidelines.
This is done as preliminary work since we are going to change the way track
proposals are submitted (from POST request to ajax POST).
Task-2618734
Thibault Delavallée