When displaying support request date.

These fields inheriting my_ticket_start/stop_date, but because support
request usually are short-lived ticket (compared for example with a
campaign that can span over several months), we also show hour:minutes

Also use these fields everywhere we are displaying support request dates
in CRM

( note that the message appearing in the diff was not used, as property
was delegated )

 * Preferences use same icons as other OfficeJS apps
 * Support Request use an "help"/"support" icon

This step just checks that multi relation field listbox shows a list of
related document and that clicking on any item of the list leads to the
related document.
The order of related documents in the list has always been unspecified,
but the first one was always 1 until recently.
Because this test does not really care which one of the two related
document was clicked, just assert that it's a document from foo_module.

/reviewed-on nexedi/erp5!774

89115b88 is great, but with "testFunctionalAnonymousSelection" the
result HTML is more than 40Mo.

/reviewed-on nexedi/erp5!772

This will insure that the URL created for diff by `Base_redirect` will have the paramters
`your_first_path` and `your_second_path` in it, thus making it unique and hence
sharable. Before, we only used to have the name of selection in the URL which
returned different result for different users.

also use '>' instead of image

Assorted fixes and new features for support request app:

Features
 * post are now HTML and use the preferred editor ( CKEditor by default )
 * posts are ingested in Web Message and the app uses same data model as erp5_crm ( so it is able to display support request created with "standard" ERP5 interfaces)
 * date of post uses momentjs relative time (New message by Bob 1 hour ago...)

Bug fixes:
 * post API no longer use proxy roles / immediate reindex
 * RSS was re-implemented to list events. The previous approach of listing support requests had an issue that the date of new posts was still the date of the original support request.
 * attached files to the "submit new support request" dialog where not uploaded
 * using a handlebars template we prevent html injection / XSS 
 * increased test coverage

/reviewed-on nexedi/erp5!769

This was inefficient for two reasons:
- any message we could validate during current iteration means a message we
  did not consider is now in the range we just scanned. And it will not be
  considered until validation node starts over and scan this same range
  again.
- "LIMIT x,1000" pattern on >1000 messages causes a quick-growing number of
  extra rows scanned by the SQL database just to skip the "x" first rows:
  at 2000 rows present it must scan 1000 + 2000 = 3000 rows for a complete
  loop over all pending activities. At 3k rows it must scan 6k rows.
  At 4k, 10k.
  While this is an overestimation (some rows should be possible to
  validate, so these would be scanned once only), this overhead grows so
  large that this overestimation can become negligible.

Instead, use a range condition consistent with query's "SORT ON", which is
already efficiently materialised by an index: SQL database just has to
dive into the existing index to start just above the last message from
previous iteration, and resume scanning from there, solving both issues
listed above.

This method is called on every __getattr__ (guarded_getattr, actually) of
every restricted python scripts. Which means each "." in the code triggers:
- traversal to relevant acl_user folder
- a user lookup
just to get the same value throughout the execution of a script (as its
owner does not change during execution).
Also, in practice we have extremely few possible owners: very few users are
allowed to edit code in an ERP5 instance, and if such instance is managed
using the upgrader alarms, they will even further reduce this owner set to
System Processes only.
On a real-world web page rendering, this reduces the total number of
traversal calls from 1500 to 1100, getting rid of the two hottest spots:
/acl_users and /$site_id/acl_users .

Publishing was too open, sharing is a better state.

Setting the document as followup of the ticket and the support request
project and the support request organisation seems a good default to set
security so that project members or users working on the ticket can see
documents.

Also ingest document in two steps:

* first step is to create the document and activate DMS metadata discovery
* second step is to share the document, once the necessary roles have been
  given to the user

What's still not good with this approach is that DMS ingestion might
merge this new document with an already existing document. This case
is not supported and needs an extension to ingestion API

This prevents html injection for Mr. <script>

Some users might be able to post messages without being able to modify
the support request

This is better than getting it in another HTTP request.

no need to to request server for this

 * format code as jslint expects it
 * use RSVP.Queue instead of Promise

When this is called in the test suite, the current user is already
logged in as manager.

But category group should be used to support all arrow categories.

So that we can see if a post was ingested or not.

This is more understandable

and add a few assertion on the posted messages content

using momentjs that's already bundled in jiodev.js

/reviewed-on nexedi/erp5!755

/reviewed-on nexedi/erp5!720

* Instead of Person.reference, Person.user_id is now used to log in (fe27a9c3).
* Fields text were renamed to follow naming conventions (329c196d).

/reviewed-on nexedi/erp5!770

https://www.erp5.com/documentation/developer/guideline/module/erp5-Guideline.Module.Creation#set-form-encytype-to-multipart/form-data-when-using-file-upload

as a result, attaching files when submitting support request was not working