We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 42727
    • 8 Posts
    Hi everyone, I've been using Modx for a few months now and despite getting more comfortable with it, I still feel lost in some respects. Throughout my time using Modx I've read through the forums on this site and found the answers to tons of questions, so to all those who indirectly answered my questions by answering others in the past, a huge thanks!

    There are still a few things I'm stuck on and I would really appreciate some help.

    Here are some of the challenges I'm running into:

    1 - I'm using Login.Register. I need to make the snippet send an e-mail to the admins notifying them there is a new user awaiting their approval, and in the meantime not allow the user to access the site until admin has approved them. Is there a way to have the user activate their account via e-mail yet still be blocked until approval? How should I go about doing this?

    2 - When I create a new account using Login.Register, it sends the validation e-mail to the user, but clicking on the link directs the user to page 1. I've tested it having removed the confirmRegister snippet and it directs the user to the proper confirmRegister page. Maybe my permissions are set too high? Any ideas on how I can troubleshoot this?

    3 - I'm trying to create a basic front-end interface for an admin usergroup to view a list of newly registered users for the website. The admins could then approve the user and activate their account. I'm using 'Peoples 1.0.1' to get a list of inactive users. Then in the chunk I'm creating a submit button with a snippet and sending [[+internalKey]] variable to it. And from there I'm not sure how to set this up. I know I need to put something like $user -> set('active', '1'); but I don't know what code to put in before that to identify the user as the same one from the internalKey variable.

    Please let me know if I'm going at any of these in the right or wrong way, or if there's a really simple solution I haven't considered yet.

    Thanks in advance!
    -John

    MODX Revolution 2.2.5-pl(traditional)
    Login 1.8.1

    This question has been answered by BobRay. See the first response.

    • discuss.answer
      • 3749
      • 24,544 Posts
      See this: http://forums.modx.com/index.php?topic=52526.0%3Bwap2

      1. The email to the admin can also be done with a postHook for the register snippet or the ConfirmRegister snippet. There may be an existing extra for this. To keep the user from self-activating, you could take the activation link out of the email Tpl chunk.

      2. If you don't want the user to self-activate, you don't want to use the ConfirmRegister snippet.

      3. You could do that, but have you seen that admins can easily activate multiple users in Security -> Manager Users? Also, see the ActivationEmail extra, which sends an email to the user notifying them of the activation.


      The problem with your plan is that there's no way to verify the user's email address, which is the point of the Activation Email. I can think of some ways to deal with that:

      1. Modify the ConfirmRegister snippet to *not* activate the user but send an email to the admin, as described in the link above.

      2. Let the user self-activate and deactivate users you don't like.

      3. Insert the admin's email address in the emailTpl chunk (and in the from and reply-to fields) with a message to "reply to this message to request activation." Make sure the user's username is also in the message.


        Did I help you? Buy me a beer
        Get my Book: MODX:The Official Guide
        MODX info for everyone: http://bobsguides.com/modx.html
        My MODX Extras
        Bob's Guides is now hosted at A2 MODX Hosting
        • 42727
        • 8 Posts
        Thanks Bob! I'll be trying out your recommendations.

        Sounds like I should be altering my plan. Here's what I'll be going for:

        The Login.Register sends the e-mail to the user.
        The user gets lgnActivateEmailTpl but instead of [[+confirmUrl]], I include a link that sends them to a page that has a custom snippet. (or preferably a modified ConfirmRegister if I can get it to work)
        The snippet sends an e-mail to the admins informing them a new user is awaiting approval.
        The admins log into the manager and activate the user's account
        The user gets notification via the ActivationEmail extra.

        Hopefully I'm on the right track. Please let me know if you see any logic holes.


        About letting admins activate users using Security -> Manager Users... This is the solution I was originally hoping for. Is there a way to give admins permission to edit/ activate /delete users from a specific user group only, and to prevent admins from altering, deleting or deactivating each other's accounts or even mine? The admins are very trusted, but I'd like to prevent anything like this from happening.
          • 3749
          • 24,544 Posts
          The user gets lgnActivateEmailTpl but instead of [[+confirmUrl]], I include a link that sends them to a page that has a custom snippet. (or preferably a modified ConfirmRegister if I can get it to work)

          I would suggest a slight change in this part. Go ahead and leave the emailTpl alone. It will send a link to the ConfirmRegister page and will contain info on the user in the $_GET parameters that the ConfirmRegister snippet will decode for you.

          On that ConfirmRegister page, put a tag for a duplicated and modified ConfirmRegister snippet with the activation part commented out and, just below it, an email to the admin.
            Did I help you? Buy me a beer
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/modx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
            • 42727
            • 8 Posts
            Thanks again. That makes sense, I shouldn't be trying to re-invent the wheel.

            A few more questions:
            1- Do you think I'll run into any trouble with ConfirmRegister due to the issue I was explaining in my first post(in question 2)?

            2a- Is there a way to give admins permission (via Security -> Manager Users) to edit/ activate /delete users from a specific user group only, and to prevent admins from altering, deleting or deactivating each other's accounts or even mine? I'm repeating my 2nd post question but I need to know if this is the right option for me... or...

            2b- If I could send the user an email that links to the ConfirmRegisterA snippet(modified to send an e-mail to admin instead of activating), this modified snippet sends an email to the admin and in this e-mail is a link the admin can click on to approve the user using ConfirmRegisterB snippet. Crazy enough to work? How can I make the important variables from e-mail A carry over to the link in e-mail B?

            or...

            2c - Simplify things by making most admin accounts only edit content, and assigning only one admin with account editing permissions.

            Sorry to ask so many questions, I just want to have a clear picture of how I should do this before diving in.
              • 3749
              • 24,544 Posts
              1. You shouldn't as long as the ConfirmRegister page is published and not protected in any way.

              2a. I don't think so. I think access_permissions is necessary to activate users (I could be wrong -- worth checking). If it is, it would allow them to change any permissions (including yours).

              2b. Good idea. Since the credentials are in the $_GET params, you should be able to just make a new link just like the one Register makes and embed it in the admin email.

              2c. That would work, but remember that if I'm right above, users of that account could make themselves sudo users and change your password.
                Did I help you? Buy me a beer
                Get my Book: MODX:The Official Guide
                MODX info for everyone: http://bobsguides.com/modx.html
                My MODX Extras
                Bob's Guides is now hosted at A2 MODX Hosting
                • 42727
                • 8 Posts
                Thanks again,

                2a & 2c - Those are the main reasons I was hoping for a front-end solution to activating users. I can probably work around it though.

                The ConfirmRegister plot thickens...
                About the ConfirmRegister issue, I'm wondering if it's something I need to change in my settings. The page ConfirmRegister snippet page is published and isn't protected in any way I know of.

                On a side note though, I had the same issue as firebot6:
                http://forums.modx.com/thread/28484/solved-404-page-showing-instead-of-unauthorized-page

                I fixed that issue today, (also, I changed my error_page the a new resource instead of the default of page 1) then re-tested the Register page. Now the activation link goes to my error_page instead of going to page 1. I'm hoping this is a useful clue that could lead to a solution.

                  • 3749
                  • 24,544 Posts
                  Make sure your Login package is up-to-date. In earlier versions, the ConfirmRegister page logged people in as the anonymous user, which often sent them to the 404 page.
                    Did I help you? Buy me a beer
                    Get my Book: MODX:The Official Guide
                    MODX info for everyone: http://bobsguides.com/modx.html
                    My MODX Extras
                    Bob's Guides is now hosted at A2 MODX Hosting
                    • 42727
                    • 8 Posts
                    I'm running Login 1.8.1 and just to make sure it wasn't a problem with installation, I uninstalled and reinstalled it. Cleared cache, tried again and the same problem is happening. Is there anything else I can check?
                      • 34049
                      • 28 Posts

                      Quote from: initial_shock at Feb 06, 2013, 03:42 AM

                      3 - I'm trying to create a basic front-end interface for an admin usergroup to view a list of newly registered users for the website. The admins could then approve the user and activate their account. I'm using 'Peoples 1.0.1' to get a list of inactive users. Then in the chunk I'm creating a submit button with a snippet and sending [[+internalKey]] variable to it. And from there I'm not sure how to set this up. I know I need to put something like $user -> set('active', '1'); but I don't know what code to put in before that to identify the user as the same one from the internalKey variable.

                      Quote from: BobRay at Feb 06, 2013, 04:36 AM
                      See this: http://forums.modx.com/index.php?topic=52526.0%3Bwap2
                      3. You could do that, but have you seen that admins can easily activate multiple users in Security -> Manager Users? Also, see the ActivationEmail extra, which sends an email to the user notifying them of the activation.

                      This is something I would like to achieve but I am struggling at the moment so any help would be appreciated. I have managed to set this up previously in Evo, but I'm not making much headway in Revo.

                      Basically for the group website I'm setting up the membership secretary will be approving any user requests. I really don't want to go through the rigmarole of explaining the backend manager to them. Just having the plain web page front for approving members would make it really easy for them. So I have set up a user permission group for the membership secretary with a specific page to list the inactive members. It would be really nice to be able to put a couple of buttons against each user to "approve" or "deny" which would either set active=1 or delete the user. This was possible with LoginPE in Evo and I'm just trying to reproduce the same functionality in Revo. If I can't get this sorted it looks like I'll be approving new users rather than the Membership Secretary which is something I would like to avoid.

                      Regards

                      Adrian