Silly Question of the Day about ClientConfig

Am I correct to assume that ClientConfig is a separate from setting up User Names and Passwords?

Documentation for ClientConfig mentions much about system settings, but not about login setup. This is my first time setting up a user and password for my client, and first time using client config. I want the client to be able to login and make changes to web page content, but also make updates to a few standard system setting type items like phone, address, form send to address etc, maybe even the SMTP address—all of which seem to be perfectly handled by client config.

Between users users groups for both MODX and ClientConfig, it's a bit overwhelming. Do I even need user groups. Why would I incorporate them? I'm designing for a very small organization for which there may only be 3 users at the most — and I'll be one of them.

Any feedback or nudging or positive encouragement will be well received.

ClientConfig has nothing to do with assigning users or groups. The "groups" of ClientConfig are only for groups of settings, for organizing them. Don't confuse them with user groups.

It takes a "sudo" manager user to establish what settings are available for other manager users to be able to change, but any Manager user can change the settings values.

Thanks Susan:

When you say "sudo", is that like me? I am the admin and have full access to everything. I will also want to create another admin type user with access to everything, as well as one that is significantly restricted. My client will be instructed to use the "significantly restricted" login for making general, normal updates to content on the site. I did read with ClientConfig that I must remember to set myself up as a super user so I can always have access to changes made in ClientConfig.

"Groups" seems overkill, and perhaps better for a later time. My interpretation is that if a site needs many many different login types, groups is an easy way to set new people up without maybe having to reconfigure settings, and ensure that anyone in a given group is provided the same privileges. Maybe a group with total access, and another group with limited access, maybe even a group that can only access and update one or two resources in the site, etc. My current site is very far from complex. One or two people maximum that might need to change a photo or text on a resource. Phone numbers, and address will probably not change, but I want them to have that option. More important is giving them the ability to control the SMTP info for the form. My host is dumping their email service option, but have provided me with an alternate option to still send form mail from my server. In the event that breaks or ceases to function, I do want my client to have the option of changing that SMTP to a gmail or other hosted email account.

The first run-through is of course the most daunting. I appreciate your feedback.

With ClientConfig, I think you do need to create one group (not a user group!) and put your custom settings in that group, otherwise nobody can see any of the settings you create.

Thanks Susan: I think you're right. First now I'm reading chapter 10 in Bob's book and will do a trial run of simply establishing a new user with limited access. Assuming that goes well, I'll move on to setting up the ClientConfig settings.

If you want to give other users access to the manager, their user accounts will need to be in a User Group. If you want to give everyone full access, you can make them a Sudo user (there's a checkbox, Sudo, when editing a user account) and/or add them to the standard Administrator user group. That way they will be able to login to the manager.

As for ClientConfig, there's a system setting accompanying the package that lets you determine the user groups a user needs to be in to see the "Admin" button in the ClientConfig component, and manage the available settings on the client view.

Hi Mark:

Thank you so much for the tips. I am just now viewing a video posted by Menno at the moment for setting up a MODx user, and giving them limited access. Then I will begin to set up ClientConfig. This new group with limited access would be the group I would set ClientConfig to allow. Am I interpreting you correctly?

I think in the case of this site, everyone who has access in any capacity to make changes on the site should be given also allowed to update a phone number or the basic settings I will establish in ClientConfig, so maybe the Sudo user option is the way to go.

There will only be one or two people other than myself that would have access. I want my standard super user access of course and then the others I want to only be able to edit resources, upload photos, etc, and make changes to the site wide type items that would be set up with ClientConfig.

I should clarify "access in any capacity ". I meant moreso changes to content on the site, not chunks, TVs, templates or snippets. I would be the only person able to to that. As a backup, I probably will want to create another administrator login as a backup. Still don't understand whether it's best to make that login a superuser or not.

I ALWAYS give the site owner an administrator with sudo login. A lot of the time I give them two logins, one as admin/sudo and one as editor for them to use most of the time. I think it's wrong to assume that the site owner does not deserve an owner's login. What if I die? Go on an extended vacation, get into a bad car accident and am in hospital, or even am replaced? This isn't morbid, it's reality. As a basic minimum we never know what the future holds and locking out the site owner from their own site is wrong in my opinion.

I agree that the site owner should have an admin access for all the reasons you mentioned. As I move forward, I also want to be able to provide clients with references and contacts should the worst ever occur.