[12.0] Add shopinvader_customer_multi_user

[simahawk]

Includes #469, look at last commit only,

@lmignon @sebastienbeau one more thing we've talked about in LLN.
Specs as we defined are here #454.

[lmignon]

Thank you @simahawk once again 'Cristal clear code' ! Looks good to me at first read. I'll test it into the coming days...

[lmignon]

@simahawk We should explain that the multi user is by company....

[lmignon]

@simahawk can you fix the pylint error PLZ https://travis-ci.org/shopinvader/odoo-shopinvader/jobs/601762911#L389

Thanks

[codecov-io]

Codecov Report

Merging #471 into 12.0 will decrease coverage by 33.73%.
The diff coverage is 54.05%.

@@             Coverage Diff             @@
##             12.0     #471       +/-   ##
===========================================
- Coverage   91.03%   57.29%   -33.74%     
===========================================
  Files         121       56       -65     
  Lines        3456     2323     -1133     
===========================================
- Hits         3146     1331     -1815     
- Misses        310      992      +682

Impacted Files	Coverage Δ
shopinvader/services/customer.py	25.86% <0%> (-65.21%)	⬇️
shopinvader/services/partner_mixin.py	26.13% <0%> (-66.97%)	⬇️
shopinvader/models/res_partner.py	51.66% <25%> (-32.82%)	⬇️
shopinvader/services/address.py	39.18% <62.5%> (-54.93%)	⬇️
shopinvader/components/access_info.py	63.63% <63.63%> (ø)
shopinvader/models/shopinvader_partner.py	26.15% <0%> (-73.85%)	⬇️
...ader/wizards/shopinvader_variant_binding_wizard.py	22.8% <0%> (-73.69%)	⬇️
...der/wizards/shopinvader_category_binding_wizard.py	27.65% <0%> (-70.22%)	⬇️
shopinvader/services/abstract_mail.py	27.27% <0%> (-61.37%)	⬇️
... and 100 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update dcdb8bf...6342e3c. Read the comment docs.

[simahawk]

@lmignon I've drafted a bit of refactoring here:

• partner_user on service ctx
• new component to deal with access to partner resources (not convinced yet but it's a start)

if we find a good way to track changes (eg: post a message or a notification when the sub user edits something) I think we are almost good.

Then probably, we should lock editing on "protected" records by raising errors.
In this case I wish we had a user record so that we could use record rules 😅

[simahawk]

I've listed here CRUD operations, but create here makes little sense because you cannot create a new profile w/out registration.

[simahawk]

at the same time create here makes little sense because create address permission should be global.
I'd say we should have anaccess or permission key in the global payload which states what you can do or not.

This seems to be the right place (when you get the customer/profile information).
We could have something like:

    def get(self):
        if self.partner:
            customer = self._get_customer_info()
            return {
                "data": customer,
                "store_cache": {
                    "customer": customer,
                    "permissions": self.access_info.permissions(),
                }
            }
        else:
            return {"data": {}}

@lmignon @sebastienbeau what to you think?

[simahawk]

I've rebased this on top of #495 as it unifies customer info handling

[lmignon]

This addon doesn't depend on locomotive. we should explain how the addon works reagrding the service layer...

[lmignon]

@simahawk Why not "readonly" : True ?

[lmignon]

what already exists?

[simahawk]

I've implemented it here https://github.com/shopinvader/odoo-shopinvader/pull/471/files#diff-6a87955a2b1b8be929d84353c6449701R37-R50

Basically by default they can do everything. Then customer multi user module overrides it to block creation of new addresses. Hence, the current behavior is:

• main account not enabled -> no matter where you are, you cannot do anything. You are redirected to an account page /account/addresses-user-disabled which shows

• address not enabled -> you cannot use it:

• you are a simple user -> you can edit only your own address if enabled:

• you are a simple user -> you cannot edit profile data:

• you are logged in as main company -> you see the token to share for allowing registration to your profile:

The WIP PR for the template is here shopinvader/shopinvader-template#21.
We'll merge it only when this PR is merged.

I don't think we need anymore to raise a specific error for users not validated. We could also get rid of the validation methods in the controller and maybe just leave an hook.

The addition of access and permission opens the door to fine grained control by scope on what users can do client side. There's only one issue: we cannot handle them when the components are loaded inside and event handler because at that stage there's no partner nor partner_user in the work context (eg: on payment transaction update).

Once we agreed on the current implementation I clean up and add proper test coverage (I left tests aside as I had to test w/ the UI as well).

@lmignon @sebastienbeau your feedback is appreciated 😉

[simahawk]

extrapolated permission handling to #533
should be rebased on it.

[simahawk]

moving to v13 #545