Not possible to add party relationships in 7.0

Maybe I’m overlooking something simple. Installed party_relationship in demo 7.0 database. Added relationship type plus reverse. But I can’t get the “+” button to work, adding new relationship records is disabled in party view and in party relationship view.

Tried the same in demo 6.8 and everything works as expected, i.e. I can add new relationships, delete existing ones etc…

At first glance, nothing has been changed in party_relationship in the last development cycle, so I’m probably missing something stupid…

Maybe you hit with:

I can not reproduce Issue #12742 on my local installation.

party_relationship phenomenon happens in SAO and in GTK client on local install, can be reproduced with demo7.0.

This is a different issue that must be reported. Could you please create it?

The issue was introduced with Make ModelSQL based on table query read only by default (5870e7a5b3ee) · Commits · Tryton / Tryton · GitLab and the problem is that we are missing an access rules for the party.relation.all model to allow users write on the model.

This is an easy fix, it will be great if you can provide a patch for it following Tryton - How to Develop

I will give it a try.

Shouldn’t this be caught by the unit tests? If not, how could they be modified to catch this? Tests pass fine AFAICT.

Normall table_query models are readonly by default, so that was improved on the recent version to make explicit when no record rules are available. This allowed to remove the access rules for most of the table models.

The party relation is a table query that should not be readonly, and this is an exception so there is no possiblity to make a generic test to catch this error.

On the other hand, if we explicity give the permissions to the model, the client will allow the users to write without any issues. So once fixes there should be no issue and we won’t need any test to validate such setup.

Yes I understand. I meant specifically the party_relationship unit tests like here

For me it is not needed to just test an access configuration.
We normally do not test access rules configuration for modules as we know that the access rules work (there is a bunch of generic tests for access rules) and once they are setup they can not be broken.

See Default access for ModelSQL based on table_query does not follow customization (#12757) · Issues · Tryton / Tryton · GitLab

Thanks. It seems there is nothing left to fix for me ;-), but at least I managed to get/reset my heptapod password…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.