?? Setting to allow/deny editing of module settings

[crnogorac081]

Hi,

I was wondering is it planed in some further version that in Advanced Group Settings can be checked option that the group can access module settings in Pages.

It would be a new variable like $allow_edit_settings  (for example if checked { show button for accessing settings} )  so it will be used as new standard for module coders..

For example I want to ban certain groups to access Settings options in news module, members module etc.. I want to let them just to edit posts and not to change settings..

(or maybe something like this already exist and I missed it, or there is some work around)
What do you think ?

cheers
I
 

[Stefek]

Hello Crnogorac,

Here is a complete solution for you:
http://www.websitebaker2.org/forum/index.php/topic,15540.msg100480.html#msg100480

 
Stefek

[erpe]

Has someone opened a feature ticket for this?

Seems to be an interesting solution.
Or soemthing similar to droplets, that only admin can edit the settings?

rgds

erpe

[doc]

Hi,

if I remember right, some modules available in the forum use WB authentification to allow certain settings etc. only for the admin group. So nothing new about it. Maybe add the code linked to the module section on the WB help project or tutorial so module authors become aware of this kind of option.

Regards doc

[crnogorac081]

@ Stefek

Great, it is a nice workaround. But, now I would need to edit all modules I am using to enable this feature

@ Doc

Yes, and this code which Stefek pointed me works only for group 1. I was thinking more that this become a standard in Group advanced settings.

For example, instead of one checkbox in module access at the bottom of advanced group settings page to have 2 checkboxes, like:

Module access:

WYSIWYG: ⊗ View/edit     o Manage Settings     <--- Only edit content
News:        ⊗ View/edit     ⊗ Manage Settings    <---- Both view/edit and edit settings
Code:         o View/edit      o Manage sections     <---- No access

And so on..

@ Erpe

I will write a ticket, if community thinks it would be useful for further development of WB.

Cheers

[Stefek]

Hello Ivan,
I am going the easy way while setting up the modules for customers.

I open the backend.css and write a new css rule into it like:

.adminonly { display:none; }

Then I open the modify.php of this module and look for the areas I don't want them to see, pick them up and add class="adminonly" to this areas (buttons, divs, whatever).

That's it.
While working in this backend, I can always disable this css rule like:
/* .adminonly { display:none; } */

This goes very fast, also if I need to upgrade a module, I can make this changes in means of minutes.

A better way would be to add this lines into your modify.php :

Code:

<?php 
if ($_SESSION['GROUP_ID'] == 0) {
$classvisible = "";
} 
else {
$classvisible = 'class="adminonly'";
}?>

then look up for the areas you do not want to show and add <?php echo $classvisible ;?> to them.
This way you dont need to open the backend.css file anytime you want to work whith this module yourself.

For example, instead of one checkbox in module access at the bottom of advanced group settings page to have 2 checkboxes, like:

Module access:

WYSIWYG: ⊗ View/edit     o Manage Settings     <--- Only edit content
News:         ⊗ View/edit     ⊗ Manage Settings    <---- Both view/edit and edit settings
Code:         o View/edit      o Manage sections     <---- No access

And so on..

This would be nice for future versions, but it would mean that only modules enabled with this technique would provide this option via the group access settings. But in fact a nice if this feature would be documented here:

Maybe add the code linked to the module section on the WB help project or tutorial so module authors become aware of this kind of option.

... so module developers could follow the "how to" (a working solution) to enable this feature in their modules (or a team would do).

Kind regards,
Stefek

[crnogorac081]

Yes, it would be nice to make it standard, and also to make guide lines for further module development.

cheers