I like the idea of restricting access to groups. Maybe the default could be * or everyone but then you are able to explicitly allow or deny like a server document. Not sure about an actual ACL but a few extra fields on the group document itself would be nice.

This can already be accomplished. And it works with any document. Open the document properties, then go to the Security tab (it's the key). Uncheck "All Readers and Above" and then select from the list who can see it and/or add people/groups from the address book.

This will effectively prevent people from seeing the groups to be able to email to them. And if they do figure out the right name, the email will bounce back because they don't have access to it.

ps - make sure that the server(s) and admins are listed to have access to it.

@Chris, I know that this can be done but it's not exactly user friendly. I really think there should be a tab or a couple of fields outlining this in a far simpler fashion.

Maybe even allow a certain role in the NAB the ability to make these changes...

Having to go to Doc Properties to do this is more of a pain and not at all obvious to new administrators.

Promoted - great Idea JR.

I like the idea of surfacing this as a feature. In my experience, the standard doc level ACL has caused all kinds of problems, even if it is occasionally a good solution for something.

@John - "user friendly"? Who lets users modify groups? ;)

Until IBM does something about this, you could also throw a readers field on the document. That would be more user friendly than "having to go to [ACL Window] to do this".

And when I was a new administrator, this was one of the first things I did.

@4 - I didn't say it was a bad idea - just that it's already possible.

@Chris - don't be so defensive as you are my Domino Idol. Really...

@Bruce, not being defensive at all. Hope I'm not taken that way by anyone. :)

Editing the document-level ACL isn't a complete solution. Although users can't see the restricted group in the address dialog, they can still use it via type-ahead, and they can still reply to the group. An R5 server will even deliver the message, but an R6 (or higher) server generates a poorly-worded delivery failure.

Because of the above limitations of document-level ACLs, I had to implement those restrictions by customizing our mail templates.

It would be nice to be able to "properly" restrict groups using built-in functions. It would also be nice if the send attempt was stopped immediately with a pop-up that says something about "group XYZ has been restricted by the admins".

I agree with Chris. Existing reader and author fields should be more than enough and would probably be just as "User Friendly" as trying to impose some form of ACL on the group.

Okay, I don't think you guys are quite getting what I mean.

Right now, there is no way in a group document to lock it down to not be seen or sent to unless you A. Go into the document properties and set readers or B. Customize the NAB to add reader fields.

I'm proposing adding the ability inherent into a Group document so you can restrict who can see and/or send to a group. And maybe even (as some have suggested) add nice error messages for people trying to send to a group that aren't authorized to do so.

I called this an "ACL" in the sense that we are controlling access to the group. Not that it would look exactly like a database ACL.

-Grey

A user can create a Group and add everybody in the Domino Directory using the Personal Address Book.

Now, if behind this idea is that you don't want mass emails, just go an create a Server Rule:

No messages to more than 50 recipients. Allowed just if you are HR User.

This is a basic example.

I agree with this idea and want to extend this to a acl for folders and maybe views.

Sorry to extol the virtues of Exchange in this Forum but... it has been possible to enforce who can email a group since Exchange 97, maybe before! Surely this can't be such a complicated request.

It should be clearly visible in the group document: "Senders to this group", with users, a group, or an OU set there. A simple idea, but how to do it?

Using document properties is not an option to me to resolve this question. Users should be able to clearly see who can email a group.

Agreed with the points above about type-ahead, and a server rule can cause false positives, and give us admins more headaches.

Sorry to be posing comments and not answers, but I just wanted to say something - this feature is one of the common user complaints from Exchange users who join a Notes house!

Making the existing features more visible would be great. This is especially true for an inherited environment. The new admin may not know which groups are hidden from all users but visible to the servers and select users.

What we've done since R5 was add to the $PersonSchema and $GroupSchema subforms (which supposedly will be arround "forever" for LDAP schema extension) an additional readers field (and authors so on same tab instead of adding to admin tab).
It works VERY well and we simply upgrade from version to version of Domino without having to add anything. I literally is a 15 minute thing to customize your subform in you Directory and then write an agent to populate all groups and person docs with whatever is the "most case".
One other thing, once you use this, you may want to set the INI for the router to still deliver mail if typed blind.

@Stephen - Absolutely correct... Amazing how as a Notes admin my team have been getting "beaten up" by our new Notes users (former Outlook/Exchange users). Seems to me that a directory "object" should have ACLs assignable in a straight forward manner out of the box.

@Steve - thanks for your comment.

@Chris - what you propose simply doesn't work. When a user performs an address lookup, the server's access to the Domino Directory is used, NOT the user's.

Consequently, if the user knows the first few characters of the name of the group, they will be able to send mail to it.

Try to demo your proposal to a half-experienced CIO who gets bugged by complaints about people sending rubbish to all users via email, and you will end up feeling rather embarrassed.

This is a real requirement by real users, rather than many of the other ideas on this site which are "nice to haves" in my humble opinion. C'mon guys, get promoting!

This can be achieved with Reader fields - albeit in a rather clunky fashion - so, sorry, I'm demoting it

Document Readers properties can be a solution, but if you are using a dircat and synch groups. The hiding group will show in the dircat. Users using the dircat will be able to use the group (Group will be expand), Same for Webmail users.