when modifying a persistent schema, erschema may miss some permissions which wil trigger a key error, but we don't want to crash on such cases

fix #694445: related entity generates weird RQL which in turn generates weird SQL which fails on SQL Server quick fix to reuse modification_date if already retreived by the rql query.

fix 4626:c26b4df9fc90 (#703911): use can't rely on peid since it's not an actual eid when we're creating the parent entity

[form fields] nicer behaviour of the password field: don't put internal field value on edition (triggering validation error if one validation without removing the value, due to confirmation mismatch), and don't show the field as required in such case

minor cleanup: don't use builtin 'id' as variable name

[forms/inline] fix #703911: add new link disappears if inline box removed. Since we've the information, we must specify the target type else we get random cardinality on ambiguous relations

this is not the form renderer responsability to check for update permissions. Move this to autoform editable_attributes relation

turn default logging threshold to warning (we usually want them), and log 'no schema for eid' pb using warning instead of error, so we see them in logs but not during migration

pfff, sorry to keep messing with default/stable...

specify db port on backup/restore commands (require forth comming lgc 0.48.1)

move captcha view to a place where it will be loaded by the registry...

backport stable

[security] allow to call .check on rql expression with a user eid specified

[facet] rqlst should be the select node

oops, should have been in my previous commit

fix table view facet retreival, necessary since 95ccd84c892b. Also some cleanup in facet box