Create active_client_accounts

[micheal-w-wells]

Related to https://github.com/bcgov/range-web/issues/418

Create user_id, client_id, type, where type is 'owner' or 'agent'

[micheal-w-wells]

add linked by user as field add changed date as field

Do we want history?

[calebissharp]

@micheal-w-wells Instead of history, we could possible just add an active column. Then instead of deleting links we don't want anymore, we just set active to false.

[micheal-w-wells]

I'll say yes to active/inactive, and a changed date column. I suppose 'linked by' is only going to say 'myrangebc' at this point anyway.

[calebissharp]

@micheal-w-wells I've found a potential roadblock with this solution. If a user is assigned to multiple client IDs, (for example, the user Leslie Knope is linked to the clients Leslie Knope and April Ludgate), and they go to sign a submission, how do we decide which client to attach the signature to? This would be especially tricky if both Leslie Knope and April Ludgate are agreement holders on the same RUP.

[calebissharp]

One possible solution I've though of is to display a dropdown in the navbar that would let the user select which client they want to act as. This could potentially come in handy for agency agreements as well.

[micheal-w-wells]

I see what you are saying, but one user should only have to worry about one signature on each RUP. I think if someone has two active client + loc codes in FTA for one RAN something is set up wrong on that end. It would mean we are sending them two bills or they are a partner with themselves for the same agreement, or two AH are sharing a BCEID which isn't a thing. The scenario you have given is test only as far as I understand.

[micheal-w-wells]

@LisaMoore1 am I out to lunch, can you think of a time where one BCEID should be attached to multiple clients on one RUP other than testing?

[LisaMoore1]

@micheal-w-wells Would this be an example?

• Joan and Frank are AHs — their grandson Marco is the agent for both of them
• I’m not sure because I’m not sure what you’re thinking for differentiating AHs from agents. I can’t think of a straight up AH situation where the same BCeID would be used to identify to separate people.
• wondering about a business but I don’t think that would apply because they just need one of their signing authorities to use the single business BCeID to represent the company

[micheal-w-wells]

That helps @LisaMoore1, I just wanted to clear up @calebissharp 's concern here about Leslie and April both being clients for Leslie and being on the same RUP:

@micheal-w-wells I've found a potential roadblock with this solution. If a user is assigned to multiple client IDs, (for example, the user Leslie Knope is linked to the clients Leslie Knope and April Ludgate), and they go to sign a submission, how do we decide which client to attach the signature to? This would be especially tricky if both Leslie Knope and April Ludgate are agreement holders on the same RUP.

[LisaMoore1]

@micheal-w-wells and @calebissharp I’ve been taking the view that BCeID login/confirmation = a signature. Only one person can sign “their” signature therefore one BCeID = one client. In the case of a business they may have multiple signing authorities associated with that client. In range we aim to have a single person as our point of contact (the primary agreement holder where there are multiple AHs — meaning a primary AH has no other rights/obligations than the other AHs other than getting the physical mail). Where there is a ranch manager they act as agent for the company and they are our primary contact. This is why I keep going back to agency agreements being the trickiest aspect of linking accounts. If we solve that I believe we by default solve all other significant issues with account linking, client #s and locations. I think the April and Leslie scenario is a testing anomalies.

Related...again from an agent perspective — how would we handle a situation where an agent is also an agreement holder? Their BCeID would be linked to their CLIENT# for sure...but that BCeID would also need to be identified as an agent-BCeID for a second (or perhaps even 3rd) client.

[calebissharp]

Perhaps we should then move plan_confirmation to use the user id, rather than the client id. As well, maybe client_agreement should just be used to determine if a user has access to a given RAN based on the entries in active_client_account.

[micheal-w-wells]

The gotcha scenario I have seen with that one @calebissharp is when an AH goes from a primary to secondary on a RUP (or otherwise use another client_id associated to that BCEID), what do you do with their signature? What we have now (with the last fix anyway) is that they would now have to sign again because of the new linkage (previously signatures were just broken in this scenario). I'm not sure what the ideal is, and if its ok to carry signatures forward when its a new client_id but same bceid.

EDIT: I think I answered my own question. If someone went from primary to secondary that change alone would constitute a change of AH and would need another signing.

[calebissharp]

Moving from primary to secondary doesn't actual change the client ID though, does it? And plan confirmations reference ref_client.id.

[micheal-w-wells]

@micheal-w-wells and @calebissharp I’ve been taking the view that BCeID login/confirmation = a signature. Only one person can sign “their” signature therefore one BCeID = one client. In the case of a business they may have multiple signing authorities associated with that client. In range we aim to have a single person as our point of contact (the primary agreement holder where there are multiple AHs — meaning a primary AH has no other rights/obligations than the other AHs other than getting the physical mail). Where there is a ranch manager they act as agent for the company and they are our primary contact. This is why I keep going back to agency agreements being the trickiest aspect of linking accounts. If we solve that I believe we by default solve all other significant issues with account linking, client #s and locations. I think the April and Leslie scenario is a testing anomalies.

Related...again from an agent perspective — how would we handle a situation where an agent is also an agreement holder? Their BCeID would be linked to their CLIENT# for sure...but that BCeID would also need to be identified as an agent-BCeID for a second (or perhaps even 3rd) client.

To summarize my understanding of what we need:

• 1 BCEID = 1 Client, where Client (with a big 'c') here we mean the literal person.
• 1 Client/person, can have multiple client (little 'c') records in FTA. There are plenty of examples. I'm operating on the assumption we don't want to make these people make multiple BCEIDs.
• 1 Client/person, can have multiple signing authorities for themselves
• 1 Client/person, can be the signing authority for multiple other Clients.

Moving from primary to secondary doesn't actual change the client ID though, does it? And plan confirmations reference ref_client.id.

It does, because it's a new location code, so new loc + client number = new client_id as it is currently implemented.

[calebissharp]

So, if big 'c' Client represents a physical person/BCeID, than I think at least plan_confirmations should use the user id. (That's how it works in real life anyway. I assume you don't forge the signature of the person you're signing for as an agent). Then we just use little 'c' client records as a way of gating access to RANs for Client/person/BCeIDs (we could probably disambiguate things by adjusting naming). The trickiest thing I see with agency agreements so far is you still probably want a way to identify which Client/person the agent Client/person is signing for. Maybe we take the name from the client/FTA record and use that?

[micheal-w-wells]

That works we just have to make sure not to carry a signature forward when it shouldn't. I'd say put signee as one field and signed for as another user_id field.

I don't think we want to rely on name. If I am an agent, the RUPS i can view are dictated by client + loc records assigned to me, so user_id : client_id, wherever we want to put that (plus a page/interface to do so). I should not be signing for more than one party on a given RUP. It should be straight forward from there to know based on the RUP I am viewing, and the agent user_id <> client_id link which record gets signed.

[micheal-w-wells]

table: agent_client_link agent user_id, client_id

[calebissharp]

Just to clarify @LisaMoore1, in the context of agency agreements, it is not possible to be the agent for multiple AHs on the same RAN?

@micheal-w-wells I think we have the user_id:client_id portion covered by active_client_account. I like the idea of signee and signed for on plan_confirmation. I assume those would be the same user.ids if someone signs for themselves. While we're on the topic, do you know of any other tables like plan_confirmation that are using ref_client.id right now but should be using user.id instead?

[calebissharp]

Also, after working with active_client_account a bit, I'd like to change the name. user_client_link seems more semantically useful.

[micheal-w-wells]

user_client_links it is. Yes it would be themselves in case of them signing it, you got it. Can't think of anything else using client_id that's at issue right now, but will keep eyes peeled.

Above it looks like @LisaMoore1 had this example I missed Joan and Frank are AHs — their grandson Marco is the agent for both of them . If we can legally have one agent sign for both parties in this case, they'd likely have a RUP together. I think a low effort implementation that could work for now is sign it for all relevant parties if there is more than one, and if that doesn't work expand to a selection component.

[LisaMoore1]

@calebissharp

• a non-AH child of the AHs (a mom and dad venture) could be the agent for either OR both parents
• an AH child of the other AHs (family venture) could be the agent for either or both parents
• a non- family member could take the same roles as “child” above
• a business may have multiple signing authorities AND a ranch manager any of which could sign

Principles

• we need to know if we have an agent versus AH signature
• staff need to easily see (a table maybe?) for each RAN/RUP who has an agent and who it is
• an agent may stop being an agent but if we look at the history we should be able to see that an agent (including their name) signed at a specific date on a specific version — the version remains legitimate if the agency agreement dissolves mid-way through a RUP term

@micheal-w-wells Re. Agreement Holders

• for the purposes of collections and agreement responsibilities there is a SINGLE agreement holder made up of all of the partners (whether Joint venture (JV), Ltd. Company or whatever)
• the entity we call agreement holder (made up of all its people) is, as a single entity responsible for all obligations and share the rights equally
• the individual partners that make up that entity do not have separate rights/responsibilities excepting for the one identified as primary getting the snail mail/phone calls
• we do not consider the entity to have signed until all the partners that make up that entity have signed
• if the entity gets shuffled around to have someone else get the mail/phone calls we don’t care (about collecting new signatures) so long as the ENTITY consists of the same collective of individuals
• if a person is added to the partnership we consider that to be a new entity and we require a disposition form (as though they were transferring it to a completely different person) and a new plan/signatures is required — this disposition would result in a shift in FTA as the primary (if they stay the same) would get a new location code that includes all of the old JV partners + the new one (usually all the JV partners but the primary are using their -00 code)

[calebissharp]

@micheal-w-wells What do you think the best way to look up which users to sign for based on the client is? Right now we have the type column which can be owner or agent. I'm thinking we add a constraint to only allow 1 owner record per unique client_id, to allow us to do a reverse lookup on client_id to get the associated user account (which we'd use for the signed for column in plan_confirmation)

[micheal-w-wells]

@calebissharp I think we would look it up the same we we looked up what RUP they can see. This is my understanding anyway:

User BEN in user_client_links would be an agent for client_id 123. We get 123's user_id from the same table. I think your idea for a constraint works there.

We get then get RUPs he can see the same way we would get RUPs. for client 123. We look in client_agreement and grab the records with matching client_id, and from there join on plan with agreement_id and we have the plan_id to go to plan_confirmation. We also check if there is another agent record for the same agreement here, grabbing all other client_ids for this agent in user_client_links, and then look in client_agreement for a matching RAN.

Again in the rare case you get more than one result (grandson signing for multiple) i'd say v1 just sign for both v2 make a checklist where you explicitly choose people to sign for.

[LisaMoore1]

@calebissharp @micheal-w-wells Not sure if this adds to the understanding but you could also have a situation something like this:

• agent 1 acts as agent for two of the three individuals on RAN071234 and one of the individuals on RAN075678
• agent 2 acts as agent for the the remaining individual on RAN071234
• agent 2 also has their own RAN077890 that they hold on their own

[calebissharp]

@micheal-w-wells We should be able to do sign for both. We may have to augment the data returned from /user/me to also include the relevant represented user accounts.

[micheal-w-wells]

@calebissharp this one is done isn't it? or does the name of the issue not really match the work anymore?

[calebissharp]

Resolved by #162