Consultant accounts - an implementation suggestion

[nhoening]

Why

Issue #203 asked for a new authorization, which enables users in some (non-admin) accounts to access the data in some other accounts. Let's discuss our first implementation step here.

In practice, this is useful for a channel partner of ours who has existing customer relationships and would rather manage them themselves. Some use cases:

• To review their data, maybe in joint sessions, or just for their own service delivery
• To create and edit assets
• To be notified of problems like outages
• ...

Let's work on the first. We want to give some read-permissions.

Data model

I propose that each account can have one consultancy_account_id field (defaults to None). If set, that account has consultancy rights.

This would require a simple & backward-compatible data model migration.

Changes to auth policy

Here is how the ACL policy in a GenericAsset for read-access looks like now:

acl = {
    "read": f"account:{self.account_id}"
    if self.account_id is not None
    else EVERY_LOGGED_IN_USER,
}

Let's enhance it like this:

accounts = []
if self.account_id:
    accounts += self.account_id
if self.consultancy_account_id:
    accounts += self.consultancy_account_id
    
acl = {
    "read": f"account:{','.join(accounts)},"
    if self.account_id is not None
    else EVERY_LOGGED_IN_USER,
}

Likewise for Sensor.

Testing

We need to add a few tests to make sure this is working.

• add an account to conftest, with a user, and make them consultant on an existing account
• Test that this user can read assets and sensors from an asset in the existing account.
• Test that they cannot edit or create assets or sensors.

We should also find a way to test this in practice. Browsing the FlexMeasures UI on localhost with a consultancy user made for this purpose is a good approach. One could also see if the FM client handles this well.

And at Seita, we can use a development version of this in our V2G living lab.

UI

• We want to see on the account page who the consultant for an account is.
• Likewise, we want to see which accounts are being managed on the account page of the consultant. These should actually be links to the asset list for these accounts, so the consultant can have a means to access them conveniently.

In order to do this, we'll probably have to add this new field in the data model to the Account API (which for now has only GET endpoints).

Editing accounts in the UI (not creating, yet) is something we should also add at a later point, and then this field would also be in that form.

Addendum: also require a user role

We could already model that only certain roles in the consultancy account have these special rights. They might add users to their account without wanting them to have such powers.

Let's call that role "customer-manager" for now.

read_access = EVERY_LOGGED_IN_USER
if self.account_id:
    read_access = f"account:{self.account_id}"
    if self.consultancy_account_id:
         read_access = f"account:{self.account_id}, (account:{self.consultancy_account_id}, role:customer-manager)"
    
acl = {
    "read": read_access
}

Left out

To be sure, there are some ideas not touched upon here:

• creating / editing rights by consultancy accounts. Let's sort out what we really want to allow here. Implementation: more work on ACLs, more tests
• accessing user accounts, or even accounts
• Allowing consultancy accounts to split their customer base and let some users be the customer managers for some of their customers, and other users for other accounts. I'm not sure this is really needed anytime soon, and it is much more complex than what we can do here with this overseeable effort.

[Flix6x]

I really like this new feature as implemented in #877. I'd like to propose simpler terms, though:

• Consultancy for relevant organisation accounts
• Consultant for relevant users (rather than customer manager)

Imo the term customer manager just brings to the table two extra terms making things harder to parse. And is it currently stands, it might also be a bit of a misnomer, with the given user only having read rights (even though it is expected to have additional rights at some point in the future, while that isn't worked, it doesn't quite fit the bill for me). I'd be happy to make a PR accordingly (which would be best to do before releasing 0.17).

[nhoening]

I agree that the term "customer manager" is not ideal.

Your proposal is to just change that term? Or are there other changes proposed?

[Flix6x]

I haven't proposed anything else yet, but if I make the PR, then besides changing the term (and corresponding documentation), there is one other change I'd propose, in the CLI. I'd make the consultancy-account-id option an AccountIdField instead of an Integer field, so there is some Marshmallow validation, and then rename it to consultancy.

[nhoening]

Fine with me!

[Flix6x]

For future reference: #892

[nhoening]

Work in #877 is merged. Closing this discussion.