Archive
Monthly
Go
|
|
DNN Blog
Apr
30
Posted by:
Shaun Walker
4/30/2006
I am very happy to announce that the DotNetNuke 3.3/4.1 release is now in full Stabilization phase. The initial Beta build ( 3.2.3 ) was released to Platinum Benefactors last Monday, April 24 and there has been a lot of valuable discussion and feedback in the private Release Discussion forum over the past week.
The purpose of providing early access to Platinum Benefactors was to allow for sufficient compatibility testing of complementary products and services, as well as to provide serious DotNetNuke vendors with the ability to get familiar with new features and enhancements which can be leveraged in their business as soon as the release goes public. Early indications seem to indicate that this program is a complete success.
A new Beta build ( 3.2.4 ) was released to the Platinum Benefactors yesterday. It contains defect corrections and minor enhancements to the previous Beta build and represents a "feature-complete" release package. Depending on the quantity/severity of defects identified, we expect that DotNetNuke 3.3/4.1 will be in Stabilization for a minimum of 4 weeks as we work with our partners to deliver the highest quality public offering.
There has not been a lot of detailed communication regarding the scope of the DotNetNuke 3.3/4.1 release, so I thought it might be useful to outline the various enhancements which have been introduced over the past 4 month development cycle.
More than 1000 individual transactions were recorded in the DotNetNuke_Core source code repository since Dec 22, 2005 ( the release date of DNN 3.2.2 ). The majority of the enhancements were focussed on the three major framework providers - Membership, Roles, and Profile. Since these providers are the underpinnings of any professional software application, we felt that a complete refactoring was in order to provide our community with the most powerful and extensible web application framework available.
Some of the more powerful core improvements are outlined below...
Membership
- Provider Abstraction - create our own provider to abstract ourselves from the Microsoft provider.
- HttpContext - eliminate dependence on HttpContext
- ApplicationName - manage our multi-portal capabilities within DNN rather than trying to hack the Microsoft provider
- Question and Answer - the ability for a user to enter and store a private question and answer which can be used for a password reminder
- Hashed Passwords - hashed passwords are supported through the Microsoft Membership Provider. We should provide a mechanism to support hashed password in DNN as they are much more secure then encrypted passwords and do not rely on MachineKeys. ( It would be advantageous to make this the default but the side effect would be that we would no longer have a password retrieval mechanism )
- CAPTCHA - add the ability to display a small image with embedded text which bots can not read. Prevents brute force dictionary login attacks.
- Public Registration - the system should send an email to the user on public registration ( to prevent cases where another user registers with their email address ).
- Profile Change Notification - when any profile attribute is changed, the owner of the account should be notified ( using the original email address ). This is to alert people in the event that an unauthorized user has gained access to their account and made changes to their profile ( password, email ).
- Login Redirect - after login there should b a way to send a user to a specific page. This could be implemented at the portal or user level.
- Password Generation - the ability for an admin to automatically generate a secure password for a user on account creation
- User Account Creation Notification - when an admin creates a user account they should have an option to send the account details to the user
- Force Profile Update - ability to force a user to update their user profile ( implemented at a granular level based on required Profile fields )
- Force Password Change - ability to force a user to change their password
- Password Complexity - add the ability to define some passord complexity requirements ( ie. mixed upper/lower case, numeric and alpha-numeric, etc... )
- Password Length - increase the default minimum password length from 4 characters ( will require a more secure host password on initial install )
- Password Expiry - a mechanism for expiring a password which would force a user to enter a new password. This could be done through password aging parameters defined at the portal level ( ie. every 2 months ). Would likely need to be associated with a reminder email to let people know their password was going to expire ( a similar requirement is needed for Role expiry ).
- Display Name Field - the membership schema should store the DisplayName of the user for demographic purposes - this item is critical for international users where their name is not represented as "FirstName LastName". Modules should link to the DisplayName for audit purposes rather than using FirstName and LastName.
- Preserve Login Parameters - when a user is directed to the login screen, the system needs to retain the original url ( with parameters ) so that it can redirect back after successful login ( especially useful in nested module UIs like Forum )
- Logout Behavior - after logging out, the user should be able to remain on the same page rather than being redirected to the home page ( the only reason they are being redirected now is because they may no longer have access to the page because of roles - but this is largely unnecessary and can be handled other ways ).
- Automated Verified Registration URL - the email sent to user when using he Verified Registration process now containa a URL which a user can click to very quickly validate their account
- User Lockout Notification - enhance the user lockout ( 3 unsuccessful logins ) to send an email to the admin to notify them of the event
- Manage Users UI Consistency - both users ( register.ascx ) and administrators ( manageuser.ascx ) should be able to manage the profile properties consistently.
Roles
- Provider Abstraction - create our own provider to abstract ourselves from the Microsoft provider.
- HttpContext - eliminate dependence on HttpContext
- ApplicationName - manage our multi-portal capabilities within DNN rather than trying to hack the Microsoft provider
- Effective Date - effective date is used to specify when a role becomes active ( we already have ExpiryDate which specifies when role access terminates )
- RSVP code - this is a code which can be assigned to a role which would allow a user to obtain access to thge role if they entered the RSVP value. A use case would be an administrator working with a group of users could send them an RSVP code which they could then enter on the site to get instant access, rather than the admin having to assign the users to roles manually.
- Avatar field - the administrator should be able to associate an avatar to a role.
- Role Groups - administration mechanism to group roles within the same portal to provide a faster, easier way to manage/assign them. This affects the Role Management, User Role management, and Permissions grids.
- Manage User Roles - once a site has more than 1000 users the user combobox, displayed when you access Manage User Roles from the Roles UI, contains too much data and sometimes times out. As a result there is no easy way to see the users who are assigned to a role ( the bottom portion of the UI ).
Profile
- Provider Abstraction - create our own provider to abstract ourselves from the Microsoft provider.
- HttpContext - eliminate dependence on HttpContext
- ApplicationName - manage our multi-portal capabilities within DNN rather than trying to hack the Microsoft provider
- Company Name Field - the default list of profile properties should contain the CompanyName of the user for demographic purposes
- Default Properties - In the default install we should provide a comprehensive collection of properties (consistent with W3C's Platform for Privacy http://www.w3.org/TR/P3P)
- Module Profile Properties - Modules should be able to add profile properties for module-specific information.
- Portal Properties - the Profile Properties should be defined at the Portal level (not the host level)
- Dynamic Definition - the Portal level properties should be managed by the Portal Administrator.
- Searchable - Profile Properties should be Searchable (ie we should be able to do Find Users By City or Find Users with Green Eyes)
- Profile Property Order - To support certain eastern cultures the order of Profile fields is important.
- Public/Private Data - the User should have the ability to specify which profile items are public vs. private. DNN should have the ability for anonymous users to link to a User Profile page and view public information.
Event Queue
- generic framework which allows managed code to create and consume custom events ( including parameters ). Events are persisted to the data store so they can survive app restarts.
File Management
- Storage Location - new Folder level specification to identify whether files should be stored on the file system ( unsecure ), file system ( secure ), or database ( secure ).
- File Manager - refactored to use the database as the source for file/folder information rather than the physical file system. Improved user interface to accomodate new Storage Location options as well as provide Synchronization at the folder level.
- File/Folder Association - added referential integrity between the Files and Folders table
- File Server - HTTP Handler for serving files regardless of Storage Location. Takes advantage of Folder permissions to ensure secure access to files.
- URLControl - leverage folder permissions and storage location in file selection and upload options.
Usability
- Copy Content - in Add Page, a new option which allows an admin to select a page and the granularly select the modules to copy as well as whether to make a New, Copy, or Reference.
- Page Template - template which defines a default set of modules to insert into the page when the page is added. The template is based on a portal template fragment and is currently defined at the host level. The default template provided contains a single HTML/Text module which helps address the usability issue of new portal administrators who do not understand that you need to add modules to your page once it is created.
- Host Space - increased host space capacity from 999.
- Module Title Editing - enabled AJAX-style editing of the Module Title by default
- ClientAPI - fixes and enhancements to ClientAPI javascript library as well as navigation controls ( ie. treeview, SolPartMenu, DNNMenu )
- Navigation Provider - fixes and enhancements to Navigation provider library
- AJAX - fixes and enhancements to DNN AJAX library
- URL Rewriter - adjusted logic so that full URL can be used in rewriter rules.
- Rich Text Editor - added support for URLControl in hyperlink popup so that a user can select from a file, page, or external URL. Also added Insert Smiley option.
- Newsletter - added ability to enter From: address.
Framework
- Remove dnn.config - the perceived performance benefit of the dnn.config was far outweighed by the support implications.
- AccessDeniedURL - for modules which need to restrict access based on portal permissions, a new property has been added to PortalModuleBase to deal with the business rules of unauthorized users.
- Module Actions - Moved ModuleActions from Container to PortalModuleBase for proper encapsulation of ModuleAction collection ( no longer dependent on the existence of an Actions skin object ). Allow custom module actions to be created as sub-items below the root.
- Permissions Grids - refactored to handle viewstate properly, allow extensibility for custom permission types, and eliminate errors related to rolenames containing embedded colons.
Data Access
- Generic Methods - new generic data access methods as part of core DataProvider. The purpose is to simplify DAL development for modules where a full Data Provider is not necessary. Detailed tutorial provides information on how they can be leveraged.
Performance
- Caching Code Pattern - code pattern for accessing the ASP.NET cache had the potential for threading issues. These issues were exposed on the ASP.NET 2.0 platform due to changes in the run-time model.
- Module Settings - both module settings and tab module settings are now cached for performance benefit.
Module Definitions
- Version - display the module version in the default Module Definitions view
- Interfaces - display module interface settings in the Edit Module Definitions UI and ensure the SupportedFeatures bits are set properly when updating.
- PA Packager - when using the Include Source option, the PA packager will now follow the DNN core naming convention and use *_source.zip as part of the filename for the source resource file.
- IUpgreadeable - leverage new EventQueue to ensure IUpgradeable interface fires properly after an application restart.
E-Commerce
- Subscriptions - new portal settings to manage PayPalIPN behavior.
- Text Banner - added support for a "display url" for text banners ( via the ImageURL property ). Also optimized the FindBanners stored procedure to exclude expired banners.
Design
- HTML Skins - skins created as HTML files can now include a section. The skin parsing engine will parse the content within the BODY tag when creating the ASCX skin file.
Please remember that there is still time to become a Platinum Benefactor and participate in the private Beta phase.
43 comment(s) so far...
Authentication
Thanks for the update.
I see a lot of changes to the membership. Has there been any testing or changes to the Authentication feature. I am currently using AD for automatic login and there is still an outstanding issue when a parent portal does not use Authetication and a child portal does. The portal messes up the cookies if they login to their child portal, visit the parent portal, and come back in.
By ccarns on
5/2/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
i've been checking the forums and blogs everyday hoping for an update.
thanks DNN Team!
By afromobile on
5/2/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Is this a breaking change.. or still exposed in same manner?
Module Actions - Moved ModuleActions from Container to PortalModuleBase for proper encapsulation of ModuleAction collection ( no longer dependent on the existence of an Actions skin object ). Allow custom module actions to be created as sub-items below the root.
By brian on
5/2/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Please make it easier to install.
By fungso on
5/3/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
First, let me say that all questions would receive more/better responses in the forums. But, I'll try to answer a few...
ccarns,
All features are currently, and have been, in beta for Platinum Benefactors to test. Any major bugs reported during this beta period (4-6 wks), especially those related to the updates, will be taken care of prior to the official release. Other pending bugs may or may not be handled depending on their priority and the availability of someone to champion the change. Your best bet is to ensure your comments are logged in Gemini. If you have the time and know-how to solve the problem, please include comments on a suggested resolution. This will ensure problems are resolved sooner - it's easier to implement a suggested fix rather than debug a complex problem and engineer the fix.
brian,
While I cannot guarrantee you this is 100% correct, I looked at the two classes and didn't notice anything that would break the code. Knowing more specifics would help determine exactly what might and might not break, tho. I suggest you post in the forums with more detail.
fungso,
If you have any specific suggestions on how we can make the install process easier, please submit them to Gemini. We are always open to suggestions and welcome them. With exact suggestions on exact features we can change - and even HOW to improve them - we can implement the changes easier and have updates to you, the community faster. Help us help you!
By flanakin on
5/3/2006
|
Thanks flanakin
flanakin,
Thanks for the response and suggestions. I have logged the issue in the public side of Gemini months ago, but there are so many issues in there (some real some not) it like a needle in a haystack. I have also tried the forums but is hard to get the attention of some one who knows enough since most users dont use the AUTH portion. I realize TAM is very busy and I dont know enough about AD to help.
fungso
I dont know how much easier they can make it. It is way easier to install DNN then most any other web application out there.
By ccarns on
5/3/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
brian
The changes to ModuleActions are the following:
1. To enable sub-menu items to be created by module-developers. The current code allows the items to be added in the Actions property, but they are never "copied" to the ActionBase skin object (ie the Actions menu)
2. To break the dependency of an ActionButton on the presence of an Actions Menu. Again this was a bug. The actions menu should not need to be present.
In order to accomplish these features the code was refactored, as shaun described, moving all of the building of the Actions collection to the PortalModuleBase base-class (where it should have been in the first place).
Having said that from a Module Developers point of view this is not a breaking change - but a bug-fix. There may, however, be a slight behavior change. I cannot guarantee that the Action Items added in a module will neccessarily display in the same order as they used to.
By cnurse on
5/3/2006
|
Issue reposted
Flanakin
After telling you I inserted into Gemini months ago I tried to relocate it there and had no luck (maybe they did some house keeping). So I reposted it. If anyone is interested in the issue visit the post here: http://support.dotnetnuke.com/Default.aspx?p=23&i=2910
By ccarns on
5/3/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Thanks for all your dedication and hard work.
By tmaler on
5/3/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Thanks Shaun for all the excellent work. One question, will www.dotnetnuke.com be dogfooding on 3.3 now or will it go 4.1 way ?
By nigam on
5/3/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
"Preserve Login Parameters" is the feature I've been waiting for. Thank you DNN team.
By zmariow on
5/4/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Good news indeed.
Is it possible to download the new versions somewhere? I would like to test if my problems with 4.0 were solved...
By microworks on
5/4/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Impressive work, thanks to all the team members!
Does anyone know if these issues are solved?
#1 http://dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/105/threadid/34791/scope/posts/Default.aspx
#2 http://dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/108/threadid/33217/scope/posts/Default.aspx
Feature request:
I miss the oportunity to copy/past one module with or without content. For example users often build UDTs and want’s to resuse them for groups of data.
Thanks ArntK
By ArntK on
5/5/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
brian: The change to module actions is not a breaking change but it does have an impact on framework behavior. In the past there was a bug which resulted in the module actions being displayed in the reverse order from which they were defined in the module. This bug has been fixed, but it means that modules may need to reorder their module action definitions.
nigam: The plan is to dogfood dotnetnuke.com on version 4.1.0 ( ASP.NET 2.0 ).
microworks: As noted in my blog entry above, the release can only be downloaded by Platinum Benefactors at this point in time. A public release will be announced in the coming weeks.
ArntK: Your performance issue with Folders is likely solved by the extensive overhaul of Folder/File management. The sychronization noted in the thread is solved by allowing an admin to sychronize a specific folder. The feature request should be directed to the UDT team.
By sbwalker on
5/5/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
I'm beyond thrilled. If it wouldn't kill me, I'd stay up till this was released to public!
By Dkingsley on
5/5/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
when can implement user level personalizaiton?
By basso on
5/6/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status : Data Access
" The purpose is to simplify DAL development for modules where a full Data Provider is not necessary"
I am dying to see some tutorials/examples so that I can code my modules in such a way that there is no DataProvider in my Module, but uses only the core DataProvider. That way anyone who is having the Core DataProvider of his choice (Firebird or MySql ...) would be able to use my modules without them doing anything extra :P
By Jaydeep on
5/6/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Mr. Walker two bugs related with TR locale.. One with File Manager another with FTB provider...
Mr.Daskaya found the solution for these two bugs can u include the fixes at next release?
By greenflash on
5/7/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Theres a lot of mention in Shaun's list of "profile properties". Am I right in thinking in 3.3/4.1 it will now be possible to add custom fields to user profiles? Have I missed something or is this a brand new feature, in which case this is huge!
By lneville on
5/8/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
I found the answer to my own question - its all under Charles Nurse's blog:
http://www.dotnetnuke.com/Community/Blogs/tabid/825/BlogID/15/Default.aspx
By lneville on
5/8/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
All I can say is "Wow". These changes are going to have huge effect on the way I run my intranet, and all for the better. This is a major milestone for DNN!
By ech01 on
5/9/2006
|
DotNetNuke 3.3 / 4.1 Release Status
The changes to version 4.1 look great, specially the ones related to the database file storage option. This change will reallly enhance the security of the Portal files. Are there any plans to add a "Portal Backup" module that would allow downloading the Portal's data to an XML file or a similar approach? When a server is used to host many Portals, if one of them gets accidentally modified or deleted, there seems to be no way of recovering the information except restoring the entire database to a temporary website and rebuilding the damaged or deleted Portal. Are there other options in the plans for future versions?
By CarlosIsaza on
5/9/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
I think there should be another level added to the benefactor program asap. There is a need for organisations who are not for profit, or government etc who rely on DNN for core systems and would benefit greatly from having access to beta releases, but have no need for regognition or advertising (or a tshirt for that matter).
By orenpv on
5/12/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Does anybody knows the release data of the 4.1 version ?
By hkgartner on
5/14/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Quote: "- URLControl - leverage folder permissions and storage location in file selection and upload options."
Does it mean that a file will be associated to permisions when is is tried to be downloaded through an url request?.
By davidllamas on
5/15/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Sean: It looks as if DotNetNuke has gone full circle with the MemberRole provider. My question is, will DotNetNuke once again support Single Sign-On as DNN 2.x did (A Users Table, A UserPortals Table, a Roles Table and and UserRoles table) such that a single user may exist in multiple child portals.
This use case was discussed extensively on the old forums http://forums.asp.net/90/ShowForum.aspx specifically with regard to sites such as Schools & Churches. Both types of sites have an inbuilt large user base which potentially need numerous sub-portals for such things as Committee Sites, Class Sites, Student Sites, etc, while still maintaining a common user base. Maintaining separate user accounts for each subportal a user visits is simply unmanageable: for example a small church web site with 120 users, a separate subdomain for each committee and class may quickly be managing hundreds, if not thousands, of user logins.
Separately, a school site wanting to use something like the now dead DNNElearn face even greater hurtles: a small school of say 300 students and 40-50 classes, each student in seven classes, maybe the teachers have their own subportals too, the number of users quickly becomes unmanagable.
I have been eagerly awaiting the 3.3 release to check this out on my own, however, as this blog entry is three weeks old, I am assuming it will be some time before 3.3 is released to the community.
In any event, thanks for all your great work.
http://forums.asp.net/thread/906677.aspx
By kennster on
5/15/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Really good news.. Hooray .. for all the brave teams!!
By clody on
5/15/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Hi Shaun,
This is really great!
Is there a document that outlines and explains the architecture of DotNetNuke? I have learnt it by experience, tyring to get some teams trained on it, so wanted to know if something is readily available.
Thanks
-Neeraj
By nvkulkarni on
5/16/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Hi,
what I'm really missing is an Interface that is called after the installation of a module has passed (either sucessfully or not)! (eg. an enhancement to IUpgradebale or a new Interface IInstallable).
IUpgradeable does currently only fire if you have a SQL-Providerscript. Some of my modules, do not have own database-structures or DAL's but however do need initial configuration/installation. There is currently no way for me to fire this than adding a dummy Sql-Script to the Module and abusing IUpgradeable :(
Any chance to see something like this soon?
-connex
By connex on
5/17/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
I'd like to see a footer/header in the newsletter that you can set for all outgoing messages.
How close are we to setting a release date. I'm currently on 3.1 and want to upgrade but don't see the sense if 3.3/4.1 is coming out soon.
By acorndiggity on
5/17/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
well, he did say on 4/29 a minimum of 4 weeks.. so on 6/1, maybe you can ask where is it! :)
By brian on
5/22/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
i didn't ask if it was available now. . . i wanted to know if a release date was set yet. a minimum of 4 weeks could mean 2 years from now. If you want to be a jacka ss why don't you do it somewhere else?
By acorndiggity on
5/22/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
acorndiggity : i've already do this, i've done a simple modification which allow admins to choose templates for headers and footer when your want to send newsletter. A second time of dev will allow to edit and create header or footer templates. For more, a simple system of content templates (modifyable for sure) can be implemented easily.
Please come on www.takethewave.net to contact me about this, and i send you my code. It's for 4.0.x ;)
Sébastien
By Sébastien on
5/23/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Any idea on the real release date?
By simonech on
5/29/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Ditto on the release date question. Have some projects I would like to schedule around the new release. Thanks.
By lmtsypin on
5/30/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Any chance that the changes to the FileManager will remove the 2GB limit imposed on Portal directories by the UpdateSpaceUsed function? I've seen no mention of this either in this announcement, nor in the bug reports for the last release. I'm using 3.2.2, and it sounds as though this has been encountered by others based on the following entry in the Forums:
http://dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/110/threadid/22377/scope/posts/Default.aspx
Thanks for all the great work, and I hope this made it in.
By Ed Sitler on
5/31/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Hmmm. June 5, 2006.
Here 4.1, 4.1, 4.1! Here 4.1!
(Looks around.)
Darn. I thought it would be here by now.
By Wendy on
6/5/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
Ok maybe I'm old, out of touch, but what does the term dogfood or dogfooding.
nigam had asked:will www.dotnetnuke.com be dogfooding on 3.3 now or will it go 4.1 way ?
and then sbwalker replied: The plan is to dogfood dotnetnuke.com on version 4.1.0 ( ASP.NET 2.0 ).
Please give me some lamen terms.
Thanks
By jeffsantos on
6/6/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
If there a fix for sending passwords, after an upgrade my customers can not retreive their passwords since I have upgraded from dnn2.1.2 to dnn3.2.2?
By angelavig on
6/7/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
I looked through the list and didn't see anything that releated to this, but then again, I've only had two cups of coffee this morning. Nevertheless, I was wondering if 4.1 would have a switch that would allow new members to have access to all portals on a DNN site, rather than having to register for each? (Then the admin could restrict users based on roles)
Thanks,
By twisterjosh on
6/12/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
If there a fix for sending passwords --> I suggest putting this in the forums as this is not a bug.
switch that would allow new members to have access to all portals on a DNN site --> better known as sso (single sign-on). I asked and the answer is not in this coming version.
any updates on the testing?
By brian on
6/12/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
jeffsantos: see this link http://en.wikipedia.org/wiki/Dogfooding
basically, it means "Not only is the product (e.g., software) good for my customers, but it is good for me as well."
By jyjohnson on
6/13/2006
|
Re: DotNetNuke 3.3 / 4.1 Release Status
what is the difference between 4.9.0 and 5.0.1
By durga12345 on
7/5/2010
|
|