Thread

My question centers around the implementation of the MSM. - We are evaluating it as a method of creating a multi-tiered site architecture for a client, but have identified potential administrative issues associated with managing and communicating with members.

For argument sake, site ZERO (0) will be our initial installation that (if I understand the documentation correctly) houses our user database.  Sites 2, 3 and 4 are sites that will share content and users.  We WANT to maintain ONE list of users (and all the associated custom fields that get collected about our users), and share both users and content between all four sites. (an article written by an editor at site 3 can be displayed on site 2)

Questions:

1. When implementing the MSM, are the membergroups identified at the site 0, or are they defined at all four of the sites?

For instance we also envision wanting to control access to content on site 2 by controlling which membergroups are able to see the content.  Where is this membergroup defined, and where is it controlled - by the site admin (sites 2,3,4), or by the super admin (site 0)? (as in our example above where site 2 displays entries from site 3, the site 2 administrator wants the capability for only certain users of membergroups at site 2 to see the site 3 content - are we capable of this?

We anticipate that site administrators will need to make membership changes to the membergroups/permissions to their local site - how do we do this?  AND, if we can utilize membergroups at the local sites, how do we control content access at site 4 for membergroups defined at site 2?  (is this a special tag that calls content - “cross site”?)

2. Currently “Communicate” allows us to send messages to membergroups - in an MSM implementation (depending on the answer to #1 above) how is this done?

3. Similar to a Windows (Forest:Domains), are we able to utilize membergroups OF membergroups? (user A is part of membergroup “blue”, membergroup “blue” is part of membergroup “colors” - so that when a communication is sent to membergroup “colors” - user A receives the communication)

4. Is there another method to separate security and distribution functions for membergroup type issues (membergroups are where security permissions are applied, and membergroups are where communicate allows us to send emails).

Thanks!

We WANT to maintain ONE list of users (and all the associated custom fields that get collected about our users), and share both users and content between all four sites. (an article written by an editor at site 3 can be displayed on site 2)

In that case, yes, the MSM sounds like a potentially good fit.

1. When implementing the MSM, are the membergroups identified at the site 0, or are they defined at all four of the sites?

Members and member groups are shared across the entire installation. If you don’t want certain members to be able to access certain sites you need to put them in different member groups. To give you an example, EllisLab uses the MSM for expressionengine.com, codeigniter.com, and mojomotor.com. The same account is valid on all those sites.

... the site 2 administrator wants the capability for only certain users of membergroups at site 2 to see the site 3 content - are we capable of this?

Yes, but you’d need to separate by member groups.

... how do we control content access at site 4 for membergroups defined at site 2?

As I’ve said, all member groups are central.

(is this a special tag that calls content - “cross site”?)

There is a site= parameter for many tags that allows you to specify the site. You can easily pull in content from one site into another, yes.

... are we able to utilize membergroups OF membergroups?

I am afraid not. What’s more, every user may only belong to exactly one member group, i.e. no multiple memberships are possible.

I hope that answers your questions for now? Let us know if there’s anything else, please.

So if I understand correctly, for a MSM installation with many sites spread across the country (with multiple local administrators), all the membergroups are maintained at site 0?  Are the local administrators able to add membergroups, or only superadmins? 

Also - if a user is only able to be part of one membergroup (which is utilized for both distribution and security), how is it feasible to control thousands of users…with different locations?  I am envisioning that this will be an administrative nightmare!

So if I understand correctly, for a MSM installation with many sites spread across the country (with multiple local administrators), all the membergroups are maintained at site 0?  Are the local administrators able to add membergroups, or only superadmins?

Conceptually, it’s important to remember that with MSM there is no one master site. It’s the same control panel regardless of what domain you’re logging in via. You can still control administrative access per-site via member groups. The ability to add member groups can be assigned to non-superadmins, as well.

Also - if a user is only able to be part of one membergroup (which is utilized for both distribution and security), how is it feasible to control thousands of users…with different locations?  I am envisioning that this will be an administrative nightmare!

It really depends on your requirements. I typically use custom member fields as a way to associate multiple group-like pieces of information with each user for use on the front-end. But on the back end (control panel) you’d definitely need to think about access control with groups in mind, and that a member can belong to only one group at a time. Hope that makes sense.

Don’t hesitate with additional questions!

That addresses the access/security question- thank you, but when it comes to distribution with “Communicate”, it doesn’t sounds like it’s an option to delineate recipients more granular than actual membergroups. Is that correct? Unless there is an addon/plugin/module for it?
Should we consider a 3rd party distribution solution for this like MailChimp? Is there an addon/plugin/module for integration of that into EE 2.0? It seemed there was one for EE1.x a few years ago, but I have not anything current on this.

... when it comes to distribution with “Communicate”, it doesn’t sounds like it’s an option to delineate recipients more granular than actual membergroups.

You can use various “mailinglists” instead. They are separate from the actual member management, though.

Is that correct? Unless there is an addon/plugin/module for it?

There are a number, I think. (FireMail is quite popular).

Should we consider a 3rd party distribution solution for this like MailChimp?

That’s another popular option, of course.