fix: resolve page classification clashes [CDD-3498]

[jrdh]

Description

Topic and metric documentation child pages are non-public capable pages which therefore must have the non-public tick box, page classification, theme, sub-theme, topic, and metric associated with them to allow us to filter based on a user's permissions if the page is set to non-public.

In the original implementation of this, there was a bug where the metric field on the documentation child page model was being reused as it already existed. Conceptually this is incorrect as it should have been a separate field, but this approach also broke the metric child pages as they were expecting the metric to be stored as the full name of the metric whereas the non-public logic was expecting an ID. To solve this, the metric field has been removed because it's not currently in scope for page permissions and was only half implemented anyway.

To future proof non-public pages and also reduce repeated code (the topic and metric documentation child models have the same code copied in both) a new non-public abstract page model has been created which carries the core fields required for a non-public page. The topic and metric documentation child page models are now subclasses of this page.

Additionally, the theme, sub-theme, and topic fields have been renamed with the prefix page_ to avoid clashing with possible fields on subclasses. This aligns with the page_classification that already existed.

On top of this, the admin form for non-public fields has been centralised into a class as well to again avoid copied code. This presents the fields slightly differently to try and make the DPD editor user experience better - the public checkbox still shows as before but the classification, theme, sub-theme, and topic are grouped together and collapsed by
default to reduce clutter when they are likely only to be set once and not looked at again. These could be moved into a tab potentially if we wanted to but for the moment this change is better than before and makes it clearer for users.

This means this:

Now looks like this:

There is also a performance fix within this PR which I tried to split out but couldn't as it's related to the changes described above. Specifically, the populating of choices on the metric documentation child model is moved from the __init__ method to the admin form's __init__. This means we don't pull metric names from the db on every instantiation of a new metric documentation object (which for example could happen 80+ times (depends how many
metric documentation child pages you have) just through the get pages endpoint (because we use .specific()).

Finally, to facilitate the field changes on the topic and metric documentation child pages, migrations have been created. These are written as renames to try and avoid data loss. However, any metric documentation child pages which were created with the old code will need to fixed as their database entries will be incorrect (they'll be using an ID in the metric column instead of a string name). This has been fixed in the bootstrap code as well as the issue was present there too.

Fixes #CDD-3498

---

Type of change

Please select the options that are relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Tech debt item (this is focused solely on addressing any relevant technical debt)

---

Checklist:

• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests at the right levels to prove my change is effective
• I have added screenshots or screen grabs where appropriate
• I have added docstrings in the correct style (google)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud