Hide/disable editing of extra fields on JMapMyLDAP

[BluWeb]

Hi!
The configuration that I am using is LDAP - Profile, with Profile enabled, which loads a custom XML file. This is a JMapMyLDAP propretary configuration, of course.

Let's say that I have users in Group "A" and Group "B", just to make it easy to illustrate.

I am trying to hide the user profile extra fields from Group "A". In the other hand, Group "B" could see these fields but could not edit them.

After searching a lot, I ended up with some possible solutions:

1 - Disable the fields, or make them readonly, in the custom XML file. It could work for the Group "B" case, but it wouldn't hide them from Group "A". Another problem is that I could not edit these fields in the backend either;

2 - Have two fieldsets, one with editable fields (that would be hidden in the frontend for the two groups) and another with readonly attribute (visible for Group "B" only). But then it would create extra information in the DB, not to mention the fact that it doesn't load the class assigned in the XML file so I could control when it would be visible.

3 - Talking about the class... I tried to create a class for the fieldset and set the fieldset class to "display: none" based on the menu class. The problem is that the fieldset doesn't load the class set in the custom XML file, actually it just loads the pure fieldset, without any other attribute. So, it is impossible to hide just this fieldset block.
I tried to do this in my custom XML file:

Code: Select all

	<fieldset 
	    name="personal"
	    label="PLG_LDAP_PROFILE_FIELDSET_PERSONAL_LABEL" 
		class="class_for_the_fieldset">.... and so on....

It loads something like this in the frontend profile edit:

Code: Select all

<fieldset>
  <legend>SOME HEADER OR SOMETHING</legend>
  <div class="control-group">
  ::before
  <div class="control-label">.... an so on

But I would need something like this:

Code: Select all

<fieldset  class="class_for_the_fieldset">
  <legend>SOME HEADER OR SOMETHING</legend>
  <div class="control-group">
  ::before
  <div class="control-label">.... an so on

So, I could add this to my CSS:

Code: Select all

.menu_class_for_group_A .class_for_the_fieldset {
display: none;
}

But, even if it worked, it wouldn't work for Group "B", because the fields would still be editable.

4 - Give the LDAP - Profile plugin access rights to Group "B" only. Now this brings two issues:

1 - LDAP - Profile plugin doesn't sync data from Active Directory when the user logs in, even if the user belongs to Group "B". It just syncs when "Public" access is set;
2 - I still could not deny editing.

As you can see, I am in a complicated situation and after all this, any suggestion would be much appreciated.

Here's the specs:
Joomla 3.9.1;
JMapMyLDAP 2.0.3.1

If you need any other information, please let me know.

Thanks for any help

[BluWeb]

Well, thanks for anyone who tried to help. Really appreciated.

I'll try to explain it in a way that I would like to have when searching for such a thing like this.

The solution was in the way that nested elements work.

First we need to understand how a nested element works (the most practical way. I am doing my best to explain, I am not very good with words, sorry).

In this case, the element in question is <fieldset>.

The custom XML file, with extra fields information, has two fieldsets, but the Profile Page is loaded bringing one more fieldset element, the one with the main profile information. The main Profile information will be available for both: internal users and customers.
Let's see how:

PROFILE PAGE PARTIAL CODE:

Code: Select all

<form id="member-profile" class="form-validate form-horizontal well" action="/forms/customers-profile?task=profile.save" method="post" enctype="multipart/form-data">...event...
<fieldset>...</fieldset>
<fieldset>...</fieldset>
<fieldset>...</fieldset>
<div class="...... the code continues

The second and third fieldsets occurences are the ones from my custom XML.
This is how a nested fieldset happens, in this case.

The CSS for nested elements is:

element:nth-child(number of the occurence)

So, if we want to change the color attribute for the second fieldset occurence, the command would be:

Code: Select all

fieldset:nth-child(2) {
color: red;
}

Now I can control which fieldset block will be available.

In the Joomla menu manager, I've created two menu items:
1 - Internal Users Edit Profile:
- Set the "page class", in "page display" with " internal_users_menu" value;
- Set access level to Local Users Access Level policy.
2 - Customers Edit Profile:
- Set the "page class", in "page display" with " customer_menu" value;
- Set access level to Customers Access Level policy.

This is how I can control what will happen when each menu item is accessed by the users.

CUSTOM EXTRA FIELDS XML FILE

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<form>
    <fields name="ldap_profile">
	<fieldset 
	    name="personal"
	    label="PLG_LDAP_PROFILE_FIELDSET_PERSONAL_LABEL" 
		id="personal" 
		>
	    <field
		name="homePhone"
		type="text"
		description="PLG_LDAP_PROFILE_FIELD_RG_DESC"
		label="PLG_LDAP_PROFILE_FIELD_RG_LABEL"
		size="30"
		required="false"
		readonly="false"
		sync="true"
	    />
	    <field
		name="pager"
		type="text"
		description="PLG_LDAP_PROFILE_FIELD_CPF_DESC"
		label="PLG_LDAP_PROFILE_FIELD_CPF_LABEL"
		size="30"
		required="false"
		readonly="false"
		sync="true"
	    />
    </fieldset>
	<fieldset name="personal_read_only"
	    label="PLG_LDAP_PROFILE_FIELDSET_PERSONAL_LABEL" 
	>
	    <field
		name="homePhone"
		type="text"
		description="PLG_LDAP_PROFILE_FIELD_RG_DESC"
		label="PLG_LDAP_PROFILE_FIELD_RG_LABEL"
		size="30"
		readonly="true"
		sync="true"
	    />
	    <field
		name="pager"
		type="text"
		description="PLG_LDAP_PROFILE_FIELD_CPF_DESC"
		label="PLG_LDAP_PROFILE_FIELD_CPF_LABEL"
		size="30"
		readonly="true"
		sync="true"
	    />
    </fieldset>	
   </fields>
</form>

As you can see, there are two fieldsets, one that will be editable and another one that will be readonly.
The editable part of the XML will be used in the backend, so administrators will be able to update these fields.
The readonly block will be available to internal users only.
Customers will never see any of these additional fields.

I also had to hide some fields from internal users and all fields from customers in the Profile view page. This page has a buttom to Edit the profile.

CSS TO CONTROL THE VIEWING:

Code: Select all

 
/* hides the editable fieldset from internal users in the edit Profile page*/
.internal_users_menu div.profile-edit #member-profile fieldset:nth-child(2),

/* hides the editable fieldset from internal users in the view Profile page*/
.internal_users_menu .users-profile-custom-personal legend, 
.internal_users_menu .users-profile-custom-personal dl, 
.internal_users_menu .users-profile-custom-personal dt,

/* hides all extra fields fieldsets from customers in the edit Profile page*/
.customer_menu div.profile-edit #member-profile fieldset:nth-child(2), 
.customer_menu div.profile-edit #member-profile fieldset:nth-child(3),

/* Hides all extra fields fieldsets from customers in the view Profile page */
.customer_menu .users-profile-custom-personal legend, 
.customer_menu .users-profile-custom-personal  dl, 
.customer_menu .users-profile-custom-personal  dt,
.customer_menu .users-profile-custom-personal_read_only  legend, 
.customer_menu .users-profile-custom-personal_read_only  dl, 
.customer_menu .users-profile-custom-personal_read_only  dt 
{
display: none;
}

Now when the internal user logs in, only the first fieldset (the one with the main profile information) and the third fieldset (the readonly one) will be available. And when a customer logs in, only the first fieldset (the one with the main profile information) will be available.

This is just a workaround, because it's important to understand that the fieldsets are processed and are available, just not visible.

Yeah... a little bit too much of information, I know. But if I had found something like this when I had this need, it would be great! Not only it would have teach me something, but also would have helped me, and saved two weeks of searching.