Having a next user level besides mobile user

[Dean211]

[COLOR=#1f497d][FONT=Calibri]Having an additional user level would be useful. Say a user level where you can do everything but configure the server would be very useful for our school district.[/FONT][/COLOR]

[stark325]

Thanks for the update on this Tom

[Tom Elliott]

I doubt it will be ready for 0.33, but I’ve started adding the checking needed for it to work. So it should just be a minor addition of rbac style controls whether built directly into the files, or you can setup from the database.

[stark325]

@Tom

Any chance this will be in 0.33 or are we realistically looking at 0.34.

Thanks for all the hard work.

[Tom Elliott]

I’m working to try implementing it, but I don’t know what other changes need to be made as everything is class base. If my understanding of this is correct, essentially the only things that are changed are visible menu options based on the User level, but this doesn’t mean somebody couldn’t make the changes correct?

[Dave Smith]

Any chance this could be put into 0.33 or even 0.34

[Daëavelwyn]

Dude man, you just save me so much time ! Really thanks for the code and for your comments about, it really, really helps me

[Fernando Gietz]

Hi, syschuck.
The code that you can find in [URL=‘http://www.ehu.es/fogenehu’]www.ehu.es/fogenehu [/URL]is actually in Production, and is the code that we are using now. But is obsolete, is based on FOG 0.30, and have a limited support to W7. You can use it to see how is developed the different users levels.

User.class.php
[PHP]
class [URL=‘http://www.ehu.es/fogenehu/doc/html/class_user.html’]User[/URL]
{
private $strUserName, $strAuthIP, $strTime, $strType, $strPass, $strLanguage;
private $intID, $strIdentity;

const TYPE_MOBILE = ‘0’;
const TYPE_ADMIN = ‘1’;
const TYPE_GESTOR= ‘2’;

function __construct($id, $username, $authIp, $authTime, $type, $identity)
{
$this->intID = $id;
$this->strUserName = $username;
$this->strAuthIP = $authIp;
$this->strTime = $authTime;
$this->strType = $type;
$this->strPass = null;
$this->strIdentity = $identity;
$this->strLanguage = null;
}

And more…[/PHP]

During login process [See management/includes/processlogin.include.php code*], you obtain a User object with the user rol [MOBILE, ADMIN and the new one GESTOR]. With this value you can filter the access, for example: We filter the access to some menus, the ADMIN rol can see the storage node configuration or Profile menu but a GESTOR rol can’t access to it [See management/include/mainmenu.include.php].

[CODE]
<a href="?node=" class=“home menu_button” alt="<?php echo((“home”)); ?>" title="<?php echo((“home”)); ?>"></a>
<a href="?node=users" class=“users menu_button” alt="<?php echo((“users”)); ?>" title="<?php echo((“users”)); ?>"></a>
<?php
if ( $currentUser->getType() == User::TYPE_GESTOR )
echo ( “<a href=’?node=profiles&sub=list’ class=‘profiles menu_button’ alt=‘centros’ title=‘centros’></a>” );
?>
<a href="?node=host" class=“host menu_button” alt="<?php echo((“hosts”)); ?>" title="<?php echo((“hosts”)); ?>"></a>
<a href="?node=group" class=“group menu_button” alt="<?php echo((“group”)); ?>" title="<?php echo((“group”)); ?>"></a>
<a href="?node=images" class=“images menu_button” alt="<?php echo((“images”)); ?>" title="<?php echo((“images”)); ?>" ></a>
<?php
if ( $currentUser->getType() == User::TYPE_GESTOR )
echo ( “<a href=”?node=storage" class=“storage menu_button” alt=’".(“storage”)."’ title=’".(“storage”)."’ ></a>" );
?>[/CODE]

[*] You can see in the code the ldap validation support

[syschuck]

Thank you very much for the information Fernando. What you are doing looks very close to what I need. I’m going to give your version a test and see what it looks like but the addition of profiles (for departments or buildings) seems very logical and could map well to what I’m doing. I started using 0.33b because of it’s support for windows 8 but I’ll give your version a try.

[Fernando Gietz]

The changes are a lot of, but you need:

*Create some tables in DB: Profiles and ProfileMembers. Those tables contain the infomation about the Profile (profile as departament or building, not as a rol) and the relationship between the users and those Profiles.
*Add a new atribute in Group table: the profileID.

The relationships are those:
Users <–> ProfileMembers <–> Profiles <–> Groups <–> GroupMembers <–> Hosts

Our image names have a pattern: groupName-service
Where service is or “docencia” or “otros”. For example: aula-bz-ciencias-AI1-docencia, the group name is aula-bz-ciencias-AI1 and the service, docencia.
Thus when you need filter the access to one image you use the group name:
Select * from images where imageName like ‘Your_Group_Name’

We do in this way to not make a new relationship between Profiles and Images:
Users <–> ProfileMembers <–> Profiles <–>ImagesAssoc <–> Images

• Add a new atribute in the users table. You need the user rol : mobile, technician and admin.
• Modificate the User Class to add this rols

You can see info in [URL=‘http://www.ehu.es/fogenehu’]www.ehu.es/fogenehu[/URL] and the code is in [url]http://www.ehu.es/fogenehu/doc/html/index.html[/url] (this doxygen doc is actually obsolete)

[syschuck]

[quote=“Daëavelwyn, post: 10724, member: 3269”]@Fernando Gietz
Hi, i’m using fog 0.32 and want to use such a feature, could you please post your modified files to do this ?[/quote]

I want to Third that motion! I could really really use that feature now. I would like the person that logs in, to only see hosts and images that she/he creates. I’m a php coder if you want to share your changes.

[Kevin]

This has been brought up in the past. I don’t think .33 is going to have any other user groups besides a reworking of the mobile interface. With .33 being a complete re-write, time will tell what would need to be changed to allow this. At this point we need to wait for .33 to be released before we can look at different access groups.

[Daëavelwyn]

@Fernando Gietz
Hi, i’m using fog 0.32 and want to use such a feature, could you please post your modified files to do this ?

[Fernando Gietz]

This idea is really useful. We have modificated the fog code to make this (we use fog 0.30). We use one only FOG server to deploy images in the different high schools. We have 40~50 technician in the different high schools. Those technicians access to the WEBUI in this new role, they can only see his High school images and not other ones.

[falko]

yes this would be a nice addition

[steve]

This is a good idea.

[Devlin7]

I second this. I would like for the helpdesk to be able to deploy images and and snapins but not muck with anything important