views:

29

answers:

2

I want to create associations between users in my application. For instance there is a Program Director (Role:PD) which has many Residents (Role:Resident), similarly there is an APD (Role: Asistant Program Director) to each PD.

To each PD I want to show him only those Residents which belong to him i.e I want to filter the Residents by the given PD. I can filter the users by Resident role (by using the combination of GetAllUsers() & GetUsersInRole() methods) but I cannot seem to filter the Residents by their Program Directors as there is no way I can make associations between two role types in Membership tables.

What can I do to have this kind of functionality? Do I need to extend the Role Provider to handle this?

A: 

I think that you don't really want to create associations amongst the roles, but rather associations amongst the users (i.e. a PD user will have many resident users, but a PD role will not have many resident roles).

I don't think that there is a built in way to do this, but setting up your own database table to hold relationships between the users shouldn't be too hard.

Paddy
Yes you are right, its creating associations among the users and not among the roles, thanks!
skhan
A: 

This sounds more like a data relation between objects rather than an extension of the rle provider. Roles are basically a grouping of user types rather than actual users.

I would approach this using an additional table to define the relationship between a PD and their Residents, and use the roles to design the administration page, e.g display all users in role PD, and below display all users in role Resident to assign

Macros
Okay I got the idea that I need an additional table to hold the relationship between the users. As I would need new retrieval methods like GetUsersByPD(pdname), where should I write these methods? Preferably these new methods should go into a class derived from Membership but since Membership class cannot be inherited, where these new user retrieval methods would go ?
skhan
Difficult to say how best to implement without knowing a lot more about your system however the approach I would take would be to do this separately from the Membership provider. If you need a link between them you can join on UserId, and you could even create a separate table for both resident and PD, again joined on UserId. I find it is much easier to treat a user as any other object rather than battling to get it into the Membership framework
Macros
Thanks Macros, things have got clear to me now.
skhan