merge

[workflow] fix potential destination for go back transition

[workflow] finish refactoring introduced by 021035b9a7ab for 'go back' transition: * fix SubWorkflowTransition.destination() prototype (must now take an entity as argument) * fix the change state for to give the entity to the transition's destination() method * we need a new method to draw workflow since we've no entity to give and 'go back' transition usually go back to multiple states

deprecate Transition.set_transition_permissions in favor of set_permissions (after all we know we're on a transition entity)

introduce 'go back' transition: transition without destination state will go to the state we were coming from

fix optimisation with super session that may lead to integrity loss at some point I've decided to stop ensuring ?1 cardinality was respected when adding a new relation using a super session, to avoid the cost of the delete query. That was yet discussable because it introduced unexpected difference between execute and unsafe_execute, which is imo not worth it. Also, now that rql() in migration script default to unsafe_execute, we definitly don't want that implicit behaviour change (which already cause bug when for instance adding another default workflow for an entity type: without that fix we end up with *two* default workflows while the schema tells we can have only one. IMO we should go to the direction that super session skip all security check, but nothing else, unless explicitly asked.

[auto/inline forms] reallow nested inline forms #703910

[reledit] fix #713217: reledit doesn't check 'update' permission on attributes

fix dumb name error

cleanup internal forms parameters in postlogin

grmmbl, bad resolve

missed conflict

backport lost stable head

fix sync_schema_props_perms test

fix create_user function introduced in d6ae30c5d055 for database initialization: messup admin user groups when anon is created due to missing restriction

3.6 api update

fix unittest_hooks: attributes have now update_permission instead of [add/delete]_permission

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...