Answered Multiple sites using contexts and management of users

Hi Guys,

I am looking at the possibilities of using Revo for managing multiple sites from a single install.
So played around setting up a test environment with 3 contexts, one for each site. Working fine and can set up manager users to only edit a particular websites (context) resources... so far so good.

Where I am struggling is say my 3 websites (contexts) each have a members area. Then I will need to set up user accounts for members to access certain pages on their respective site. I know the security of the actual resource pages can be set via resource groups. But the management of these user accounts seems not to be context sensitive. This raises a couple of issues
1) I could not have users on the 3 sites with the same username.
2) Managers for individual contexts see all the user accounts, not just those relating to the particular website (context).

Am I missing something or is the management of user accounts not context sensitive?

Thanks. [ed. note: uxello last edited this post 13 years, 10 months ago.]

Hi,

our last project has 4 contexts (each with another domain - using the ContextRouter plugin by Mark Hamstra) we are also running into the problems you describe.

To solve issue 1) you could give a user access to more then one context so you don't need 3 different user accounts. This is how we do it currently. The Login extra can handle this for you.

For issue 2) we currently have no solution. Revo doesn't support a filtered user management as far as I know. You could create your own extra to handle this problem. All you would need is a CMP which lists only the users an admin should have access to. The editing of the user can then be done with the built in "edit user" page.

Thanks for your reply.

For Issue 1) I don't think I was clear enough (sorry!). It is 'frontend' member user account uniqueness that I am particularly concerned with, I could live with naming user manager accounts distinctly.
E.g. With several contexts (domains) each with a frontend members area. As far as I can tell the member account usernames must be unique across the whole system and not just within each context. I.e. if I have a member account username jbloggs for context1, I cannot have a jbloggs member account username for context2 ??

For issue 2) OK I have not looked into CMP, thanks. So I guess with a bit of coding work that can be solved.

Thank.

Quote from: uxello at Nov 26, 2012, 03:38 AM

For Issue 1) I don't think I was clear enough (sorry!). It is 'frontend' member user account uniqueness that I am particularly concerned with, I could live with naming user manager accounts distinctly.
E.g. With several contexts (domains) each with a frontend members area. As far as I can tell the member account usernames must be unique across the whole system and not just within each context. I.e. if I have a member account username jbloggs for context1, I cannot have a jbloggs member account username for context2 ??

My hint is regarding to frontend users. You can give a member of your site(s) access to 1 or more user groups. Context access is then handled through user groups. As I told you, the Login plugin can handle this (it can at registration time add a member to 1 or more user groups).

Quote from: gadgetto at Nov 26, 2012, 04:00 AM

Quote from: uxello at Nov 26, 2012, 03:38 AM

For Issue 1) I don't think I was clear enough (sorry!). It is 'frontend' member user account uniqueness that I am particularly concerned with, I could live with naming user manager accounts distinctly.
E.g. With several contexts (domains) each with a frontend members area. As far as I can tell the member account usernames must be unique across the whole system and not just within each context. I.e. if I have a member account username jbloggs for context1, I cannot have a jbloggs member account username for context2 ??

My hint is regarding to frontend users. You can give a member of your site(s) access to 1 or more user groups. Context access is then handled through user groups. As I told you, the Login plugin can handle this (it can at registration time add a member to 1 or more user groups).

Yes I appreciate the use of usergroups, but if jbloggs on context1 is a different jbloggs to that on context2 then I would not want them to be a single member account accessing multiple groups. I would want the reverse? I.e. two member accounts each accessing a separate members area (usergroup) for their particular website.

In this scenario they are each distinct people and the first one to register would get the 'jbloggs' username for their website members area. The second 'jbloggs' would not be allowed to create an account of that name too (?), even though as far as the frontend user is concerned they are unrelated websites and would know nothing of the other website.

Thanks again for your time!

Quote from: gadgetto at Nov 26, 2012, 06:02 AM

OK - now I got it. And yes this is a restriction of MODx - usernames of one MODx instance have to be unique.
But If your sites are unrelated, why not setting up n instances of MODx?

Ok thanks, thought so... shame.

I already have separate installs using Evo. One of the reasons for moving to Revo would be proper multi site management via the contexts.

I envisage 30+ sites, though unrelated, all basically with the same functionality using certain custom plugins/snippets I have written. The main drive is to drastically reduce system management (upgrades etc) by running them from one ModX install.

I guess if I could live with the username restriction then it should otherwise work in conjunction with your other suggestions (CMP and ContextRouter).

Personally, I prefer using email as login name anyway. Quite a few large sites do that, so it shouldn't be any surprise to your users. Solves a lot of user management problems before they ever get started.

Quote from: sottwell at Nov 26, 2012, 10:49 AM

Personally, I prefer using email as login name anyway. Quite a few large sites do that, so it shouldn't be any surprise to your users. Solves a lot of user management problems before they ever get started.

Thanks Susan,
That is true. Though, there are always the odd exception. I.e. In my scenario a very small minority of users may be a member of more than one website. Ideally I'd like the users database to have a context filter/security system, as the resources do, so members can be made truly independent for each context and managed independently too.

Hi

Slightly off topic, but with the multiple contexts did you ever get friendly urls to work?