Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade License #24

Open
TimothyBJacobs opened this issue Mar 4, 2015 · 4 comments
Open

Upgrade License #24

TimothyBJacobs opened this issue Mar 4, 2015 · 4 comments
Assignees
Milestone

Comments

@TimothyBJacobs
Copy link
Member

Customer's need to have a way to easily upgrade from one license type to another license type.

This would probably be done in a similar manner to how we handle renewals. We will add an additional button to the Super Widget prompting people to upgrade their license if they have an existing license for this product.

The upgrade price would be the new price, minus the existing price.

@TimothyBJacobs TimothyBJacobs self-assigned this Mar 4, 2015
@TimothyBJacobs TimothyBJacobs added this to the 1.0 milestone Mar 4, 2015
@TimothyBJacobs
Copy link
Member Author

Editing upgrade paths is done in a product feature called Licensing Upgrades.

edit product upgrade paths view

A new upgrade path is created by clicking the plus icon. This will then reveal two select boxes for selecting the product and the variant.

edit product upgrade paths add new

@TimothyBJacobs
Copy link
Member Author

Upgrades are configured in a linear manner.

A user can upgrade to any configuration along the path forward from the level they are currently at.

When a user upgrades to another version discounts will be automatically applied. If there is a gap between the upgrade paths, the discounts will be applied sequentially to arrive at a final price.

@TimothyBJacobs
Copy link
Member Author

Upgrades will be stored as a custom post type. The post_parent field will be utilized to distinguish the order in which upgrade paths should be stored. They will be associated with a licensing product with the menu_order field.

Once a user has added an upgrade path contain a product different from the current product, they will no longer be able to add any other upgrade paths.

To summarize each upgrade path begins with the current product and variant with the lowest activation limit, and ends with a different product and its lowest activation limit variant.

@TimothyBJacobs
Copy link
Member Author

Thats a crap idea. The reverse should be how the data is stored. post_parent is used to associate an upgrade path with the product, and menu_order controls the order the upgrade paths can be utilized in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant