I've developed a module with view and edit controls for a DNN portal site in which all pages in the site are configured to use a site-wide skin and container.

The container is properly applied to and displayed for the view control but not the edit control. Both view and edit controls function as designed.

Is this a known problem? Is there a way to assure that the selected container is applied to both the view and the edit control of the module?

Thanks.

Here are results from my "experiments":

Exp (1) Under Module Settings -> Page Settings -> Basic Settings -> Module Container: selecting a container does not work! and has no impact on module container for Edit Control

Exp (2) Page Management -> Advanced Settings -> Page Container: selecting a container does not work! and has no impact on module container for Edit Control

Exp (3) Site Settings -> Basic Settings -> Appearance -> Admin Container: selecting a container does work; now both View and Edit Controls of module display desired container

So these experiments confirm your remarks about Edit Controls of modules processed as Admin content. In my opinion, these inconsistencies in the user interface and programming logic need to be improved. Why provide the user interface controls relevant in Exp (1) and (2) if they do NOT work? Alternatively, why force all Edit Controls of any Module to be considered Admin content?

I have looked in both online documentation, and the Wrox textbook Pro DotNetNuke 4, and have not yet found clear and cogent discussion of interaction of security permissions (View/Edit) vis-a-vis Page permissions, Module permissions, Module control keys, and whether or not controls can be accessed with or without the relevant skin and container and/or display of the Control Panel. And of course, the Control Panel is displayed in its full form or limited form (Mode View Edit only) depending on whether the current user has Administrator privileges or not. Is anybody working on developing more transparent and cogent documentation for these matters? Such documentation is necessary to better understand what is design flaw and what is programming bug....

Meanwhile, in the scenario I'm interested in, I want registered users to have Edit access to the Module but not to the Page. I also want these registered users to have that Edit access by default without any display of the limited form of the Control Panel which adds an extra step (necessary to switch from View mode to Edit mode) just to get to add content in the Module. Documentation and discussion of these matters would be greatly helpful, but again I have not found anything in either *.pdf guides on DotNetNuke website or in the Wrox textbooks.

Ian,

Thanks for discussion. Let's hope the process will be better in DNN 5 Cambrian.

As a litmus-test code snippet to watch as an indicator, just keep an eye on the public shared function HasNecessaryPermission in the source file PortalSecurity.vb. This function has various overloads, but the most important one has Dim statements near the beginning of the function with very different patterns for the declarations for canViewModule and canEditModule. The lack of consistent use of a design pattern here, especially where it concerns security access, violates a programming philosophy which mandates consistency. Note that the cited code snippet does not necessarily have to be the source of the actual current problems. The point here is that it does provide an indicator of lack of use of consistency as a guiding design philosophy for matters as important as security access permissions.

If the underlying programming philosophy guiding design does not enforce or require consistency, then it is a "setup" for frustrating problems created elsewhere downstream as you commented for both developers and users. Fundamentally, whether at host, site, page, or module heirarchical levels, they are all just levels within a heirarchy of levels. But there shouldn't be different programming design patterns for the permissions of the different levels. Same is true for actions where, whether view or edit or any other action, they are all just actions which can be placed in a heirarchy of actions. But there shouldn't be different programming design patterns for the permissions of the different actions as is the current case where the design pattern is very different for canViewModule and canEditModule.

So when DNN 5 Cambrian is released, examine the code and judge whether the programming design patterns have been made consistent, or left as an inconsistent hodgepodge of different patterns.