- Added Django 4.0 support (thanks @gregtap!)
- Added Django 3.2 support (thanks @dduong42!)
- Fixed the "path matches" condition validator to allow any valid regular expression.
- Added
enable_flag
anddisable_flag
functions. - Added
enable_flag
anddisable_flag
management commands.
- Added defaults for
FlaggedViewMixin
'skwargs
(by @jackton1)
- Added Django 3.1 support
- Added Django 3.0 support
- Added validator support to ensure that the values that flag conditions test against are valid.
- Deprecated the optional
flags.middleware.FlagConditionsMiddleware
in favor of always lazily caching flags on the request object.
- Django Flags 4.1 deprecated support for using a single dictionary to hold key/values of conditions for a settings-based feature flag, and this has been removed. Use a list of dictionaries or tuples instead.
- Removed support for Django 1.11.
FLAGS_STATE_LOGGING
is nowFalse
by default to cut down on potentially unwanted noise (@darakian).
- Removed the word "optional" to describe non-required conditions in the Flag Conditions Debug Toolbar panel.
- Fixed a bug where if a flag was defined in multiple sources the conditions defined in subsequent sources would not be evaluated. This means (with the default sources) if a flag is defined in Django settings and has conditions defined the database, only the settings conditions would be evaluated.
- Made the language around optional boolean conditions with required conditions clearer in the Flag Conditions Debug Toolbar panel
- Added optional Django Debug Toolbar panels to list all flag conditions and to report flag checks for a request.
- Added flag state check logging and
FLAGS_STATE_LOGGING
setting to enable it. - Modified flag state checking to raise an
AppRegistryNotReady
if an attempt to check flag state is made before the app registry is ready. - Modified flag view decorators to warn if a fallback view do not take the same arguments as the flag view.
- Added support for Django 2.2 and Python 3.7 (Chris Adams).
boolean
andanonymous
conditions now accept multiple possible string representations of truth as their values.parameter
conditions now accept possible parameter values.
- Added the option to specifiy required conditions that must always be met.
- Deprecated support for using a single dictionary to hold key/values of conditions for a settings-based feature flag. Support will be removed in Django-Flags 5.0. Use a list of dictionaries or tuples instead.
- Added a
before date
condition that is met whenever the current date is before the expected date.
- The system check introduced in 4.0.2 will no longer raise a
ProgrammingError
or anOperationalError
when run pre-migration.
- Logging of non-existent conditions is now a Django system check.
condition.check()
returns a FalsyNone
instead of raising aTypeError
when a configured condition has no function registered.
- The template functions
flag_enabled
andflag_disabled
in both Django and Jinja2 templates now support taking keyword arguments that could be used by custom conditions. - Jinja2 template functions are now available via a Jinja2 extension that can be included in
settings.py
. - The optional
flags.middleware.FlagConditionsMiddleware
has been added to ensure that all feature flag checks throughout single request cycle use the same flag conditions. - Support for specifying the source of feature flags in
settings.py
has been added to allow further customization and the potential to limit flags to settings or database-only. - The "user" condition now supports custom user models. (@callorico)
Django-Flags 4.0 introduces backwards-incompatible changes for users of Jinja2 templates.
Previously Django-Flags provided flags.template_functions.flag_enabled
and flags.template_functions.flag_disabled
functions that had to be registered in the Jinja2 environment downstream. The Django-Flags documentation recommended doing so in jinja2.Environment.globals.update()
. flags.template_functions
has been removed in Django-Flags 4.0.
Jinja2 function registration is now handled by a flags.jinja2tags.flags
Jinja2 extension. To use Django-Flags 4.0 with Jinja2 templates, the TEMPLATES
setting in settings.py
should to be modified to include the extension:
TEMPLATES = [
{
'BACKEND': 'django.template.backends.jinja2.Jinja2',
...
'OPTIONS': {
'extensions': [
...
'flags.jinja2tags.flags', # add this line to your existing settings
...
],
}
},
]
- Requests are now optional the
flag_enabled
andflag_disabled
template tags. - Flag state form conditions are now bound when the form is created to ensure all custom conditions are available on the form. (@callorico)
- Django 2.1 is now supported.
Django-Flags is a fork of the Django-only components of the Wagtail-Flags feature flag library. This is the initial release.