Having a next user level besides mobile user
-
[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]
-
Thanks for the update on this Tom
-
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.
-
Any chance this will be in 0.33 or are we realistically looking at 0.34.
Thanks for all the hard work.
-
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?
-
Any chance this could be put into 0.33 or even 0.34
-
Dude man, you just save me so much time ! Really thanks for the code and for your comments about, it really, really helps me
-
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
-
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.
-
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 <ā> HostsOur 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)
-
[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.
-
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.
-
@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 ? -
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.
-
yes this would be a nice addition
-
This is a good idea.
-
I second this. I would like for the helpdesk to be able to deploy images and and snapins but not muck with anything important