Can you define what address book a user sees by default with Class's of Service

[duran.goodyear]

In our continuing research into a new email system on campus, we've got another question.

When a user logs in to Zimbra, and starts writing a new email, and opens the address book to find an address, can you define what address book the user sees by default?

Case in point. A staff member here recently sent some private information via email to a student by accident, who has the same first and last name as the director of Personnel Services here. Using Outlook, they just started typing "Lastname..." and hit Tab to complete the address. For some reason the students name was picked instead of the Staff persons name. Lazyness won the day, and some private data was sent to the wrong person.

So, our question is. Can we define in class of service, if a staff person defaults to staff address book, and has to specifically use a different address book to find a faculty or student, and vice versa for the other classes of service.

This is a stupid solution, as we should be punishing laziness, not rewarding it, but the question stands.

Is this possible?

Thanks!

[mmorse]

Would you be talking about the GAL (global address list) auto-complete?

[duran.goodyear]

I guess my terms are bad.

Yes, in OUTLOOK its the Global Address List, the GAL.

What we were hoping for was a way to default by Class of Service, which address book they search against initially when they start typing in a name, or searching for a name. They would have the other address books available to them, but it wouldn't be their default.

I guess this could be a larger issue in a HUGE deployment, where across departments you'll find a lot of John Smith's, but if we could define a class of service that makes a user only see a dept, or group of names, instead of the GAL as default, it might be helpful to make sure you're sending your email to john smith in your dept., not john smith in another dept.

[mmorse]

it's called GAL in zimbra too
give me one sec and I'll start throwing you options

[mmorse]

Ok, so first is what's being worked on for the future:

Bug 13012 - groupings for GAL contacts for 'Select Addresses' dialog and or GAL > Bug 14531 - GAL via contacts folders with sorting, browsing and real sync

This too was a school's request to sort students vs teachers etc:
-Then the idea would be to, let people select either: 'search faculty', 'search students' or 'search both'
-And if you had to keep the faculty contact information separate, you would only allow the students to 'search students'

Stay tuned and I'll give you some current 'solutions' to your problem that you could consider.

[duran.goodyear]

Thanks mike, thats some of the exact functionality I'm looking for.
I think there is a fair bit of USER EDUCATION and AWARENESS that needs to be addressed, but being able do what bug # 13801 suggests is a great step.

I'm not sure I can post to that bug report, but a functional use of those dept level GAL's would be that your class of service could define *WHICH* GAL is your default, and which you had access to.

You of course could manually type in ANY email address you wanted, this wouldn't block email traffic, it would just possibly prevent you from accidently sending an email to the John Smith in the NYC office, with the address "jsmith1@domain.com" instead of the John Smith in your office with the address "jsmith2@...." Unless of course you went looking for his address specificly, or had to search in a different GAL for it.

Thanks for the help! This is a good bit of info, especially if it gets implemented that helps me steer my bosses towards zimbra

[mmorse]

Cool, I certainly hope uArts signs on!

I had actually removed the link to Bug 13801 - Add support for multiple GALs per domain but I'm glad that you posted there anyways so it can be remembered from all sides.
-Yes all of them would be COS oriented, as mass setting of options is always needed.

Though their all on the roadmap, you can still go and vote for all concerned!

[mmorse]

Current thoughts - I'm shifting away from the id10t error and getting more into student vs faculty/staff GAL abilities to look one another up to keep personal info safe etc:

Idea 1) In the COS of whomever you want to restrict, prevent 'auto-complete from gal' You can still leave 'GAL access' on if they want to find other in say the main search bar etc.
Or if this user finds that they are so worried about doing it again:
This can be done per individual settings page plus they can also turn off auto-complete from their options/prefs tab.

Idea 2) Separate GAL's:
There's a setting called the GalInternalSearchBase, which is set to DOMAIN by default so that hosting providers can access multiple domains.

You'd have like 3-4 domains:
@uarts.edu
@student.uarts.edu
@employee.uarts.edu (or split into @faculty.uarts.edu & @staff.uarts.edu)

You would however still set up aliasing and canonical addressing (displays in the 'From:" field of messages that are sent)
-So that they could receive mail to user@uarts.edu or user@student.uarts.edu of course.

You can have some interesting setup's domain wide as well: ManagingDomains - ZimbraWiki

---
And at this point, if you wanted everyone see each other you would set the search base to ROOT:

zmprov mcf zimbraGalInternalSearchBase ROOT

(SUBDOMAIN is comming in v5)

-Mix and match to your desired privacy