Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[13.0] [MIG] partner_multi_relation #936

Merged
merged 35 commits into from
Sep 8, 2020

Conversation

NL66278
Copy link
Contributor

@NL66278 NL66278 commented Jun 29, 2020

My attempt at migration of the module. Including all the fixes already present in 12.0.

@pedrobaeza
Copy link
Member

@NL66278 I see you are not following the migration guide:

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-13.0

for proper commit separation for things like auto-formatting. Can you please check?

@NL66278
Copy link
Contributor Author

NL66278 commented Jun 30, 2020

@pedrobaeza I agree that I could have split commit 221c324 to have the header correction on test and the other changes in test in separate commits, but I think in the other commits I did not mix up functional changes and changes for conventions. Please take into account that I build on the migration work don by @Rad0van in commit fa907bb, and then cherry-picked the commits from the 12.0 branch that were missing.

@pedrobaeza
Copy link
Member

I mean to split the [IMP] $MODULE: black, isort, prettier commit from the migration one, being the auto-formatting previous to that one, and avoid later commits like 8f4ff0a. With current approach, each time you touch the code for fixing something, you will mix formatting tasks with code patches.

@NL66278
Copy link
Contributor Author

NL66278 commented Jun 30, 2020

@pedrobaeza But I have separate commits for black, isort etc, and on the other hand for functional changes. So what exactly do you want different?

@pedrobaeza
Copy link
Member

The problem is the order in which you have made such operations: first should be auto-formatting for all the existing code. Then you add the rest of the code (that is auto-formatted by default). If not done that way, as said, you mix diffs with code formatting and patches.

@pedrobaeza
Copy link
Member

Anyway, I'm missing a lot of commit history from previous branches...

I think you need to redo from scratch the migration, or at least redo the procedure and then mount on top the 13.0 stuff from you and the other contributor.

NL66278 and others added 23 commits July 6, 2020 19:44
* API of _auto_init
* Menu and groups
  stuff has moved from base to sales_team in odoo 10
* Fix error on search when leaf is (1, '=', 1)
* Another comparison fix with search arguments
* Update README
* Python 2to3
* Move relation menus items under contacts
* Fix date comparison
* Fix cache invalidate on relation write
* Bump module version
* Remove test_relation_type_unlink_dberror

  This test is not required because it tests a standard behavior of SQL.
  If a foreign key column is not nullable, then the foreign row can not be deleted.

* Remove utf8 encoding comment
* Add missing dependency for partner_multi_relation
* Add missing active_test in view action
* Bug Fix
* Enable additional columns on res_partner_relation_all.

  Enable to add additional columns from res_partner_relation in the sql view of res_partner_relation_all.

* Only require inverse_name when relation type is not symmetric
* Remove deprecated @api.one and replace openerp with odoo
* Add website to manifest
* Prevent disabling allow_self if reflexive relations exist
* Enable deleting/ending invalid relations after deactivating reflexivity.
* Handle case of invalid future reflexive relations
Updated by Update PO files to match POT (msgmerge) hook in Weblate.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.

Translation: partner-contact-12.0/partner-contact-12.0-partner_multi_relation
Translate-URL: https://translation.odoo-community.org/projects/partner-contact-12-0/partner-contact-12-0-partner_multi_relation/
Currently translated at 86.6% (84 of 97 strings)

Translation: partner-contact-12.0/partner-contact-12.0-partner_multi_relation
Translate-URL: https://translation.odoo-community.org/projects/partner-contact-12-0/partner-contact-12-0-partner_multi_relation/es/
@rousseldenis rousseldenis added this to the 13.0 milestone Jul 7, 2020
Copy link
Contributor

@HaraldPanten HaraldPanten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @NL66278 here's my functional review:

I tried this use case:

  • Company A and Company B have a "is competitor of" relation between themselves. Both are companies.
  • "is competitor of" relation type has "Do not allow change that will result in invalid relations" invalid relation handling configuration.

TEST A:

1- Open Company A and check partner relations.
2- Navigate to partner form (from partner relations tree view) and change "Company" to "Individual".
3- An error is shown, but the change is done despite of the restriction.

TEST B:

1- Open company A form view and change "Company" to "Individual".
2- The change is done despite of the "is competitor of"//"Do not allow change that will result in invalid relations" restriction. Even the error message is not shown if I make this change directly from the partner form (instead of the partner relations tree view as I mentioned in TEST A).

IMO this fix should be done.

My IMP recommendation would be to show the restriction/field details in the error pop-up if user is trying to make an invalid configuration. If a contact has lots of different relationship types with other contacts, that would help a lot to find where are the restrictions, so... it would improve UX.

Imagine the TEST A and B defined before. That would be an example of the IMP that I'm proposing:

Captura de pantalla 2020-07-09 a las 12 18 47

Another use case/issue is that "invalid relation handling" seems not to be working properly, for example:

  • Company A and Company B have a "is competitor of" relation between themselves. Both are companies.
  • "is competitor of" relation type has "Do not allow changes that will result in invalid relations" invalid relation handling configuration.

TEST C:

1- I open Relation Types and I have "Do not allow changes that will result in invalid relations" in "is competitor of" invalid relation handling.

2- I change "Do not allow changes that will result in invalid relations" parameter by "Allow existing relations that do not fit changed conditions" invalid relation handling.

3- I select a partner and I check it's relations.

4- From the relations tree view, I navigate directly to the Company A and I change it's type to "Individual".

Issue: This error message is shown but IMO there shouldn't be any restrictions as I configured "is competitor of" invalid relation handling as "Allow existing relations that do not fit changed conditions".

Captura de pantalla 2020-07-09 a las 12 45 14

Same happens when I select "End relations per today if they do not fit changed conditions" or "Delete relations that do not fit changed conditions".

As a UX IMP, I propose you to set different messages depending on the invalid relation handling action. Imagine that you're going to delete relations because you've configured "Delete relations that do not fit changed conditions" and you're going to omit a restriction. Maybe a warning like --> You're going to delete this contact relations because you're not respecting the 'Delete relations that do not fit changed conditions' invalid relation handling.

What do you think? Hope it helps you!

@NL66278
Copy link
Contributor Author

NL66278 commented Jul 9, 2020

@HaraldPanten Thank you for your review. Note that this is a migration PR, but your tests exposed some shortcomings in the existing code, and some limitations that perhaps have not been properly pointed out.

In Test A and in Test B you are changing the partner. At present the test and the settings for how to handle existing relations are a constraint on the relation type or the relation itself. Not on the partner. Therefore the change on the partner is allowed. I agree with you the code could or rather should be enhanced to prevent changes on the partner that would result in invalid relations.

This also explains why you sometimes get a message for changing a partner, but only when you change it from the relations view.

In test C the error is correct - we might discuss the message -, as you are changing an existing relation by changing the attributes of the partner. "Allow existing relations...." basically means that if you change the conditions for a relation, existing relations are not deleted or ended.

I will look into improving the error messages, and extending the checks to changes from the partner side.

It is not easy with Odoo to intercept a change that might have unwanted consequences - like deleting existing relations when the relation type is changed, than show a message, but allow the user to override the message and proceed...

@BT-jstein
Copy link

@NL66278 Thanks for your effort! We would highly appreciate to see the pull request merged since we are running a V13 project where this module covers the requested functionality.

@pedrobaeza pedrobaeza changed the title [13.0] [MIG] partner multi relation [13.0] [MIG] partner_multi_relation Sep 7, 2020
@pedrobaeza
Copy link
Member

@BT-jstein if you want to see it merged, contribute with your review to this PR: https://odoo-community.org/page/review

Copy link
Contributor

@rousseldenis rousseldenis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review

Copy link

@regispirard regispirard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functional review : LGTM.

Tested :

A) Configuration of use of relation type :

  • With left type person / right type organisation : ok
  • Reflexive : ok
  • Symmetric : ok
  • with right partner category (label) : ok

B) Invalid relation handling:

  • do not allow : ok
  • allow : ok
  • end relation : ok
  • delete : ok

C) Search in Relations / Relations (res.partner.relation.all) : Ok
Just noticed there was a filter "Include past records" which seems to have no use since the tree view already show all records.
I guess it was originally designed to show only active records, and this filter allowed to show active + closed records.
Anyway, it was also the case in V12 so, this might be an improvement and should not block migration.

Thank you

@pedrobaeza
Copy link
Member

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 13.0-ocabot-merge-pr-936-by-pedrobaeza-bump-nobump, awaiting test results.

OCA-git-bot added a commit that referenced this pull request Sep 7, 2020
Signed-off-by pedrobaeza
@OCA-git-bot OCA-git-bot mentioned this pull request Sep 7, 2020
47 tasks
@OCA-git-bot
Copy link
Contributor

@pedrobaeza your merge command was aborted due to failed check(s), which you can inspect on this commit of 13.0-ocabot-merge-pr-936-by-pedrobaeza-bump-nobump.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

@rousseldenis
Copy link
Contributor

rousseldenis commented Sep 7, 2020

@pedrobaeza It seems that http://download.geonames.org/export/zip/MC.zip is failing again... So, merging is blocked until they sove it...

@pedrobaeza
Copy link
Member

Yes, let's wait a bit. It's a temporary glitch as you know.

@rousseldenis
Copy link
Contributor

Yes, let's wait a bit. It's a temporary glitch as you know.

IMHO, that module should be moved to its own repo in order to not bother anymore people work.

@pedrobaeza
Copy link
Member

I don't think the same, as this only happens once in a couple of months. I'll be monitoring this. Don't worry.

@rousseldenis
Copy link
Contributor

I don't think the same, as this only happens once in a couple of months. I'll be monitoring this. Don't worry.

The problem is that you are not the only one working here.

@pedrobaeza
Copy link
Member

Nor you, and as said, I'm taking care of this. If I am the one that has started the merge process, why are you ranting about something that doesn't affect you directly? If you have one PR affected, then say it and we find a solution. Meanwhile, please don't start again with the same thing.

@rousseldenis
Copy link
Contributor

Nor you, and as said, I'm taking care of this. If I am the one that has started the merge process, why are you ranting about something that doesn't affect you directly? If you have one PR affected, then say it and we find a solution. Meanwhile, please don't start again with the same thing.

I try just to find a more long-term solution as people should have an environment as stable as possible and not influenced by external factors that don't depend on their code. That can be frustrating when contributing. That's all I say.

@pedrobaeza
Copy link
Member

This is working since v8 (6 years), and it's not a great problem. Only very rare occasions.

@pedrobaeza
Copy link
Member

/ocabot merge nobump

@OCA-git-bot
Copy link
Contributor

This PR looks fantastic, let's merge it!
Prepared branch 13.0-ocabot-merge-pr-936-by-pedrobaeza-bump-nobump, awaiting test results.

@OCA-git-bot OCA-git-bot merged commit c670d46 into OCA:13.0 Sep 8, 2020
@OCA-git-bot
Copy link
Contributor

Congratulations, your PR was merged at e68bc6e. Thanks a lot for contributing to OCA. ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.