Refactoring of settings variable names

CHANGELOG

@@ -1,8 +1,29 @@
 django-plans changelog
 ======================
 
-current dev
------------
+0.7
+---
+* Changes in plans.taxation.eu.EUTaxationPolicy to implement new EU VAT regulations (MOSS)
+* Clean up settings variables naming conventions prepending PLANS_ prefix:
+  * Renamed settings variable name TAXATION_POLICY to PLANS_TAXATION_POLICY
+  * Renamed settings variable name ISSUER_DATA to PLANS_INVOICE_ISSUER
+  * Renamed settings variable name PLAN_EXPIRATION_REMIND to PLANS_EXPIRATION_REMIND
+  * Renamed settings variable name PLAN_CHANGE_POLICY to PLANS_CHANGE_POLICY
+  * Renamed settings variable name PLAN_VALIDATORS to PLANS_VALIDATORS
+  * Renamed settings variable name CURRENCY to PLANS_CURRENCY
+  * Renamed settings variable name TAX to PLANS_TAX
+  * Renamed settings variable name TAX_COUNTRY to PLANS_TAX_COUNTRY
+  * Renamed settings variable name INVOICE_LOGO_URL to PLANS_INVOICE_LOGO_URL
+  * Renamed settings variable name INVOICE_NUMBER_FORMAT to PLANS_INVOICE_NUMBER_FORMAT
+  * Renamed settings variable name INVOICE_TEMPLATE to PLANS_INVOICE_TEMPLATE
+  * Renamed settings variable name INVOICE_COUNTER_RESET to PLANS_INVOICE_COUNTER_RESET
+  * Renamed settings variable name ORDER_EXPIRATION to PLANS_ORDER_EXPIRATION
+  * Renamed settings variable name PLAN_DEFAULT_GRACE_PERIOD to PLANS_DEFAULT_GRACE_PERIOD
+
+
+
+0.6+
+----
 * Changing `QuotaValidator` API. `ModelCountValidator` requires now to give `add` argument only as a kwarg.
 * Adding support for defining URL for plan, quota and pricing period that will act as a clickable pricing
   table header (requires schema migration)

conftest.py

@@ -35,19 +35,19 @@ def pytest_configure(config):
         TEMPLATE_DEBUG=True,
         USE_TZ=True,
         ALLOWED_HOSTS=['*'],
-        ISSUER_DATA={
+        PLANS_INVOICE_ISSUER={
             "issuer_name": "My Company Ltd",
             "issuer_street": "48th Suny street",
             "issuer_zipcode": "111-456",
             "issuer_city": "Django City",
             "issuer_country": "PL",
             "issuer_tax_number": "PL123456789",
         },
-        TAX=Decimal(23.0),
-        TAXATION_POLICY='plans.locale.eu.taxation.EUTaxationPolicy',
-        TAX_COUNTRY='PL',
-        CURRENCY='PLN',
-        PLAN_VALIDATORS={
+        PLANS_TAX=Decimal(23.0),
+        PLANS_TAXATION_POLICY='plans.taxation.eu.EUTaxationPolicy',
+        PLANS_TAX_COUNTRY='PL',
+        PLANS_CURRENCY='PLN',
+        PLANS_VALIDATORS={
             'MAX_FOO_COUNT': 'example.foo.validators.max_foos_validator',
         },
         EMAIL_BACKEND='django.core.mail.backends.console.EmailBackend',

demo/example/settings.py

@@ -131,7 +131,7 @@
     ('en', 'English'),
 )
 
-ISSUER_DATA = {
+PLANS_INVOICE_ISSUER = {
     "issuer_name": "My Company Ltd",
     "issuer_street": "48th Suny street",
     "issuer_zipcode": "111-456",
@@ -140,15 +140,15 @@
     "issuer_tax_number": "PL123456789",
 }
 
-TAX = Decimal('23.0')
-TAXATION_POLICY = 'plans.taxation.eu.EUTaxationPolicy'
-TAX_COUNTRY = 'PL'
+PLANS_TAX = Decimal('23.0')
+PLANS_TAXATION_POLICY = 'plans.taxation.eu.EUTaxationPolicy'
+PLANS_TAX_COUNTRY = 'PL'
 
-PLAN_VALIDATORS = {
+PLANS_VALIDATORS = {
     'MAX_FOO_COUNT': 'example.foo.validators.max_foos_validator',
 }
 
-CURRENCY = 'EUR'
+PLANS_CURRENCY = 'EUR'
 
 EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
 

docs/source/invoicing.rst

@@ -7,8 +7,8 @@ There is a built in support for creating invoices. This functionality brings pow
   * invoices can be marked as "requiring shipment"
   * invoices can be previewed as HTML or PDF
 
-Changing values of VAT tax and ISSUER_DATA in a living system
--------------------------------------------------------------
+Changing values of VAT tax and PLANS_INVOICE_ISSUER in a living system
+----------------------------------------------------------------------
 
 Your system can be running for a while. You can have a multiple orders and you could have issued a multiple invoices already.
 There can be a situation that you need to change after a while a tax
@@ -24,8 +24,8 @@ After changing those settings every new order, payment, invoice will use those n
     all your already created orders but not yet paid will have old tax. If this is what you don't want you
     need to cancel those orders manually and remember to contact your client that theirs orders were cancelled!
 
-    This  however is not a case with ``ISSUER_DATA`` change, because those data are taken in the same moment
-    of issuing invoice. Even an old order will use new ``ISSUER_DATA`` when invoicing a new payment.
+    This  however is not a case with ``PLANS_INVOICE_ISSUER`` change, because those data are taken in the same moment
+    of issuing invoice. Even an old order will use new ``PLANS_INVOICE_ISSUER`` when invoicing a new payment.
 
 Billing data
 ------------

docs/source/plans.rst

@@ -81,7 +81,7 @@ List of ``pricing`` periods
 **type**: Many-to-many with ``Pricing`` by ``PlanPricing``
 
 Many pricing periods can be defined for a given plan. For each entry there is a need of defining price. The currency
-of price is defined by ``settings.CURRENCY``.
+of price is defined by ``settings.PLANS_CURRENCY``.
 
 .. warning::
 

docs/source/plans_change.rst

@@ -2,7 +2,7 @@ Plan change policies
 ====================
 
 Changing (upgrading or downgrading) plan is another thing that can be highly customizable. You can choose which
-ChangePlanPolicy should be used via ``PLAN_CHANGE_POLICY`` settings variable.
+ChangePlanPolicy should be used via ``PLANS_CHANGE_POLICY`` settings variable.
 
 
 Plan change policy is a class that derives from ``plans.plan_change.PlanChangePolicy`` which should implement ``get_change_price(plan_old, plan_new, period)``. This method returns should return total price of changing current plan to new one, assuming that a given active period left on the account.

docs/source/quota_validators.rst

@@ -27,11 +27,11 @@ Account complete validation
 
 Complete account validation is needed when user is switching a plan (or in a general - activating a plan). The reason is that user account can be in the state that exhausting limits of new plan (e.g. on downgrade). Plan should not be activated on the user account until user will not remove over limit resources until the account could validate in limits of the new plan.
 
-In django-plans there is a common validation mechanism which requires defining ``PLAN_VALIDATORS`` variable in ``settings.py``.
+In django-plans there is a common validation mechanism which requires defining ``PLANS_VALIDATORS`` variable in ``settings.py``.
 
-The format of ``PLAN_VALIDATORS`` variable is given as a dict::
+The format of ``PLANS_VALIDATORS`` variable is given as a dict::
 
-    PLAN_VALIDATORS = {
+    PLANS_VALIDATORS = {
         '<QUOTA_CODE_NAME>' :  '<full.python.path.to.validator.class>',
         [...]
     }
@@ -40,7 +40,7 @@ First of all this variable defines all quota that should be validated on any pla
 
 .. note::
 
-    Please note that the only quota that can be added to ``PLAN_VALIDATORS`` are "limiting resources quota" and "limiting states" quota. Those are the kind of quota that conceptually can be validated within the database state. The third kind of quota ("limiting actions quota") are to be checked on to go when user is just using it's account and performing certain actions.
+    Please note that the only quota that can be added to ``PLANS_VALIDATORS`` are "limiting resources quota" and "limiting states" quota. Those are the kind of quota that conceptually can be validated within the database state. The third kind of quota ("limiting actions quota") are to be checked on to go when user is just using it's account and performing certain actions.
 
 Secondly each quota has a specific validator defined that is custom to your need of validations.