/reviewed-on nexedi/erp5!799

instead of building HTML in python, it's cleaner and prevent problems when attachments names are HTML entities.

erp5_base portal_actions/jump_related_object: Generic jump action should be lower priority than other dedicated jump actions.

because storing as document depends on erp5_ingestion & erp5_dms

So that conversion is done by a zope activity node and not on a front
node.

fixes from user feedback

/reviewed-on !800

Assorted fixes:

 * Fix performance problems on the dashboard graphs by optimizing 
 `SupportRequest_getSupportRequestStatisticsAsJson` 

 * Fix performance problems on RSS by applying a limit correctly
 
 * Fix rendering of RSS in some corner cases security configurations (with documents user cannot view)




/reviewed-on !795

Using a cache cookie that is incremented each time an account is added or modified,
we can keep an (almost) up to date list of accounts in the UI.

Fixes #20170221-1812E21

/reviewed-on !796

<h1>, <h2> ... currently have a style applied by gadget_nojqm.css that
does not make them look like header.

Apply a local override for now.

The vertial space between two <p> was not different from the vertical
space between two lines in a <p> making it hard to visualize the
boundaries of paragraphs.

/reviewed-on !798

On both the "create new support request" and "post new message on an
existing support request", enable the "Maximize" button so that users
can author their message in larger editor.

If we have a dialog with an editor field in bottom group, then dialog
action buttons does not fit on the screen.
Until rjs_gadget_erp5_nojqm.css allows using editor in bottom groups of
dialog, let's put them in center group, because editor in center group
have "normal" size and the action button fits.

This reverts commit 11b815bc.

This approach was not enough to solve on all dialogs the problem that
button is not always on the screen and it can still be confusing.

nexedi/erp5!800 (comment 69514)

- introduce a `form_dialog` class on dialog gadget, so that we can apply
different styles.
- add a rule overriding the rule making "big" editors in bottom group so
that in dialog mode they are not so big.
- force the maximize class to apply its height as !important, because
the added selector being more specific, it has priority over the one
from maximize.

http://lesscss.org/less-preview/ has been used to compile .less in .css

The default "don't style list item" rules from gadget_erp5_nojqm where
not good here, because user expects list items to be displayed in the
"standard" way (like in the CKeditor)

Listbox number of lines is not `limit` ... it's `list_lines`

Also add the missing test that should have discovered this earlier.

* Make it obvious that this script works with catalog brains and does
not want to call getObject
* Make two queries, one to get the "latest" support requests (by date)
and another one to get the "current" (by state), making one big query
will return too many results when the number of SR grow
* backend directly returns the data in the format expected by graph
library.

Before this change, `index_html` for Catalog Tool was None that means trying to
access view for CatalogTool from UI always make a function call to the
` __call__` which function was overridden with `searchResults`, which
means everytime someone tried to access `portal_catalog/`, a useless query was
being made and an undesirable query result was displyed on the UI.

In this case, `index_html` is prefered whenever we try to access portal_catalog
from UI.

Also, add test for proper display of view when CatalogTool is accessed from XHTML UI

/reviewed-on nexedi/erp5!793

This reverts commit 5b251ce6.

* Problems with data migration ( some events had no source, the logic of using current user was anyway wrong ) 
* Problems with security
* RSS too small

( see commits for details )

/reviewed-on !792

.pop .popitem and .setdefault where returning None

/reviewed-on nexedi/erp5!791

Security might be configured in a way that even if user can see the
support request he cannot see all events related to that support
request. We should handle this case by filtering out the event and not
letting Unauthorized error happen.

There was an issue that RSS was failing with Unauthorized errors when there was some events users cannot access.

(once again, thank you zope security, it was not leaking information just causing error)