As a set of modules similar to subscription tools, I am building a bunch of modules catered to the reselling of child portals. These will be known as "Portal Tools".

Currently, I am in the design phase and need to gather some feedback.

I currently have my main site that offers portals for sale. This site has a various series of screens such as support forums and help desk for lodging trouble tickets. So a user has to be registered to participate on the main site.

The trouble comes when they go to sign up for a portal as a new account is created during the signup process of the new portal. So they would now have a potential for 2 usernames & passwords, although, most likely they would be the same.

The main portal would contain all of there account statistics such as when the portal expires and status of their subscription (Active or Cancelled). Very similar to the new modules I'll be adding to subscription tools.

Are there any additional facilities you would like to see?

OOooo.. *drool*

Here is my scenario.. maybe you can tell me if what you are doing will fit in here.

I have my main site.  This main site will have subscription only features my users will want.  Some users however, want a more personalized site, and therefore will want their own child portal....    member2.site.com, member3.site.com, etc.

So they will sign-up for their own child portal, and then sign up for any value add modules I've been programming.  With this, they'll be able to create their own view of the world using data from the main portal, but with their own personalized view.

Will they be able to give view access to certain areas of their child portal to usernames of the main site?  Some of their stuff they want to make public, some of their stuff they want completely private, and some of their stuff they want to give access to only certain people.

>Your point regarding separate usernames & passwords for the main site and the portal

If you had sub portal modules which 'shadowed' the content (DNNForge) modules on the main site then you do not necessarily need the sub portal users to log into the main site.  Moving between sub portals is a different issue which could be explored with the ASP.NET 2 membership model custom providers.

see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/bucupro.asp

I do see a need for a common logon page (SSL capable) accross all the sub portals.  There is a certain level of credibility that is gained when the user knows that the site is secured during login.

>Your point regarding the main portal account statistics (portal expires, status of their subscription)

Can the users see their account information that is stored in the main site?  They could if the the module was 'shadowed' and filtered (portalid could be determined at runtime).

Great work Scott.

sbosarge pretty much nailed it IMO.

In talking about this with some other people in the community, it seems like there are two separate camps (maybe three) of how they'd like to use DNN.

1st Camp:  The users.

These people just want a single DNN site on a domain name.  No child portals, just one portal with some members for family, or a gallery of pics for some kind of group, etc.etc.  Very simple, DNN serves these folk extremely well, and I'd think is the large majority of people.  They might also have storefronts, and make some money with some simple subscription services,etc., but it's currently quite easy to extend DNN for their needs.

2nd Camp: The hosters.

They want to host websites for others to make some money. i.e. No common theme, private websites, anyone with a child portal can do what they like with it, with the modules provided.  There is some upselling with "Premium" modules, but the users can skin it how they like, put whatever content, etc. 

These guys have great servers, great bandwidth, backup, battery backup, dedicated servers, shared servers, etc.etc., and perhaps offer other services as well to the user of the child portal.

Sure there are tons and tons of scenarios with how this would be set up, but the common theme is, they are basically just an ISP offering a prebuilt portal site.  This seems to be what DNN is currently geared for... The ISP and the user.

3rd Camp: Us!  (I think)

We have our own DNN installation.  We have a theme for our site.  We want to extend the website by giving users their own child portal based off of the users and content of the main site.  We want to give them their own "Space" inside of a very public community.   It should be single sign-on... one sign-on to get to the main site content, giving the user appropriate permissions to content based on roles.  The same sign-on should also give them appropriate access to their child portal, giving them appropriate admin access to their portal.

Here is the kicker for me....  my users would like to assign people (users from the main site) into roles for their child portal, so these users can see information specific to the child portal owner.  Make sense? Kind of hard to explain.

My example, my users have a private list of what wine bottles they have in their cellar.  They might want to open this list up only to certain people attending a wine dinner of some sort, but don't want to show just anyone visiting their child portal site.

4th Camp:  101 Variations of the 3rd camp!

Hey, stop "wine-ing" about DNN, get it... wine-ing, wine list, ha.... 

[insert sound of chirping crickets]

I think you nailed it as well.

camp 1 if most likely the majority of users which is probably why this functionality has not matured along with and at the same rat as the other features.

camp 2, I think I fit in here, I have a main site where I have public content and I sell portal space for a low amount to users who want an easy to use yet powerful portal where they can concentrate on there Game Group and not on web programming.

camp 3, I like this notion as well, I saw somewhere, may on this site a post on "MyDNN" where a user has custom tabs based on their login, similar to "my yahoo" or "my ebay". The single sign on, I think is really important for continuity. Users will be annoyed if they have to sign on to different parts of what amounts to the same site.

I think this module or set of modules is done right, it has the potential of being one of the most important modules available to the DNN community

Scott B. GameGroup.Org

I am in camp 2, a tailored hosting solution. Well for one of my "ventures".

I'm working on a process flow/screen design at the moment that I'll post up on this site tomorrow. This should address the majority of items raised in this thread.

It should be a very exciting enhancement (along with subscription tools) to dotnetnuke.

THe last few days I've spent clearing my schedule quite a bit to spend even more time on this site, so I've very excited!

Very cool.  I am camp two as well, except my membership base is the same for every portal, which kinda makes a third camp. :-) 

Let's go campin!  I'll bring the wine and women.

I like the idea of having a tab for each user, but that's actually not enough for my purposes.  Each user that wants it, will probably have a front page, a blog page, a gallery page, and then a page specific to all their wine info.

So my question, can an option be added in the Portal tools to "Use members from main site" for each child portal created?  

I'm in camp no.2 also, I think sbosarge has the right idea, but I would add the following:

* Have a simply skin gallery available for users to choose their default skin during signup. And/or generally have a skin gallery available on your site for users to browse through prior to registration on a new portal...

* An api/web service for the creation/suspension/deletion of portals via a 3rd party billing system. Also in
the api should be a premium module enabler/disabler - although the last time I checked, if you have access
to a a premium module, then you delete it and unsubscribe from the premium module, you can still undelete it from the recycle bin and use it without anyone knowing...

TJ

• Signup to create a portal
• Charge a fee
• Send notifications when portal is expiring
• Report on usage to both host and admin.

But for the management aspects, and like your site John, where you want your end users to participate accross all your portals (in forums, etc) without having to register on each portal (which would be a different username from the one they use on other portals).