Welcome to django-flexible-plans’s documentation!¶

Contents:

django-flexible-plans¶

Independent and reusable Plan, Subscription app used to build the Django Subscription Plan System

Django-Subscription-Plan-System

Status¶

Under heavy development. Not ready for use yet. Please feel free to join and contribute.

Documentation¶

The full documentation is at https://django-flexible-plans.readthedocs.io.

Quickstart¶

Install django-flexible-plans:

pip install django-flexible-plans

Add it to your INSTALLED_APPS:

INSTALLED_APPS = (
    ...
    'flexible_plans.apps.FlexiblePlansConfig',
    ...
)

Add django-flexible-plans’s URL patterns:

from flexible_plans import urls as flexible_plans_urls


urlpatterns = [
    ...
    url(r'^', include(flexible_plans_urls)),
    ...
]

Create Features PlanFeatures, Plans through the admin panel to let users activate their subscriptions.

Features¶

Plans have Features that describe them and what their subscribers can do or their quotas Users can subscribe to Plans and their Subscription can be activated, deactivated, renewed, prorated, upgraded or downgraded.

Roadmap¶

Configurable, swappable Plan Model, to customize the Plan Class behaviour
Dynamic imports from other app in the ecosystem to handle all the other aspects of having a plan subscription system
Multiple plan types, with support of any combination of quotas, features, permissions.
Multiple plan/subscription provider support

Running Tests¶

Does the code actually work?

source <YOURVIRTUALENV>/bin/activate
(myenv) $ pip install tox
(myenv) $ tox

Credits¶

Tools used in rendering this package:

Installation¶

At the command line:

$ easy_install django-flexible-plans

Or, if you have virtualenvwrapper installed:

$ mkvirtualenv django-flexible-plans
$ pip install django-flexible-plans

Usage¶

To use django-flexible-plans in a project, add it to your INSTALLED_APPS:

INSTALLED_APPS = (
    ...
    'flexible_plans.apps.FlexiblePlansConfig',
    ...
)

Add django-flexible-plans’s URL patterns:

from flexible_plans import urls as flexible_plans_urls


urlpatterns = [
    ...
    url(r'^', include(flexible_plans_urls)),
    ...
]

Documentation for the Code¶

Plan Models¶

The Plan Model is a concrete, swappable subclass of the abstract BasePlan.

BasePlan
Plan

class flexible_plans.models.plans.BasePlan(*args, **kwargs)[source]¶

BasePlan is TimeStamped, which means it holds a reference to dates of creation and modification. BasePlan is SoftDeletable, which means it becomes deactivated and not removed entirely (to keep a reference to subscribed plans which become soft-deleted and thus no more available).

BasePlan also can be visible and available. Plan is displayed on the list of currently available plans for user if it is visible. User cannot change plan to a plan that is not visible. Available means that user can buy a plan. If plan is not visible but still available it means that user which is using this plan already will be able to extend this plan again. If plan is not visible and not available, he will be forced then to change plan next time he extends an account.

BasePlan is defined by its Features, which can be quotas, permissions on objects and features

static get_default_plan(cls)[source]¶: Shortcut to retrieve the default plan to be assigned if no plan is selected :param cls: :return: default Plan instance

get_features_dict()[source]¶: Retrieve a Dict of all the plan’s feature to pass through validators :return: {feat.codename: feat.value}

static get_provider_choices()[source]¶: Scans settings to look for configured payment providers and serve them as choice list :return: [PaymentProvider]

class flexible_plans.models.plans.Plan(*args, **kwargs)[source]¶

Single plan defined in the system. A plan can be customized (for specific users), which means that only those users can purchase this plan and have it selected.

exception DoesNotExist¶

exception MultipleObjectsReturned¶

class flexible_plans.models.plans.PlanFeature(id, plan, feature)[source]¶

exception DoesNotExist¶

exception MultipleObjectsReturned¶

Feature Models¶

There are a few Feature concrete, swappable subsclasses of the abstract BaseFeature to represent different types of features with different logic:

BaseFeature
Feature
MeteredFeature
CumulativeFeature
PermissionFeature

class flexible_plans.models.features.BaseFeature(*args, **kwargs)[source]¶

BaseFeature Abstract Model defines the feature behaviour

get_validator()[source]¶: Get the proper validator from the ValidatorPolicy registry :return: Validator object that matches with the feature codename or None

log_usage()[source]¶: Logs the feature usage, against the correct validator

class flexible_plans.models.features.CumulativeFeature(id, name, codename, description, feature_ptr, usage)[source]¶

exception DoesNotExist¶

exception MultipleObjectsReturned¶

class flexible_plans.models.features.Feature(*args, **kwargs)[source]¶

Feature default implementation Feature is a swappable model to allow client to use their own Feature model. It is recommended to subclass BaseFeature to inherit all the behaviours and base fields. Being Feature a base class of other specific Feature Classes, it support an InheritanceManager to return all kinds of objects on Feature querysets

exception DoesNotExist¶

exception MultipleObjectsReturned¶

class flexible_plans.models.features.MeteredFeature(id, name, codename, description, feature_ptr, units, usage)[source]¶

exception DoesNotExist¶

exception MultipleObjectsReturned¶

Views¶

All the CRUD views are defined and available. Plus, specific views for the Plan management are available

Contributing¶

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

Types of Contributions¶

Report Bugs¶

Report bugs at https://github.com/tobia.ghiraldini/django-flexible-plans/issues.

If you are reporting a bug, please include:

Your operating system name and version.
Any details about your local setup that might be helpful in troubleshooting.
Detailed steps to reproduce the bug.

Fix Bugs¶

Look through the GitHub issues for bugs. Anything tagged with “bug” is open to whoever wants to implement it.

Implement Features¶

Look through the GitHub issues for features. Anything tagged with “feature” is open to whoever wants to implement it.

Write Documentation¶

django-flexible-plans could always use more documentation, whether as part of the official django-flexible-plans docs, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback¶

The best way to send feedback is to file an issue at https://github.com/tobia.ghiraldini/django-flexible-plans/issues.

If you are proposing a feature:

Explain in detail how it would work.
Keep the scope as narrow as possible, to make it easier to implement.
Remember that this is a volunteer-driven project, and that contributions are welcome :)

Get Started!¶

Ready to contribute? Here’s how to set up django-flexible-plans for local development.

Fork the django-flexible-plans repo on GitHub.

Clone your fork locally:

$ git clone git@github.com:your_name_here/django-flexible-plans.git

Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development:
```
$ mkvirtualenv django-flexible-plans
$ cd django-flexible-plans/
$ python setup.py develop
```
Create a branch for local development:
```
$ git checkout -b name-of-your-bugfix-or-feature
```
Now you can make your changes locally.
When you’re done making changes, check that your changes pass flake8 and the tests, including testing other Python versions with tox:
```
$ flake8 flexible_plans tests
$ python setup.py test
$ tox
```
To get flake8 and tox, just pip install them into your virtualenv.

Commit your changes and push your branch to GitHub:

$ git add .
$ git commit -m "Your detailed description of your changes."
$ git push origin name-of-your-bugfix-or-feature

Submit a pull request through the GitHub website.

Pull Request Guidelines¶

Before you submit a pull request, check that it meets these guidelines:

The pull request should include tests.
If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring, and add the feature to the list in README.rst.
The pull request should work for Python 2.6, 2.7, and 3.3, and for PyPy. Check https://travis-ci.org/tobia.ghiraldini/django-flexible-plans/pull_requests and make sure that the tests pass for all supported Python versions.

Tips¶

To run a subset of tests:

$ python -m unittest tests.test_flexible_plans

Credits¶

Development Lead¶

Tobia Ghiraldini <tobia.ghiraldini@ninjabit.com>

Contributors¶

None yet. Why not be the first?

History¶

0.1.0 (2019-01-23)¶

First release on PyPI.