First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
Purpose
=======
A 'Access Rights' (group_erp_manager) user can create a company
A 'Settings' (group_system) user can create a resource.calendar
With the resource module, if a resource.calendar is not set on the new company values, a default one is create.
As the 'Access Rights' user can create a company, but can't create a resource calendar, this should be done with sudo.
Specification
=============
When user is creating a new company (in a multicompany environment), by default, he should have access to this company.
Also, do not allow to create new company from allowed companies dropdown
Purpose
=======
Right now user not able to archive maintenance equipments and maintenance teams which are no longer in use.
Specification
=============
Add archive button in form view of Equipments and teams. Also add filter on list view.
Don't put a specific team by default on equipment, select the first unarchived one instead.
* portal
When there are too many items in the top menu, the menu is broken into
multiple lines (especially on medium screen resolution). This commit
implements a system like in the enterprise backend: the extra items are
placed in a "+" dropdown menu at the end of the top menu.
Also, review the direction used to open dropdown menus. The default is
now left-to-right (while it was right-to-left before) and JS has been
added to determine the safe direction:
- If last item: to the left instead
- If would overflow the window: to the other direction instead
Now the colorpicker option can be defined with a `data-color-prefix`
parameter which will allow toggling classes different than "bg-*".
(e.g. if the prefix is set to be "hello-", the colorpicker option will
allow to choose between "hello-primary", "hello-danger", ...).
Before this commit, when defining two sets of classes to be chosen
independently on a same element you had to define two options:
```
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 1</a>
<ul class="dropdown-menu">
<li data-select-class="a"><a href="#">A</a></li>
<li data-select-class="b"><a href="#">B</a></li>
<li data-select-class="c"><a href="#">C</a></li>
</ul>
</li>
</div>
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 2</a>
<ul class="dropdown-menu">
<li data-select-class="x"><a href="#">X</a></li>
<li data-select-class="y"><a href="#">Y</a></li>
<li data-select-class="z"><a href="#">Z</a></li>
</ul>
</li>
</div>
```
Now, an unique option can be used for this, allowing to not duplicate
the `data-selector` and not creating two JS options:
```
<div data-selector=".myElement">
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 1</a>
<ul class="dropdown-menu">
<li data-select-class="a"><a href="#">A</a></li>
<li data-select-class="b"><a href="#">B</a></li>
<li data-select-class="c"><a href="#">C</a></li>
</ul>
</li>
<li class="dropdown-submenu">
<a tabindex="-1" href="#">Classes set 2</a>
<ul class="dropdown-menu">
<li data-select-class="x"><a href="#">X</a></li>
<li data-select-class="y"><a href="#">Y</a></li>
<li data-select-class="z"><a href="#">Z</a></li>
</ul>
</li>
</div>
```
Before this commit, defining a snippet option began by choosing an XML
`data-selector` attribute to put on the option's <div/>. This selector
would then be used to find DOM elements on which to attach the option.
A recent refactoring added the `data-exclude` attribute, allowing to
define a selector that a DOM element must not match to receive the
option.
A new kind of need has arrived: allowing an option to be attached on a
DOMElement but making the option's effects be applied on a specific
child of this DOMElement. This can allow to regroup children options on
a main DOMElement.
To that effect, this commit introduces the optional `data-target`
attribute. If defined, its value is used as a selector to find the
option's `$target` inside the element found with previous rules. Note
that the system has been made smart enough to only add the option on
elements which indeed contain such a $target.
E.g. I want an option to appear in the customize menu of my custom
snippet's <section/> but will in fact control the toggling of a class
'super-row' on the `.row` (I don't want the option to be on the `.row`
otherwise it would not be in the main customize menu). All I have to
do is defining a
```
<div data-selector="section" data-target="> .container > .row">
<li data-toggle-class="super-row"><a href="#">Super Row</a></li>
</div>
```
(no JS required)
Note: a similar behavior was already present on the JS side of the
"colorpicker" option.
When reinitializing modules it is impossible to create partners if
stock is installed because picking_warn field has a required column
but no default value if the module does not depend from stock. Use
case is trying to run test_mail tests with stock installed.
As this field is not business critical it is now not required. As there
is a default value behavior should not change for users.
When reinitializing modules it is impossible to create partners if
account is installed because invoice_warn field has a required column
but no default value if the module does not depend from account. Use
case is trying to run test_mail tests with account installed.
As this field is not business critical it is now not required. As there
is a default value behavior should not change for users.
When an invoice is paid, the button "Cancel" was not visible. For a better guidance, we now show that button.
Indeed, after having unreconcilied the invoice and the payment, the user should be able to cancel the invoice.
It also now allows to cancel wrongly encoded invoices with 0 as total (they were directly marked as paid, preventing
their cancellation)
Was PR #20470. Was task: https://www.odoo.com/web#id=34307&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
To consume a tip, the elements matching the selectors `trigger` and
`extra_trigger` must exist in the dom.
However, the presence of blockUI should prevent the tip to be consumed
in the tour because the user can't physically execute the corresponding action.
As on enterprise module install order can be different from community
query count for some mail-related tests are different. This commit
updates some counters to avoid breaking enterprise runbot and give
time to find the source of added queries.
Purpose
=======
In a business point of view, it make no sense to merge record. if someone want really to merge record they have to do this manually to think about all corner case. What about id sent to the customer ? what about timesheet ? what about business ?
The idea of the task: remove this feature in both app, project.task and in helpdesk
Specification
=============
Remove both features
"Merge Selected Tickets" in helpdesk
"Merge Selected Tasks" in project.task
Since test cases of sale depends on account common
class test, they are executed post_install.
For some futur dev, we will need to launch them
at install (since stock module change the behavior
of consumable product for delivered quantity computation).
This commit:
- avoid test to use demo data
- reuse common helpers to generate testing
data
- make test suite share common test classes
Accounting tests are executed post install to be sure a chart
of account is install. However, for some case, we might want
to run test at module installation, involving accounting, without
being sure a chart of account is installed.
This commit provides a base common test class with a minimal chart
of account (some journals and accounts) allowing to start tests at
installation. this class should be extended in sale or expense for
this modules to be tests at installation. We will required this for
reinvoice test in sale later (test consumable product when sale_stock
is not installed, but maybe without a chart of account). The idea is
each test suite can call method to setup their own data.
This commit also use this common test class in sale_expense.
Accounting tests are done 'post install' because
their generally requried a chart of account to be
installed before test execution.
If a test is launched before l10n install, the test
will be skipped but nobody will know it, unless you
read all the logs of your server.
When skipping a test, a warning should be displayed.
The rte_inline tour was failing on chrome because jquery selector in
chrome does not like a space in the style selector.
On the other hand, other browsers and phantomjs need the space.
This commit change the selector to find the element on chrome and
friends.
When running the portal tour, the test succeed too early because it finds
the words "Your Details" on the wrong page (/my instead of /my/account).
The selector has a match on previous page, so tour succeeded when it 's
not complete.
This commit use another selector that only match on the '/my/account'
page.
When using the fast_counterpart creation method to automatically
reconcile bank statement lines, there was no verification that the
account id was not set or that the statement was already linked to journal
entries. It was causing a traceback in some conditions when the
demo data were loaded because the fast_counterpart_creation was called
without the verification, using an XML function.
This commmit introduce the necessary verifcation.
Thanks @qdp-odoo for the review and some docstrings/comments
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that... for the employee login.
Thanks to the murphy's law, the test branch was green.
When searching the id mail.mail_activity_data_todo a request is done and
should be taken into account by the assertQueryCount.
This commit does just that.
New tests are added in test_mail to have tests for message_post and
complex mail thread features. Purpose is to have performance counters
for more complex stuff in mail and begin to work on performances
and try to lessen those counters.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The 'on_reverse_breadcrumbs' option of do_action() allows to
define an handler to execute when coming back to the previous
action by clicking on the breadcrumbs.
This option was set when executing the Import client action, to
ensure that the previous view was reloaded when the client action
was left. However, the view to restore is always reloaded, so
specifying the option in this case produces a double reload.
Before this commit:
To know if an event menu is an auto generated one (eg: location, register..),
it checks if the menu name is the same as the hardcoded one in
_get_standard_menu_entries_names.
If user change the menu name, the code won't retrieve it and will act as if the
menu had been deleted and it will recreate it.
This leads to 2 bugs:
*First (website_event)
- Change menu name from website_event (eg: location, introduction or register)
- Check/Uncheck 'Track on website' or 'Track Proposals on website' to force
the code to rewrite missing menus.
- Go back to the event front end, theses menus have now been recreated, and
are duplicated.
*Second (website_event_track)
- Check 'Track on website' on event's back end
- Change the 'Talks' menu name in front end
- Go back to backend, 'Track on website' is unchecked because
_compute_website_track won't retrieve an event menu named exactly 'Talks'
Now:
We don't use euristics to try to recover missing menus.
We just create related menu when option is checked, and we delete them when
option is unchecked.
To know which menu item comes from which option, we store a value in a new
model 'website.event.menu'.
We don't want to try to check if the menus are all there and recreate them if
needed anymore. There is cases where user wan't to delete a menu and repace
it with a link to that menu's URL in the page content.
Before this commit, the option would've been unchecked since it won't
retrieve the menu.
This technical dependency module adds settings to res_company for the
company's social media pages.
It is introduced to fix duplicated fields for res_company in website and
mass_mailing, these two modules now require social_media as a dependency
Add the context manager method `assertQueryCount` to count queries,
the decorator `@users(...)` to execute a test for several users, and
the decorator `@warmup` to execute a test twice (warm-up, then real).
Creating data directly in tests was done when tests were located in mail
module to avoid creating real data or demo. Now that mail tests have their
own module we can create demo data and use them in tests. It is simpler to
have demo data for things like subtype and email templates to ease
understanding and reuse.
Richard Mathot