Archive
Monthly
Go
|
|
DNN Blog
Jan
2
Posted by:
Charles Nurse
1/2/2008
In the keynote at OpenForce, Shaun mentioned that the next version of DotNetNuke (codenamed "Cambrian") would contain an improved Admin experience.
As part of the preparation for this I have been working on removing the differences between "Admin" modules and pages and "Standard" modules and pages.
There are two major components of this re-Architecture.
- Remove the artificial difference(s) between Admin and Standard pages. There are four major components of this:
- Admin pages will no longer be required to be a child of the top-level "Admin" menu
- Admin page access will be controlled by the standard Page permission model, thus allowing Admin users the ability to delegate administrative tasks to other "Power" users, for example a "User Account Manager" role.
- Remove the artificial notion of an Admin Skin and a Portal Skin.
- Remove the artificial restrictions on Admin Pages so they can contain a mix of Normal and Admin modules.
- Remove the artificial difference(s) between Admin and Standard modules, so that all modules - admin and standard - will behave the same way.
While, these changes, do not themselves create an improved Admin experience, they do introduce more flexibility in the framework. For example, with these changes:
- Module Developers will be able to build their own versions of Admin modules, and have a fully supported way to install them and add them to pages.
- Portal Administartors will be able to place admin modules on any page, possibily with other modules, to improve the usability for their site.
13 comment(s) so far...
Re: Cambrian - Admin Modules
Is there any way that we could also start adding the infrastructure to DNN that would allow it to be administered through web services?
This could be used in an automated build process to query a DEV instance of DNN and then migrate any changes to a QA site and then eventually migrate them to a running production instance of DNN.
Either CruiseControl.Net or Team Foundation Server could be used to automate these transitions.
By juchytil on
1/2/2008
|
Re: Cambrian - Admin Modules
Very cool. Looking forward to it :>
Richard
By rbinnington on
1/2/2008
|
Re: Cambrian - Admin Modules
I like this but I am curious, will we also be able to designate what modules - of any type - can be seen by a user with page edit permissions?
By boblpope on
1/3/2008
|
Re: Cambrian - Admin Modules
Do you mean the module select list? This is a good question.
By cshark on
1/3/2008
|
Re: Cambrian - Admin Modules
Yes - that is the plan - it would not be appropriate for anybody to be able to add a User Accounts module to any page - even if they have permission on that page.
By cnurse on
1/3/2008
|
Re: Cambrian - Admin Modules
Up until now, when you visit an "Edit" or "Admin" control in a module (e.g. choose Settings or View Options in module menu), or visit an Admin or Host page, the page is rendered with an Admin Skin. The page also only displays the current module which can be frustrating, e.g. if the site's navigation menus are modules then these are not available.
In Cambrian will this phenomena go away?
2nd question - will you make it impossible for a site to get completely hosed, e.g. by an administrator deleting the User Accounts module from all pages and also removing all roles' (including themselves) permission to re-add the module?
By lneville on
1/4/2008
|
Re: Cambrian - Admin Modules
It should be an administrator's right to completely hose their site by removing all User Account modules. :) But it looks like the progression of permissions to these pages will allow a host admin to lock at least one page from a site admin removing the module. That would save me a lot of headaches. The ability to aggregate specific admin modules to a page and delegate those tasks to a subordinate would also make my life much easier. Thanks for the preview.
By jeff@zina.com on
1/4/2008
|
Re: Cambrian - Admin Modules
Ineville - To answer your first question - the main goal of this change just deals with the Admin Pages (not a modules "Edit" pages) - so the answer is this behaviour will still exist as pat of this feature. It is still up in the air - whether we will change the behaviour of the "ctl=xxx" pages.
By cnurse on
1/4/2008
|
Re: Cambrian - Admin Modules
Charles - thanks, understood. I hope the module "Edit" pages do stop doing this in future. Its a minor annoyance from a user perspective and tricky for a module developer to work around (at least the last time I tried).
By lneville on
1/8/2008
|
Re: Cambrian - Admin Modules
This is crucial functionality we've been looking for. I am wondering, will this be part of the initial Cambrian release scheduled for the end of the first quarter?
Thanks!
By chelene on
1/29/2008
|
Re: Cambrian - Admin Modules
Charles - Will there be protection put in place to avoid the ability to "un-install" core modules, such as user accounts etc? Or will they just not show in Module Definitions like they do today?
By mitchel.sellers@gmail.com on
2/27/2008
|
Re: Cambrian - Admin Modules
This sounds like an excellent idea, any idea which quarter this is likely to be released on?
By bitpail on
2/27/2008
|
Re: Cambrian - Admin Modules
Will the styles for each feature be implemented through Module.css files? Ideally, default.css shouldn't come with a ton of imposing styles.
Just my $.02.
By swift51 on
2/29/2008
|
|