Uploaded image for project: 'Blesta Core'
  1. Blesta Core
  2. CORE-2468

Expired/Over qty coupons break service modifications

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.0-b1
    • Component/s: None
    • Labels:
      None

      Description

      When a coupon is either expired or has reached it's usage limit, services that coupon is applied to cannot be modified, since the system attempts to re-apply the coupon. This seems to only occur in the admin interface. There are two cases. First when service change queuing is not enabled, the admin immediately receives an error:

      That coupon does not appear to be valid.

      If service change queuing is enabled then the edit will succeed, but when the cron runs to perform the service change, it returns an error:

      Processing service change # resulted in status: Error

      If the 'Limitations do apply to service renewals' option is selected and the limit is reached or the coupon expires, then it should continue to apply the coupon regardless.
      If the 'Limitations do not apply to service renewals' option is selected and the limit is reached or the coupon expires, then either the coupon should be ignored or an error message should be shown immediately even if service change queuing is enabled.

        Issue Links

          Activity

          jonathan Jonathan Reissmueller created issue -
          jonathan Jonathan Reissmueller made changes -
          Field Original Value New Value
          Rank Ranked higher
          admin Paul Phillips made changes -
          Issue Type Bug [ 1 ] Improvement [ 4 ]
          Hide
          tyson Tyson Phillips (Inactive) added a comment -

          I'm not sure the description's expectation for the Limits ... apply to service renewals options are accurate to what we'd want.

          It seems to me that the problem here is that we want the ability to edit a service to save the service data without causing an error about the coupon being invalid due to limitations. In this case, we can solve that problem by only applying the coupon validation iff the coupon has been changed.

          We would need to have the same occur during upgrades/downgrades. Unless the coupon is changed during the upgrade/downgrade, there is no reason to validate it.

          The primary problem here is in answering the question, "When does the service renew?" so that we can then, and only then, validate the coupon again based on its defined settings.

          Show
          tyson Tyson Phillips (Inactive) added a comment - I'm not sure the description's expectation for the Limits ... apply to service renewals options are accurate to what we'd want. It seems to me that the problem here is that we want the ability to edit a service to save the service data without causing an error about the coupon being invalid due to limitations. In this case, we can solve that problem by only applying the coupon validation iff the coupon has been changed. We would need to have the same occur during upgrades/downgrades. Unless the coupon is changed during the upgrade/downgrade, there is no reason to validate it. The primary problem here is in answering the question, "When does the service renew?" so that we can then, and only then, validate the coupon again based on its defined settings.
          jonathan Jonathan Reissmueller made changes -
          Link This issue relates to CORE-2472 [ CORE-2472 ]
          Hide
          jonathan Jonathan Reissmueller added a comment -

          As far as I can tell renewal happens exclusively through the cron. It seems to make sense for the coupon usage to be incremented at the time of invoice creation.

          So this is the way I would expect coupon usage to act:

          Service creation will increment the coupon usage for either 'limits ... apply' setting.
          Service renewal will only increment the coupon usage and validate the usage limitation for the 'limits do apply' setting.
          Service editing will only increment the coupon usage and validate the usage limitation when a coupon is being added or changed. (IMO this is what should be done to complete this task, just not tying to increment at all rather than not validating)

          Should coupon usage be decremented when a coupon is removed from a service?

          Another thing not directly addressed by this ask but related that since renewal invoices are created by the cron, they will fail silently once the coupon reaches it's limit. Even just ignoring the coupon sounds better than that to me.

          Show
          jonathan Jonathan Reissmueller added a comment - As far as I can tell renewal happens exclusively through the cron. It seems to make sense for the coupon usage to be incremented at the time of invoice creation. So this is the way I would expect coupon usage to act: Service creation will increment the coupon usage for either 'limits ... apply' setting. Service renewal will only increment the coupon usage and validate the usage limitation for the 'limits do apply' setting. Service editing will only increment the coupon usage and validate the usage limitation when a coupon is being added or changed. (IMO this is what should be done to complete this task, just not tying to increment at all rather than not validating) Should coupon usage be decremented when a coupon is removed from a service? Another thing not directly addressed by this ask but related that since renewal invoices are created by the cron, they will fail silently once the coupon reaches it's limit. Even just ignoring the coupon sounds better than that to me.
          jonathan Jonathan Reissmueller made changes -
          Remaining Estimate 0 minutes [ 0 ]
          Time Spent 50 minutes [ 3000 ]
          Worklog Id 10354 [ 10354 ]
          tyson Tyson Phillips (Inactive) made changes -
          Story Points 3
          tyson Tyson Phillips (Inactive) made changes -
          Sprint 4.2.0 Sprint 3 [ 48 ]
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked higher
          tyson Tyson Phillips (Inactive) made changes -
          Rank Ranked lower
          Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
          Status Open [ 1 ] In Progress [ 3 ]
          jonathan Jonathan Reissmueller made changes -
          Time Spent 50 minutes [ 3000 ] 1 hour, 38 minutes [ 5880 ]
          Worklog Id 10440 [ 10440 ]
          Automated transition triggered when Jonathan Reissmueller created pull request #343 in Stash -
          Status In Progress [ 3 ] In Review [ 5 ]
          Resolution Fixed [ 1 ]
          tyson Tyson Phillips (Inactive) made changes -
          Fix Version/s 4.2.0-b1 [ 11014 ]
          Automated transition triggered when Tyson Phillips (Inactive) merged pull request #343 in Stash -
          Status In Review [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              jonathan Jonathan Reissmueller
              Reporter:
              jonathan Jonathan Reissmueller
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Fix Release Date:
                5/Dec/17

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour, 38 minutes
                1h 38m

                  Agile