Overhaul the admin and support for required condition

[willbarton]

This PR makes significant changes to the Wagtail-Flags admin to:

• support Django-Flags's recently introduced "required" conditions,
• make comprehending the conditions for a large number of flags comprehensible by moving them to subpages, and
• hide "boolean" conditions behind "enable"/"disable" buttons to make their intent clearer. "booleans" are intended to be simple on/off switches, so this tries to express that in the UI.

This looks like:

The great-big-list-of-all-flags-and-conditions is still available behind a WAGTAILFLAGS_ADMIN_BIG_LIST feature flag. If that flag is enabled, the new individual flag UI on the subpages will instead be displayed on the main flags page.

My current plan is, once this is reviewed, to release a beta, and we can get feedback on it in cf.gov. Once we decide on a direction between subpages and great-big-list, then we'll remove the WAGTAILFLAGS_ADMIN_BIG_LIST feature flag and release 4.1.

[Scotchester]

Eeeeee! Exciting stuff! I will try to review today, but one initial point of feedback: I think it would be nice to still show all conditions on a flag in the main list of flags.

[willbarton]

I think it would be nice to still show all conditions on a flag in the main list of flags.

I find that list overwhelming, personally, with all the flags in cfgov-refresh. What if it were hidden behind a disclosure, so it's still a click away, but not a page-load away?

[Scotchester]

I think it would be nice to still show all conditions on a flag in the main list of flags.

I find that list overwhelming, personally, with all the flags in cfgov-refresh. What if it were hidden behind a disclosure, so it's still a click away, but not a page-load away?

That would be a nice middle ground.

[willbarton]

@Scotchester I cannot find a way to marry the UI I have here with a disclosure that exposes all the conditions on the same page. I think I'd personally make a judgement that it's better to dig into what the conditions for a flag might be, but I'm going to hold off, because I think I want to move some of this functionality into Django-Flags, and that might inform a different approach here.

This PR is on hold until then.

[willbarton]

@Scotchester I think the best alternative is going back to having everything on one page:

[Scotchester]

That UI makes for a pretty crazy long page on cf.gov... but maybe that gives us some impetus to continue cleaning up our outdated flags :)

I'm good either way. I leave it to your judgment.

[willbarton]

@Scotchester I'll push up the one-big-list behind a... feature flag! And then we can get folks's opinions. I think I'm most comfortable leaving the default as a multiple-page drill drown.

[higs4281]

Does this load wagtailflags_admin twice?

[willbarton]

Indeed so.

[higs4281]

This is a wonderful improvement, especially for the common use case – a single on/off switch.

Because the on/off usage is so common, I prefer the simplified list option to cut down visual clutter.

I just had one minor question.

[schbetsy]

The plain language describing flag conditions is great. I'm into it. This is the only one that had me really confused:

"disabled when all required conditions are met" == enabled when the conditions aren't met? I didn't get to drill into the logic to figure it out

[willbarton]

@schbetsy Ah yes. That's meant to indicate that the flag is disabled even when all required conditions are met. COMPLAINT_INTAKE_TECHNICAL_ISSUES has an explicit boolean False condition that means that even if the required conditions are met, it'll still be disabled.

Does that make sense? Is there a better way to indicate that?

[schbetsy]

Ah, that makes sense. Maybe "disabled for all requests, regardless of whether conditions are met"?

[willbarton]

Excellent suggestion. That'll have to be in Django-Flags, actually. I'll PR and tag you there.

[willbarton]

PR is open at cfpb/django-flags#45

That'll be in Django-Flags 4.2.1, which I don't think is worth pinning explicitly in Wagtail-Flags (I'm going to leave the version pinning at >=4.2,<5.0), so I'm going to go ahead and merge this and release the beta so we can get some feedback in cfgov-refresh.