Added tag cubicweb-version-3.18.6, cubicweb-debian-version-3.18.6-1, cubicweb-centos-version-3.18.6-1 for changeset d91501356742

[pkg] 3.18.6

[hooks/security] allow edition of attributes with permissive permissions If an attribute has more permissive security rules than the entity type itself, we should be green and not deny action because of an early global entity permission check (with the more restrictive rules). Only if one attribute with the entity-level permission rules is edited will the global check be performed. Note: * the "if action == 'delete'" check at the entry of check_entity_attributes is a guard for a condition currently not happening in cubicweb itself (but application hooks could conceivably call this function with a 'delete' action) Closes #3489895.

Almost backout afcd46716d6a which breaks _select_best raising an ambiguity exception in debug mode. The problem is, before afcd4, *tests* ran in debug mode and we want this (e.g. we want to show, rather than swallow, select ambigüities). We juste replace the bogus __init__(vreg.config) by __init__(True), which is practically equivalent and also much more clear.

[server] fix anonymous_user predicate in tests devtools' TestServerConfiguration overrides the anonymous_user method, but not the anonymous-user config option, so testing for the latter would give the wrong result. Closes #3996664.

[entities] cw_rest_attr_info() should only consider required attributes (closes #3766717) This prevents CW from choosing unique but non-required attributes. None/NULL is a poor choice for RESTful URIs.

[views] csvexport accept an empty rset (closes #4236928) When you tried to apply the 'csvexport' view on an empty rset, the view couldn't be selected and you got a HTTP 500 error. Also add two new test cases.

[views] Display attributes in entity creation form based on "add" permission Previously, the "update" permission was used. Hence in case the latter is more restrictive that the "add" permission, an user may not be able to set such an attribute, despite she may have "add" permission on it. As a result of the change of permissions action in `editable_attributes` method (add/update depending on whether the entity is being created or modified), the "eid" attribute would have shown up in the edition form. To avoid this, it is moved in the "hidden" section (where it should arguably belong anyways). Closes #4342844.