This patch makes it possible for Waffles to automatically create switches upon usage so you don't have to manually create them.

This fixes ticket https://github.com/jsocol/django-waffle/issues/44

Closes #354.

Django 3 "remove[s] private Python 2 compatibility APIs", which is to say it removes a number of utility methods that were either already provided by six or otherwise were used in bridging the old and the new python. This pull request makes django-waffle work with Django 3 by making just 3 changes.

1. Add six to the requirements.
2. Replace the result of callingavailable_attrs with functools.WRAPPER_ASSIGNMENTS (cf https://docs.djangoproject.com/en/2.2/_modules/django/utils/decorators/)
3. Use the python_2_unicode_compatible provided by six rather than the one vendored with django.

Not sure what the protocol is on bumping the version and amending the changelog; would be happy to do both.

In an environment with sufficiently high traffic and DB replication set up, there is a race condition with switches and samples where when an update is immediately followed by a read, the read will get a stale value from the DB replica and cache it.

This fixes the race condition by ensuring that switches and samples are always read from the write DB.

• Export signals handling to models.py
• Export all settings to one unique file
• Export keyfmt to utils.py
• We are not importing models anymore in init.py which can cause in several cases multiple fails from django.apps Registry
• Refactor unittests using django own DiscoverRunner

Currently all tests pass except SwitchTests.test_no_query which I'm missing something why we should make on query as we don't cache query from Django itself (we only cache proxies from waffle.__init__.py).

I'm available if you want more information.

This PR is currently under development and not available to merge btw.

I get a circular import problem in my Django 1.5 app caused by waffle getting the user model incorrectly.

From the docs:

When you define a foreign key or many-to-many relations to the User model, you should specify the custom model using the AUTH_USER_MODEL setting.

waffle.compat.User is used to define a ManyToManyField.

• Ensure that new switch is not created unless the --create flag is passed.
• Add tests to ensure no regression for the --create fix on all commands.
• Add separate positional arguments for commands (instead of "positionals") to improve the --help documentation.

To answer @clintonb's question in #245—perhaps it's already obvious—this project has not been high on my list lately, due to any number of factors (I don't write a lot of Python day-to-day at the moment, weekends have been nice outside lately, others).

To keep the project alive will need the support of more maintainers. I love to add two or three folks to GitHub and PyPI who

1. use Waffle in their day jobs / active projects;
2. have at least opened a PR, even if I haven't merged it;
3. want to see Waffle improve, hopefully beyond their immediate needs; and
4. care about making open source a welcoming and inclusive space.

If you'd like to help out (I suspect a couple of folks from #245, #243, #241, #226 and other recent issues might be willing, but don't want to assume) please comment here or email me, and let me know your PyPI username.

Hi James,

Just a small one here to get the project's test suite up to current speed.

Tox now runs the test suite successfully under the latest Django 1.10.x and Python 3.6 environments.

As part of making the tests run under the new environement, the tests were updated to account for deprecated behaviour in Django. Only thing of note really is that render_to_response was removed in favour of render as render_to_response is 'likely pending deprecation' as of Django 1.10.

Thanks for all your work on this, we use it extensively at Yunojuno. If the 1.10 stuff could get a release on PyPI that'd be super; if there's anything blocking that just let us know.

Fixes #224.

cheers, Darian

If you're using Memcache as your cache backend and have a space in your Flag, Switch or Sample name memcache throws and error on saving. MemcachedKeyCharacterError: Control characters not allowed

This is because with Memcache you can't have spaces in the key.

Avoid conflicts with other tags for example the switch/case template tag.

This can be done by defining WAFFLE_FLAG_TAG_NAME, WAFFLE_SWITCH_TAG_NAME and/or WAFFLE_SAMPLE_TAG_NAME in the settings.py. This is all optional.

Flags, Switches and Samples may be scattered throughout templates, backend code or across mulitple frontend clients. This patch provides a user with the option of having waffle create a missing Flag, Sample or Switch when one is requested but does not exist.

The goal of this change is to save operators time by removing the need to search through code for flag/switch/sample names and to reduce communication requirements accross teams with of multiple developers with multiple environments that might require the creation of a flag/switch/sample in the database of every environment code is run in.

Behavior Changes

Old Behavior

1. Flag/Switch/Sample is requested 2a. If found in db evaulate what the value should be for request 2b. If missing return (FLAG|SWITCH|SAMPLE)_DEFAULT value

New Behavior

1. Flag/Switch/Sample is requested 2a. If found in db evaulate what the value should be for request 2b. Create Flag/Switch/Sample with value (FLAG|SWITCH|SAMPLE)_DEFAULT
2. Return (FLAG|SWITCH|SAMPLE)_DEFAULT for this request, subsequent requests will be served using the value from the cache/db

Further Discussion

• #44 (https://github.com/jsocol/django-waffle/issues/44)
• #50 (https://github.com/jsocol/django-waffle/issues/50)

Future Work

This change intentionally narrowly scoped and as such does not provide a mechanism to set a default value other than (FLAG|SWITCH|SAMPLE)_DEFAULT for individual objects that are not in the database although it could be expanded in the future to do so.

The problem

I ran into an error that occured due to a typo in the name of a waffle flag in my code. It would have been much better (IMO), and the bug would have been picked up much earlier, had flat_is_active failed hard for non-existent flags. Failing silently can be dangerous, and whilst I appreciate I can set WAFFLE_LOG_MISSING_FLAGS to logging.ERROR to increase visibility, this will still not cause a request to fail hard. In development environments, I tend not to pay particular attention to logs unless I'm specifically looking for something. However, a hard failure would pick up the typo before it makes it way to production.

Is this configuration bloat??

Obviously, not everyone would want the behaviour I suggest above (quite apart from the fact that it would be a breaking change). As such, an extra configuration setting such as WAFFLE_RAISE_MISSING_FLAGS would be needed. There are currently quite a lot of configuration settings for waffle. For each of FLAG, SWITCH and SAMPLE we have:

• WAFFLE_*_DEFAULT
• WAFFLE_CREATE_MISSING_*S
• WAFFLE_LOG_MISSING_*S

With this in mind, we probably do not want an extra configuration setting. There are no doubt other behaviours that other uses would wish for in the case of a missing flag, and it's untenable to provide a new setting for each of them.

A proposed solution

Instead of introducing a new config setting, I propose that we replace WAFFLE_CREATE_MISSING_*S and WAFFLE_LOG_MISSING_*S with a new setting WAFFLE_HANDLE_MISSING_*S which would be a string that points to a function that would be called when an entity is missing. For example:

# settings.py
WAFFLE_HANDLE_MISSING_FLAGS = "some_file.handle_missing_flags"

# some_file.py
def handle_missing_flags(name):
    # potentially log a message, create a flag and do anything else you want
    # optionally return a flag

(If a flag is returned the flag would be cached, and the value from the flag would be used, otherwise the default value would be used - as is the current behaviour).

This would have several advantages.

• The default function would use the existing WAFFLE_CREATE_MISSING_*S and WAFFLE_LOG_MISSING_*S settings so that introducing the setting would result in no change in behaviour.
• We can then utilise the django checks framework to provide warnings that the old settings will eventually be deprecated, and in time update those warnings to errors. Suitable documentation could also be provided to guide migration to the new system (although this should be reasonably straight-forward). This will mean a pleasant deprecation timeline.
• This allows users greater flexibility to provide the individual functionality they want.
• This actually reduces the number of configuration settings whilst protecting against future settings bloat.

(Part of me would like to subsume WAFFLE_*_DEFAULT into the new setting too, but seeing as the default values are used in WaffleJS this would be difficult.)

If there is support for this proposition I would be more than happy to submit a PR. I look forward to any feedback on the above.

Up until now, the override_flag test util was only useful to completely activate or deactivate a flag. It didn't allow to provide more customization for all the internal checks it makes, like evaluating if the request user is authenticated or staff.

This change provides that functionality, without breaking the current API, to avoid breaking changes. Now, users can provide more granular arguments to override_flag, for a more flexible flag testing.

Closes #439.

I am upgrading from django-waffle==0.19.0 to current django-waffle on Django 3.1. I am getting the above TypeError which seems to be related to the changes made in #447. Are there any hints on how to modify existing code the deal with the read_only change?

The setting WAFFLE_SWITCH_MODEL allows using a custom switch model. It's documented on the Switches page but not on the Configuring Waffle page. For comparison, the equivalent setting for flags, WAFFLE_FLAG_MODEL, is documented on both the Flags and Configuring Waffle pages.

Perhaps there are other settings missing from the Configuring Waffle page? I haven't checked.

It would be very useful if testing utils such as override_switch and override_flag were available for pytest style classes as class decorators. Is this feature somewhere on the road map?

Waffle currently has a view to expose flag state as Javascript via the WaffleJS endpoint.

But there are a number of use cases, e.g. backend API calls, where it would be preferable to expose that state in a serialized format like JSON.

For use cases like an audit dashboard, the view might also expose metadata such as the total number of active and and inactive flags of each type, and the number of stale flags (i.e. more than X days since last toggled).

I propose a new backend function that queries the database and returns this data, and a new endpoint that returns the data as JSON.