Hi

According to the website:

DotNetNuke 4.1.0 ( for ASP.NET 2.0 ) is targeted for beta release to Platinum Benefactors in the first quarter of 2006. The beta release will go through a minumum 4 week stabilization period before it is released to the general public.

Are there any further updates on this? (could it be weeks, months?).

I'm wondering whether to hold back the release date of my websites, seems little point in releasing them and then upgrading the framework a few weeks later. I'd rather hold back if this is to be the case.

Cheers

Alex

Absolutely, I'd much rather wait for a stabler version.
Do you think it will be over 2 months or 1 to 2 months?

Ta

Alex

Cathal: Maybe you can answer this question: I have repeatedly asked this in the forums and in Nina's & S.B.'s blogs with no response:

Will the new Membership provider enable a single user to exist in multiple portals?

This was one of the 'killer app' features of DNN 1 & 2, being able to log on to a root portal, and navigating seamlessly to child portals.

There has been endless debate about this since DNN 3.x was released (with me noting sardonically that it appeared an 'inside job' by M$: Hold you friends close, Hold your Enemies Closer: with a mature, sophisticated application framework that supported a single sign-on, it competed to closely to MCMS & WSS/SPS). I realize that argument was moot: but I have been unable to do anything of any great merit with any later version of DNN than 2.1.2, because I simply don't trust having to manage multiple identical accounts in a system that didn't permit normal SQL access. There are (at least) two professionally developed modules on Snowcovered which do this, but the general tone of the discussion in the old asp.net forums led me to not trust these solutions.

I have noted that the new membership provider will no longer use the text/blob field approach to storing membership properties, but instead store a single row for each property stored: couldn't agree with those that wrote this more. I had to write a custom search engine for users a while back, and the only way to do it was to write two custom functions and another custom view to bring back the desired fields, and at that, was read only. What sense does it make that the company that writes one of the most popular database products out there would then 'help' an open source project by making one it's core features (membership management) closed source, proprietary format?

Back to my question: Will the new Membership provider enable a single user to exist in multiple portals?

Plus, even since the membership provider/DNN 3.x has been released there have been all sorts of issues reported about the fact that a single user name could only exist once across all portals because of the 'legacy' users table. I don't know if this was ever resolved, but there are other similar issues with regard to the old system's limitations rearing it's ugly head.

For the record: why would it be good to have a single user exist in multiple portals?

1. I have a customer that is a small secular private day school  (www.wellingtonschool.com): I would like nothing more than to do the following:
1. Give each teacher her own portal.
2. Give each club it's own portal
3. Give each campus it's own portal
4. Give Each class it's own portal
5. Give the school office and business office their own portals.
6. Enable each group or activity the ability to log on to the main web site, and get a list of the sub portals they are members of (I can do this in DNN 2.1.2, and give the module away freely on my web site).
7. Enable each group or activity the ability to maintain their own page or pages on the main web site.
8. Only have to manage one account per user.
2. A Church:
1. Give each Committee or Group their own portal.
2. Give each their own portal.
3. Give each class their own portal.
4. Give the Church office it's own portal.
5. Enable each group or activity the ability to log on to the main web site, and get a list of the sub portals they are members of.
6. Enable each group or activity the ability to maintain their own page or pages on the main web site.
7. Only have to manage one account per user.