Peer Multiple reference object

[JoshK131]

I have an Account BO and a RegularUser BO.
If an Account can have many owners, this needs a 2 way peer multiple reference attribute.

If i want to say what kind of owner it is, then ill need to make a new AccountOwner BO with a single RegularUser and single Account with some other attributes detailing the relationship.

The peer multiple reference already creates a SQL table "account_ref" which would be functionally similar to the "AccountOwner" BO created but the AccountOwner will have other fields.


If we could add some custom attributes to the existing peer multiple reference so we can use the additional data when needed, but also use the nice INSERT, REMOVE and other functions related to the multiple reference would help.

Then i also wouldnt have to do EXISTS Account WHERE ( EXISTS AccountOwner WHERE ( AccountOwner.ps_Account = Account AND AccountOwner.ps_Owner = LoggedInRegularUser AND AccountOwner.Type = 'Manager'))

Instead something like EXISTS Account WHERE ( LoggedInRegularUser IN Account.pm_Owner WITH Type = 'Manager')

I hope that makes sense
Thank you.

[nhofkes]

Can you clarify what your question is ?

Also, it would be helpful if you could explain what type of account you are referring to, because it is not immediately obvous why an account would have many owners. I am working on a system that also uses accounts, which can hold e.g. shares, options or cash, but I am working from the assumption that each account has just one owner.

[JoshK131]

I dont have a question. Just a wish list post.

If there are many tiers of managers for example, then many different people should have access to an Account.
Instead of having ps_Manager, ps_Owner, ps_Supervisor, having 1 pm_Owner makes it easier to manage access permissions.
But now in the PM, i dont know who the manager, owner or supervisor of the account is.

[PointsWell]

I dont have a question. Just a wish list post.

If there are many tiers of managers for example, then many different people should have access to an Account.
Instead of having ps_Manager, ps_Owner, ps_Supervisor, having 1 pm_Owner makes it easier to manage access permissions.
But now in the PM, i dont know who the manager, owner or supervisor of the account is.

I would recommend that you use a third table to manage your AccountManager relationship (and any m-n relationships), as this will maintain the ability to track more dimensions to that relationship that you will probably need further down the line (e.g. date started, date ended).

I personally avoid peer multiple lists as much as possible ( in 1-m relationships create the relationship from the side that has the singular relationship e.g.one person has many cars, create car and add the peer singular from there to car, this will prevent the person BO generating a ref table).