Details

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

      Description

      Coupons should be updated to allow for a set of terms/periods to be defined for which the coupon must apply to to be used. These terms/periods must always apply regardless of any additional limitations.

      1. Create a new table for coupons called coupon_terms
        • `id` PRIMARY KEY
        • `term` SMALLINT(5)
        • `period` ENUM('day','week','month','year','onetime')
      2. Update the add/edit coupon pages to add a new section for Coupon Terms beneath Limitations
        • The coupon terms should include a description... something to the effect that coupons can only be applied if the service ordered is one of the selected terms/periods. If none are enabled, then the coupon applies to ALL possible terms/periods (i.e. the default behavior).
          Enabled Period Terms
          Checkbox Day [Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Day, 3 Days, and 4 Days]
          Checkbox Week [Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Week, 3 Weeks, and 4 Weeks]
          Checkbox Month [Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Month, 3 Months, and 4 Months]
          Checkbox Year [Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Year, 3 Years, and 4 Years]
          Checkbox Onetime [Blank section]
        • Unchecking a checkbox, or deleting all items in the Terms section has the same effect--deleting the entries from the coupon_terms table. You can have the UI update itself to check/uncheck the checkbox whether any terms are set.
        • (optional) It would probably be useful to have some UI JS utility that displays the terms as labels in an input box, similar to marketplace tags, rather than a pure-text CSV list.
      3. Update ALL locations that coupons are applied/checked to be applied, or otherwise validated to ensure that the selected terms/periods are considered as limitations to the coupon's use. This occurs at minimum in the Coupons model and the Pricing Presenters. Check all locations.

      It may be useful to limit coupons to a particular billing cycle or set of cycles. An example is a 50% off first month coupon. You certainly wouldn't want to give 50% off the first year. I imagine the interface looking very much like the package pricing interface.

      It seems that this should be an optional feature controlled whether or not any billing cycles are set for the coupon. If they are not it should continue to function how it does now.

      Attached is an example of what it could look like.

        Activity

        jonathan Jonathan Reissmueller created issue -
        jonathan Jonathan Reissmueller made changes -
        Field Original Value New Value
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Story Points 8
        tyson Tyson Phillips (Inactive) made changes -
        Description It may be useful to limit coupons to a particular billing cycle or set of cycles. An example is a 50% off first month coupon. You certainly wouldn't want to give 50% off the first year. I imagine the interface looking very much like the package pricing interface.

        It seems that this should be an optional feature controlled whether or not any billing cycles are set for the coupon. If they are not it should continue to function how it does now.

        Attached is an example of what it could look like.
        Coupons should be updated to allow for a set of terms/periods to be defined for which the coupon must apply to to be used. These terms/periods must *always* apply regardless of any additional limitations.

        # Create a new table for coupons called *coupon_terms*
        #* `id` PRIMARY KEY
        #* `term` SMALLINT(5)
        #* `period` ENUM('day','week','month','year','onetime')
        # Update the add/edit coupon pages to add a new section for _Coupon Terms_ beneath _Limitations_
        #* The coupon terms should include a description.. something to the effect that coupons can only be applied if the service ordered is one of the selected terms/periods.
        ||Period||Terms||
        |Day| [Input box where you can type a number (e.g., "1,3,4")]|
        |Week||
        |Month||
        |Year||
        |Onetime||

        ----

        It may be useful to limit coupons to a particular billing cycle or set of cycles. An example is a 50% off first month coupon. You certainly wouldn't want to give 50% off the first year. I imagine the interface looking very much like the package pricing interface.

        It seems that this should be an optional feature controlled whether or not any billing cycles are set for the coupon. If they are not it should continue to function how it does now.

        Attached is an example of what it could look like.
        tyson Tyson Phillips (Inactive) made changes -
        Description Coupons should be updated to allow for a set of terms/periods to be defined for which the coupon must apply to to be used. These terms/periods must *always* apply regardless of any additional limitations.

        # Create a new table for coupons called *coupon_terms*
        #* `id` PRIMARY KEY
        #* `term` SMALLINT(5)
        #* `period` ENUM('day','week','month','year','onetime')
        # Update the add/edit coupon pages to add a new section for _Coupon Terms_ beneath _Limitations_
        #* The coupon terms should include a description.. something to the effect that coupons can only be applied if the service ordered is one of the selected terms/periods.
        ||Period||Terms||
        |Day| [Input box where you can type a number (e.g., "1,3,4")]|
        |Week||
        |Month||
        |Year||
        |Onetime||

        ----

        It may be useful to limit coupons to a particular billing cycle or set of cycles. An example is a 50% off first month coupon. You certainly wouldn't want to give 50% off the first year. I imagine the interface looking very much like the package pricing interface.

        It seems that this should be an optional feature controlled whether or not any billing cycles are set for the coupon. If they are not it should continue to function how it does now.

        Attached is an example of what it could look like.
        Coupons should be updated to allow for a set of terms/periods to be defined for which the coupon must apply to to be used. These terms/periods must *always* apply regardless of any additional limitations.

        # Create a new table for coupons called *coupon_terms*
        #* `id` PRIMARY KEY
        #* `term` SMALLINT(5)
        #* `period` ENUM('day','week','month','year','onetime')
        # Update the add/edit coupon pages to add a new section for _Coupon Terms_ beneath _Limitations_
        #* The coupon terms should include a description... something to the effect that coupons can only be applied if the service ordered is one of the selected terms/periods. If none are enabled, then the coupon applies to *ALL* possible terms/periods (i.e. the default behavior).
        ||Enabled||Period||Terms||
        |Checkbox|Day|[Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Day, 3 Days, and 4 Days]|
        |Checkbox|Week|[Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Week, 3 Weeks, and 4 Weeks]|
        |Checkbox|Month|[Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Month, 3 Months, and 4 Months]|
        |Checkbox|Year|[Input box where you can type a CSV list of terms (e.g., "1,3,4") meaning 1 Year, 3 Years, and 4 Years]|
        |Checkbox|Onetime|[Blank section]|
        #* Unchecking a checkbox, or deleting all items in the _Terms_ section has the same effect--deleting the entries from the *coupon_terms* table. You can have the UI update itself to check/uncheck the checkbox whether any terms are set.
        #* (optional) It would probably be useful to have some UI JS utility that displays the terms as labels in an input box, similar to marketplace tags, rather than a pure-text CSV list.
        # Update *ALL* locations that coupons are applied/checked to be applied, or otherwise validated to ensure that the selected terms/periods are considered as limitations to the coupon's use. This occurs *at minimum* in the Coupons model and the Pricing Presenters. Check all locations.


        ----

        It may be useful to limit coupons to a particular billing cycle or set of cycles. An example is a 50% off first month coupon. You certainly wouldn't want to give 50% off the first year. I imagine the interface looking very much like the package pricing interface.

        It seems that this should be an optional feature controlled whether or not any billing cycles are set for the coupon. If they are not it should continue to function how it does now.

        Attached is an example of what it could look like.
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.2.0 Sprint 2 [ 47 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        tyson Tyson Phillips (Inactive) made changes -
        Fix Version/s 4.2.0-b1 [ 11014 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        Automated transition triggered when Jonathan Reissmueller created a branch in Stash -
        Status Open [ 1 ] In Progress [ 3 ]
        jonathan Jonathan Reissmueller made changes -
        Remaining Estimate 0 minutes [ 0 ]
        Time Spent 1 hour, 27 minutes [ 5220 ]
        Worklog Id 10389 [ 10389 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 hour, 27 minutes [ 5220 ] 3 hours, 38 minutes [ 13080 ]
        Worklog Id 10400 [ 10400 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 3 hours, 38 minutes [ 13080 ] 5 hours, 44 minutes [ 20640 ]
        Worklog Id 10401 [ 10401 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 5 hours, 44 minutes [ 20640 ] 6 hours, 44 minutes [ 24240 ]
        Worklog Id 10410 [ 10410 ]
        tyson Tyson Phillips (Inactive) made changes -
        Sprint 4.2.0 Sprint 2 [ 47 ] 4.2.0 Sprint 2, 4.2.0 Sprint 3 [ 47, 48 ]
        tyson Tyson Phillips (Inactive) made changes -
        Rank Ranked higher
        jonathan Jonathan Reissmueller made changes -
        Time Spent 6 hours, 44 minutes [ 24240 ] 7 hours, 54 minutes [ 28440 ]
        Worklog Id 10420 [ 10420 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 7 hours, 54 minutes [ 28440 ] 1 day, 1 hour, 56 minutes [ 35760 ]
        Worklog Id 10422 [ 10422 ]
        Automated transition triggered when Jonathan Reissmueller created pull request #341 in Stash -
        Status In Progress [ 3 ] In Review [ 5 ]
        Resolution Fixed [ 1 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 day, 1 hour, 56 minutes [ 35760 ] 1 day, 4 hours, 14 minutes [ 44040 ]
        Worklog Id 10426 [ 10426 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 day, 4 hours, 14 minutes [ 44040 ] 1 day, 5 hours, 54 minutes [ 50040 ]
        Worklog Id 10427 [ 10427 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 1 day, 5 hours, 54 minutes [ 50040 ] 2 days, 1 hour, 14 minutes [ 62040 ]
        Worklog Id 10428 [ 10428 ]
        tyson Tyson Phillips (Inactive) made changes -
        Time Spent 2 days, 1 hour, 14 minutes [ 62040 ] 2 days, 1 hour, 44 minutes [ 63840 ]
        Worklog Id 10531 [ 10531 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 2 days, 1 hour, 44 minutes [ 63840 ] 2 days, 3 hours, 35 minutes [ 70500 ]
        Worklog Id 10533 [ 10533 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 2 days, 3 hours, 35 minutes [ 70500 ] 2 days, 7 hours, 1 minute [ 82860 ]
        Worklog Id 10538 [ 10538 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 2 days, 7 hours, 1 minute [ 82860 ] 3 days, 3 minutes [ 86580 ]
        Worklog Id 10540 [ 10540 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 3 days, 3 minutes [ 86580 ] 3 days, 1 hour, 23 minutes [ 91380 ]
        Worklog Id 10547 [ 10547 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 3 days, 1 hour, 23 minutes [ 91380 ] 3 days, 1 hour, 43 minutes [ 92580 ]
        Worklog Id 10550 [ 10550 ]
        jonathan Jonathan Reissmueller made changes -
        Time Spent 3 days, 1 hour, 43 minutes [ 92580 ] 3 days, 3 hours, 29 minutes [ 98940 ]
        Worklog Id 10556 [ 10556 ]
        Automated transition triggered when Tyson Phillips (Inactive) merged pull request #341 in Stash -
        Status In Review [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            tyson Tyson Phillips (Inactive)
            Reporter:
            jonathan Jonathan Reissmueller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 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 - 3 days, 3 hours, 29 minutes
              3d 3h 29m

                Agile