Release Notes

4.2.4

What's new?

  • FLAGS_STATE_LOGGING is now False by default to cut down on potentially unwanted noise (@darakian).

4.2.3

What's new?

4.2.2

What's new?

  • 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.

4.2.1

What's new?

4.2.0

What's new?

4.1.2

What's new?

4.1.1

What's new?

4.1

What's new?

4.0.3

What's new?

  • The system check introduced in 4.0.2 will no longer raise a ProgrammingError or an OperationalError when run pre-migration.

4.0.2

What's new?

  • Logging of non-existent conditions is now a Django system check.

4.0.1

What's new?

  • condition.check() returns a Falsy None instead of raising a TypeError when a configured condition has no function registered.

4.0

What's new?

  • The template functions flag_enabled and flag_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)

Upgrading

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
                ...
            ],
        }
    },
] 

3.0.2

What's new?

  • Requests are now optional the flag_enabled and flag_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)

3.0.1

What's new?

  • Django 2.1 is now supported.

3.0

Django-Flags is a fork of the Django-only components of the Wagtail-Flags feature flag library. This is the initial release.