How to use membership classes with multiple 'projects'...?

  • Thread starter Thread starter Glenn
  • Start date Start date
G

Glenn

My current classic-ASP site has users, projects, roles and the 2.0
membership looks like a perfect fit, but I'm having trouble finding
examples of how to have users that belong to different projects, and
have different roles per project.

The current model..

* When a user joins my site, they eventually end up joining or
creating one or more projects. But, they are not required to be a
member of a project to be a member of the site.

* As a member of the site, a user can be a member of zero or more
projects.

* They can create a project, for which they automatically assume a
'project owner' role.

* They can also join an existing project, in which they assume the
'regular member' role by default.

* So, a project will always have a member with the 'project owner'
role, zero or more with either the 'project lead' role, and zero or
more with the 'regular member' role.

* Users can leave a project at any time, unless they are the project
owner, in which case they must transfer ownership to another project
member.

* A common 'view' for a user is to view information across the
projects of which he is a member.

Currently, I have over 20,000 users, each with a unique user id (int),
and 500+ projects, each with a unique project id (int). A simple join
table associates users with projects (table:'user_projects': columns:
user_id,project_id,role,etc.)

Can I adapt the ASP.NET 2.0 membership classes to this model? After
looking for a while, I don't think an 'application' as defined by the
membership classes correlates to a 'project' in this case. I think my
projects need to be more dynamic.

Any tips, pointers, examples would be appreciated.

Thanks,
Glenn
 
You can write your own membership provider to fit in with the existing 2.0
set of classes although its not something ive bothered to do.

Generally, I tend to "Roll my own" membership classes as I find it gives me
most flexibility. The set of standard classes supplied with .net are really
there as starter blocks if you like but if you need to get more serious,
then either write your own provider or simply write your own code to handle
membership and roles, It sounds like youve already done it in the backend
for ASP anyway, so a simple port to the new environment is all you probably
need to do.
 
I think Membership and Roles --as is-- would work just fine with a
role-based schema analagous to an alphanumeric part numbering schema so
widely used to assign "membership" and "role" categories to products, parts,
assemblies and so on.

// conceptual alphanumeric example of a "set"
G000 -- G(uest) with default access to all projects.
P000 -- P(roject) Creator

Make the alphanumeric identifier with several sets to account for future
extensibility...
G000-000-000
P000-000-000

Use alphanumeric or numeric characters in the sets to designate access
rights, project types and so on.

G001-000-000 - Guest with access to Project Type 1 where 1 may represent all
read, write, edit rights or some other designation but not the right to
delete the project and so on.

Instead of writing all the provider code you just write your own
authenication class which assigns and modifies user's roles when they
create, join or leave projects which should also be categorized by type and
indicated alphanumerically in one or more of the sets of indentifiers.

I had to so some of this for some e-commerce applications when using ASP. It
takes a lot of thinking and planning but IMO Membership and Roles --and--
Profiles are already setup for what can be complex membership models.


<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
 
mmm, well ok. But I think this fixed numbering is restrictive. better to use
relational tables with almost unlimited expansion. The way I normally do it,
is to have non hierarchical role types, so a user can have many roles
assigned to them, which do not directly depend on each other other than in
the business logic. Permissions are dependent on the object one is
accessing, again, your system can then have a table of object types with a
set of permission types associated with them. and these can be stored in a
permissions table associated with the user and objects.

ON top of this is you really want to get clever you can add groups as well,
but then you enter the arena of group manegment, and groups in themselves
like users are just another object. Where it gets really hairy is when the
groups are inclusive and exclusive as well as being nested.

Your statement about carefull thought is probably the most poignient one,
when designing such a system, one needs to keep a few things in mind.


1.) Make sure you did a good systems analysis job first.
2.) Think carefully , very carefully.
3.) Make sure its workable, and signed up to by the client, as changes
afterwards can be a nightmare.
4.) Keep flexibility in mind, but beware of over complex design.

Hope that helps.
 
Back
Top