[security] don't add attribute into skip_security if already in edited_attributes, else we may accidentaly skip a desired security check

[repo entity] we have to provide a __delitem__ implementation as well, see example in the docstring

[yams] on creation, specify relations anyway so we don't get spurious warning for accessing eid through the dict api on yams validation

[repo] fix warning message and implementation of bw compat unsafe_execute

stable is now 3.7

oldstable is now 3.6

backport stable

merge

Added tag cubicweb-debian-version-3.6.3-1 for changeset f9fce56d6a0c

Added tag cubicweb-version-3.6.3 for changeset 9c342fa4f1b7

Added tag cubicweb-debian-version-3.7.1-1 for changeset 9194740f070e

Added tag cubicweb-version-3.7.1 for changeset 6b0832bbd1da

backport debian control changes done in 3.7

3.6.3

ticket #636927, add ajaxhtmlhead in controller js_component

[widget] allow kwargs passed to Select widget

take care to empty breadcrumbs

fix bug with damned transmutation functionality, occuring when using an INSERT query which also add relation to the entity

update skeleton for __pkginfo__.py

don't use optional on final relation

fix security issue introduced by 4967:04543ed0bbdc: attributes explicitly set by hooks should not be checked by security hooks

[form js] apply vgodard patch fixing #750056: reorderTabindex js function crashes when form dom id is not 'entityForm'

missing unittest_main

[server] add unit tests for storages

[registry] trigger reload events on set_schema()

[source] only consider edited_attributes in source.preprocess_entity()

[source] implement storages right in the source rather than in hooks The problem is that Storage objects will most probably change entity's dictionary so that values are correctly set before the source's corresponding method (e.g. entity_added()) is called. For instance, the BFSFileStorage will change the original binary data and replace it with the destination file path in order to store the file path in the database. This change must be local to the source in order not to impact other hooks or attribute access during the transaction, the whole idea being that the same application code should work exactly the same whether or not a BFSStorage is used or not.

i18n update