Sogo 'Full name' field proposal

Hi all, need feedback on sogo

with samba4AD when you create a user you give the User name (used to login) and the full name of your user

my concern is that when you go to the imap setting in sogo, the full name is didier and not didier de labrusse (in my example)

this is my example

once I modify

    CNFieldName = cn;

to

    CNFieldName = displayName;

i have

Do i’m doing a good common use case ?
does it is valuable ?

probably in the good way, this is now what I have

instead of

I suppose it is better

@asl might I have your input ?

1 Like

Hello @stephdl, first a question: I recognised that in your sample screenshots under Shared Folders the name changed from ‘stephane de labrusse’ to ‘stephane’. Is this relevant here or just any sample?

In fact these are several improvements for the sysadmin

  • in the imap setting of sogo the full name is now fully written to didier de labrusse instead of only didier
  • in the upper top of sogo you can see didier de labrusse instead of only didier
  • in the shared emailbox you can see didier de labrusse instead of only didier

but it assumes that when you create an user in the nethgui interface, you put in the name field, the full name of your user

is it the case ?

yes you are right. Same issue here on my installation, but I did not take care so much about it.
Yes, I usually write the full name into this field as ‘surename forname’. So your change in the config is an advantage, I thnik this is the right way to go.

2 Likes

Same by me. I only used calendar, so I didn’t realised before, but I think too, modyfying the config is the right way.

1 Like

sogo is a good groupware, it worth an active maintainer :smiley:

1 Like

As you are busy about sogo.conf I rember about the issue with MailFieldNames = (“userPrincipalName”); which is fine for a single domain setup but not for a multi domain setup!

Solution:

  • Minimum some Information in the Documentation about this field or
  • A choice for the user between this default and empty or make a field writable so you can write the value directly to be used

3 months of searching just for this small issue :wink:

2 Likes

yep life is just a question of time and motivation :slight_smile:

well, high preassure from the customer made a high motivation (in this case)…

2 Likes

Actually, the Nethserver gui interface is lacking. After you create a user with it, and when using AD, you definitely want to change that users properties. (Name, last name, full name, email, homedir, profile path, etc.) Actually, you do not even want to create the user with the Nethserver gui, as you cant set half the needed values. The only thing it saves you from doing, is setting the shell to /bin/bash by enabling you to enable ssh.

This is not a shortcoming imho. Nethserver does not act as the AD. A container running in it acts as the AD. You want to administer the AD with AD tools. You create users in AD with ADUC.

I am very opensource minded, but I also need to employ M$ engineers for the day-to-day stuff I do not want to have to think about beyond design. Having to make them do things in two places sucks. Trying to recreate ADUC is senseless … it works, why replace it. If you run windows clients you better have one yourself.

To get back to the question: the name field in Nethserver translates to a bunch of properties in AD, skewing the displaying of that information. I would re-assess the need by going into ADUC and setting the AD properties like you would expect (fill as much as possible with correct information) and see how much of the issue remains, and then fix what is left. The current way Nethserver creates an AD user, is not realistic compared to real life scenarios. Setting these AD properties, actually has effect.

Yes it could be nice to get more AD properties (name and first name, email, mobile, home|work phone, Address, company…)

1 Like

It is actualy essential for proper use of AD. Even opensource software like OTRS, when coupled to AD, expecs the mail property to be populated as it is used for user identification.

If you are merely using the AD for user authentication and a few GPO’s, the current implementation on the nethgui is fine. Else it is the thing you want to mention not to use.

Hi @stephdl
What is about LDAP Admin, isn’t it possible to integrate it in nethgui?

1 Like

fulli integrated in netgui bty a reverse proxy like I did for shellinanbox ?

Not fully, I’m thinking about running it in background and filling fields at the nethgui. So we can keep the nethgui style.

Netgui doesn’t need phpldapadmin to create object in samba4, it does it by specific command relative to samba-tools

(Excuse me if i’m not accurate but i’m on my cell phone)

1 Like

I think it’s good to change the sogo field because it makes sense to see the full name instead of just the username.

I don’t know what’s the better way here:

With phpldapadmin you can change any field, more than with RSAT tools but you have to know what you’re doing. It’s ready to work and nothing has to be done, no reinvention of wheel.

On the other hand as mentioned above, it would be nice to have some more important fields in Nethgui (mail, mobile, photo(nextcloud uses it), etc) so it would be a simple Nethserver approach having the fields one REALLY needs in comparison to RSAT or phpldapadmin where you have fields you may never use.

I know anything could also be done just with RSAT and in 90% of the cases you want to have a Windows PC with RSAT to manage AD but there are also some requests in the forum to manage AD things with NS instead of with RSAT/ADUC, just not to be dependent on M$ tools when configuring the server.

Yes, I think this is the way to go to find the compromise of what’s really needed in NethGUI to satisfy AD users.

I’d also add photo and department.

1 Like

Yes you are right, I didn’t think about this.

No problem, everything is fine.

1 Like