I'm just starting with DNN (4.x), and like a few others have a desire for cross-portal users.  I've read through the June 26, 2006 revision of "Enhancing Membership_3.3_.pdf", and looked at the current (4.3.4) DNN datamodel.  I think there may be a simpler solution.  I'm not sure if this is the place to post my idea or if someone has already discussed this - if so please point me in the correct direction.

As an owner of portals, lets say I have 3 portals: one for knitting, one for crocheting, and one for sewing.  I'd like to be able to let users register once and use 1, 2, or 3 of the portals.

Some users may only be interested in one or two of the portals, while others might be interested in all 3 topics.  As a user, if I registered with the sewing portal, I'd like the option of also being registered with the knitting and crocheting portals, but it should be an option.  My reason for this is that I think one other missing bit in DNN is the ability for members to create a personalized page in the portal, and to allow members to search and view each others' profiles.  If that piece is in place, a user may not want to automatically be part of all portals (maybe they love sewing but think knitting is embarassing).  Such a user should show up in the sewing portal membership list, but not the knitting portal membership list.  Ideally as a user, I could go back to my registration page at any time and add/remove myself from available portals.

To implement this, I would still use Portal Groups.  However, they would simply be used to display the portals available for registration.  So lets say Portal Group 1 has portals A, B, and C.  And Portal Group 2 has portals D, E, and F.  Let's say I browse to Portal E, and click on a "register" link.  It should take me to the Portal E registration page, which should include check boxes allowing me to apply my registration to Portals D, E and/or F.  By default, the Portal E check box should be checked.  The system could then process each registration exactly as it does now - only the business layer would handle registration to all checked portals at once.

I would not use Portal Group Roles.  If someone was a member of Portals A, B and C, but most active in Portal B, I might want to assign them a moderator role in Portal B, and just the "regular" role for portals A and C.  Keeping the Portal Roles retains the granularity of permissions.

I'm not sure if there'd be many use cases where a given Portal would be part of more than one Portal Group in my approach, but there's no reason not to allow this other than it adds a little complexity

So what changes would be required?
1)  A PortalGroups Table: A list of PortalGroups
2a)  A PortalGroupID Field in the existing Portals Table: to identify the PortalGroup that the Portal belongs to
  OR
2b)  A PortalPortalGroup Table: to allow a Portal to be associated with multiple Portal Groups
3)  A change to the registration (contral/tab???) and classes:  For a new user will list all Portals in the same Portal Group as the current Portal.  The user can check which Portals they want to be registered with.  For existing users, the control will list all Portals they're currently registered in, as well as any portals they're not registered in, but that are part Portal Group(s) that are the same as Portals they are registered in.  Then a user can add/remove themselves from individual portals at will.  The fact that the registration page would include all currently registered portals for the user allows Portals to be added/removed from Portal Groups at any time.
4)  An updated user admin screen allowing an administrator to easily manage all roles for all portals for a given user.
5)  Cross-site authentication as outlined in "Enhancing Membership_3.3_.pdf"

One other related issue from my perspective is cross-portal modules.  It seems by editing the TabModules table in the current DNN, I can share a module between portals.  (In my case, I want to share the Forums module between 2 portals).  I would like to see the "Add Existing Module" functionality expanded so that you would have all modules from the same PortalGroup as the current Portal available here.  The forums users are tied to Users, not Portal Users so for forums at least, this should work OK.

I think the approach I've outlined will support powerful cross-platform users, while maintaining excellent permissions granularity.  Plus, I think it would minimize the changes required to DNN.  Quite likely this has already been suggested, and there are problems with it that I'm not aware of.  (I'm still a real newbie).  But at the very least I will get a better understanding of DNN if someone can comment on my suggestions.