Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.12.0-b1
    • Component/s: Plugins, Staff Interface
    • Labels:
      None

      Description

      When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

      After signup a message should be displayed if verification is enabled "An message has been sent to verify your email address. Please complete verification at your earliest convenience."

      When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click here." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.

      Add new setting to the order plugin setting "Hold unverified user orders." This setting should prevent prevent orders by unverified users from being automatically marked as accepted by the cron. A tooltip should be added saying as much.

        Activity

        jonathan Jonathan Reissmueller created issue -
        jonathan Jonathan Reissmueller made changes -
        Field Original Value New Value
        Component/s Plugins [ 10007 ]
        Component/s Staff Interface [ 10000 ]
        jonathan Jonathan Reissmueller made changes -
        Description When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until your email is verified. To resend your verification email, click *here*". This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until your email is verified. To resend your verification email, click *here*.". This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        jonathan Jonathan Reissmueller made changes -
        Description When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until your email is verified. To resend your verification email, click *here*.". This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until your email is verified. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        jonathan Jonathan Reissmueller made changes -
        Description When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until your email is verified. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        jonathan Jonathan Reissmueller made changes -
        Description When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.
        When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.

        Add new setting to the order plugin setting "Hold unverified user orders." This setting should prevent prevent orders by unverified users from being automatically marked as accepted. A tooltip should be added saying as much.
        jonathan Jonathan Reissmueller made changes -
        Description When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.

        Add new setting to the order plugin setting "Hold unverified user orders." This setting should prevent prevent orders by unverified users from being automatically marked as accepted. A tooltip should be added saying as much.
        When a user signs up using any order form and the email verification is enabled, an email verification should be created and sent immediately. This verification should have a redirect that points back to the cart on the current order form.

        After signup a message should be displayed if verification is enabled "An message has been sent to verify your email address. Please complete verification at your earliest convenience."

        When the order is completed and the client moves to payment, two things should happen. First, the email verification record should be updated to redirect to the payment page for this order. Second, if the setting to prevent payment is enabled, and the email to be verified is the same as the contact's current email, then a message should appear on the payment page saying "Payment is unavailable until email verification is complete. To resend your verification email, click *here*." This link can point to ClientVerify::send(). Also we should of course actually prevent payment based on the setting and disable the payment form as well.

        Add new setting to the order plugin setting "Hold unverified user orders." This setting should prevent prevent orders by unverified users from being automatically marked as accepted by the cron. A tooltip should be added saying as much.
        abdy Abdy Franco made changes -
        Assignee Abdy Franco [ abdy ]
        Automated transition triggered when Abdy Franco created a branch in Stash -
        Status Open [ 1 ] In Progress [ 3 ]
        abdy Abdy Franco made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 12 minutes [ 720 ]
        Worklog Id 13870 [ 13870 ]
        abdy Abdy Franco made changes -
        Time Spent 12 minutes [ 720 ] 1 day, 14 minutes [ 29640 ]
        Worklog Id 13871 [ 13871 ]
        Automated transition triggered when Abdy Franco created pull request #184 in Stash -
        Status In Progress [ 3 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        abdy Abdy Franco made changes -
        Time Spent 1 day, 14 minutes [ 29640 ] 2 days, 4 minutes [ 57840 ]
        Worklog Id 13872 [ 13872 ]
        abdy Abdy Franco made changes -
        Time Spent 2 days, 4 minutes [ 57840 ] 2 days, 1 hour [ 61200 ]
        Worklog Id 13890 [ 13890 ]
        Automated transition triggered when Abdy Franco merged pull request #930 in Stash -
        Status In Review [ 5 ] Closed [ 6 ]
        abdy Abdy Franco made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        abdy Abdy Franco made changes -
        Time Spent 2 days, 1 hour [ 61200 ] 2 days, 3 hours, 44 minutes [ 71040 ]
        Worklog Id 13898 [ 13898 ]
        Automated transition triggered when Jonathan Reissmueller made commit cfa0f96924d in Stash -
        Status Reopened [ 4 ] In Progress [ 3 ]
        abdy Abdy Franco made changes -
        Status In Progress [ 3 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            abdy Abdy Franco
            Reporter:
            jonathan Jonathan Reissmueller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              17/Sep/20

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 2 days, 3 hours, 44 minutes
              2d 3h 44m

                Agile