Figure out why the pulse filters don't show up in the list of permissions

[Pomax]

Pulse filters show up in the list of snippets:

But they are nowhere to be found in the list of items that can be assigned permissions when creating/editing a group.

Code:

https:/mozilla/foundation.mozilla.org/blob/main/network-api/networkapi/wagtailpages/pagemodels/pulse.py#L9

[richbrennan]

Findings so far:

• Pulse Filter shows in Group permissions locally with production DB backup, but not on staging or production

• Clearing the staging cache and then restarting the dynos doesn't help

This seems to be something to do with permissions not being present on staging/production. This Group form code fetches the registered permissions for snippets when constructing the 'Object permissions' list on the Group admin page.

When recreating the call in the shell locally vs staging the list of permission objects is empty on staging:

Local:

>>> from django.contrib.contenttypes.models import ContentType
>>> from networkapi.wagtailpages.pagemodels.pulse import PulseFilter
>>> ct = ContentType.objects.get_for_model(PulseFilter)
>>> Permission.objects.filter(content_type=ct)
<QuerySet [<Permission: wagtailpages | pulse filter | Can add pulse filter>, <Permission: wagtailpages | pulse filter | Can change pulse filter>, <Permission: wagtailpages | pulse filter | Can delete pulse filter>, <Permission: wagtailpages | pulse filter | Can view pulse filter>]>

Staging:

>>> from django.contrib.contenttypes.models import ContentType
>>> from networkapi.wagtailpages.pagemodels.pulse import PulseFilter
>>> ct = ContentType.objects.get_for_model(PulseFilter)
>>> Permission.objects.filter(content_type=ct)
<QuerySet []>

So to progress we need to investigate why the permissions don't appear to be present on staging and production.

[Pomax]

This is starting to smell like a migration file got updated in-place, where stage/prod had the class, then later it got switched to a snippet, but the migration that created the class got updated, rather than having a new migration that changed the data layout.

Although a prod copy should be identical in table data so if the databases look different after copying, we'll have to pick up the investigations there, first.

[bheasman]

Moving back to backlog as agreed in standup until we have a clear sense on Pulse strategy

[mtdenton]

Moving this up for Maintenance/bug issues

[tomusher]

In looking in to this, these permissions now seem to be present on both production and staging.

Looking at deployment logs, there was an error running migrations starting when these models were first added, meaning the full migration process (and contrib.auths post_migrate) was not running. This seemed to be fixed by a change on Jan 11, which allowed the migrations to succeed and the permissions were correctly generated.

[tomusher]

Created #9547 to prevent similar issues by exiting out of the release pipeline when commands fail.

[tbrlpld]

Thanks for looking into this @tomusher. I left one question on the PR, but only for my own learning 😅

[tbrlpld]

Merged and deployed. All is well. Thanks for this @tomusher.