The main motivation is to allow to use Internal Invoice Transaction as
causality of Internal Invoice Transaction, so that when they are posted
the automatic grouping takes place.

A side effect is that now users can also create transaction as causality
of Balance Transaction, not really expected, but not really a problem.

Internal Invoice Transactions are used for any kind of internal
transaction (invoice, payment etc). To make it easier to input
payment, we allow selecting the bank account directly from the view of
the transaction, this way users do not have to enter the line and set on
each line.

- edit method adds an extra entry in the edit history. We already have one
entry for newContent
- edit silently creates local properties in case of typos, so it's
  generally better not to use it when the property names are known

This API takes care of building query string and redirecting to the same
form_id, this is a cleanup.

Rework Balance Sheet and Profit and Loss so that they are more consistent with other reports:
 - Ability to choose output format and produce in deferred mode
 - Allow specifying the date range explicitly, for current period and previous period as well. When dates are not specified, the previous behavior of guessing start date and previous date range from accounting periods is kept
 - Style fixes
 - Set a filename for *Save as ...*

Introduce a new feature on Profit and Loss to allow to have instead of the two column layout (used in France mostly):

| INCOME  | EXPENSE |
|---------|---------|
| **1. Revenue** | **1. Operating Expenses** | 
|     - ...... | - ...... | 
|    | - *Cost of Sales* | 
|     | - *Selling, General and Administrative Expenses* | 
|     | - *Other* | 
| **2. Non Operating Income** | **2. Non Operating Expense** | 
|     - ...... | - ...... | 
| **3. Interest Income** | **3. Interest Expense** |
|     - ...... | - ...... | 

Have a one column layout with intermediate profit/loss calculated for each level ( what I call "british layout" here):

| Profit and Loss  |
|---------|
| **1. Operating** |
|  * *Sales* | 
|  * *Operating Expenses* | 
|        - ...... |
|        - Cost of Sales | 
|        - Selling, General and Administrative Expenses | 
|        - Other | 
| **2. Non Operating** |
|  * *Non Operating Income* | 
|        - ...... | 
|  * *Non Operating Expense* |
|        - ...... | 
| 3. **Financial** |
|  * *Interest  Income* |
|        - ...... | 
|  * *Interest Expense* |
|        - ...... | 

This is achieved by putting all that hierarchy in `portal_categories/financial_section/income` and not splitting it in `income` and `expense`. This report will not display `expense` category if it is empty.

Still TODO:
* [x] updating https://www.erp5.com/erp5-HowTo.Select.Accounting.Financial.Section

/reviewed-on nexedi/erp5!284

Making "modified_object_list" consistent by always containing tuples and not
sometimes lists and sometimes tuples.

Also, update the files where they have been used

Using _getOb is always less costly than getattr, as it reduces the need to look in acquisition.

And simplify manage_exportProperties function accordingly

Also, we don't need to look for `transactionless` connection-id here,
as we don't use them in catalog methods.
And, update the files where we can use the new function.

Methods used in PaymentTransactionGroup_view

Always returned Accounting Transaction Lines
(there is no Payment Transaction Line portal type) that were sub-objects of
Payment Transactions. But now they can be also sub-objects of
Accounting Transactions.

So used '...AccountingTransactionLine...' instead of
'...PaymentTransactionLine...'

Previously, this could only be node_uid.
In future we should find a more generic approach to make this configurable.

Also, add two tests to testInventoryAPI to check queries with selection_domain
for getInventoryList and getMovementHistoryList.

/reviewed-on nexedi/erp5!426

- Reindex the support request before add it as HTML Post follow up.
- Use custome message when no post content provided.
This should fix the 502 Proxy error and 400 error when creating a
 new Support Request with/without description.

Use a custom ERP5 script instead global worklist searching.

ckeditor 4.5.3 cannot work properly on Android and iPhone. Before update it to latest
version. We need to check the compatibility issue of other officejs. For now, just use
textarea instead buggy ckeditor.

And update the test for textarea.

Solved issues:
- Restore button didn't work after change listbox.changeState to listbox.render.
- Restore button should restore the listbox to page zero.
- Restore button should be enabled when to refresh the page with expected parameters.

Some listboxes in ERP5 use "| desc" to sort elements, even if it
didn't work (ie: Base_viewEventList/listbox).
Also, as "asc" is working (because descending sort is defined by
whitelist), adding "desc" makes things more consistent

/reviewed-on nexedi/erp5!419

-  close opened tags
-  replace TH with TD for data cells
-  prefix invalid attributes "line" and "column" with "data-"

When a user triggers `NotificationTool.sendMessage(recipient=user_id)` to a recipient she does not have access permission on, it now causes this problem (the caller context is a custom script with manager proxy role):

```
  Module Products.ERP5.Tool.NotificationTool, line 322, in sendMessage
    person_value = getUserValueByUserId(person)
  Module Products.ERP5.Tool.NotificationTool, line 291, in getUserValueByUserId
    return portal.restrictedTraverse(user['path'])
  Module OFS.Traversable, line 317, in restrictedTraverse
    return self.unrestrictedTraverse(path, default, restricted=True)
  Module OFS.Traversable, line 251, in unrestrictedTraverse
   - __traceback_info__: (['redacted_person_id'], 'person_module')
    next = guarded_getattr(obj, name)
Unauthorized: You are not allowed to access 'person_module' in this context
```

This is a regression caused by 62d8d3ac .

That particular case was working before, because the person was looked up using [catalog]( https://lab.nexedi.com/nexedi/erp5/blob/882f0022c7af4f36c2f31643498ac0b5d82c2217/product/ERP5/Tool/NotificationTool.py#L321-322) so the proxy role from the caller script was taken in to account.

Now, we can say that the approach suggested here is not correct and document that the current logged in user must have permission to access the person documents involved as sender or recipient in the notification.

Then, if we need to send message to persons the current user does not have access permission, instead  of using:
```python
portal.portal_notifications.sendMessage(recipient=person.getUserId())
```

just do:
```python
portal.portal_notifications.sendMessage(recipient=person)
```

but the later does not allow for using activities.

/cc @vpelletier @gabriel 


/reviewed-on nexedi/erp5!395