[#7811] Generalised category system

[gbp]

Relevant issue(s)

Part of #7811

What does this do?

Adds generalised category system, replacing the old PublicBodyCategory models.

Why was this needed?

So we can categorise requests.

Implementation notes

There is one minor changes to the old category feature. Due to how nested sets work categories can now only have one parent/heading.

This means:

1. I didn't add to Category the uniqueness validation which is on PublicBodyCategory#category_tag.

2. Some categories have been duplicated, for WDTK this means 27 categories with the same title as another will be created. I think this is a good compromise given the reduced code complexity and added flexibility of being able to reuse the new categories feature for InfoRequest easily.

[garethrees]

There is one minor changes to the old category feature. Due to how nested sets work categories can now only have one parent/heading… Some categories have been duplicated, for WDTK this means 27 categories with the same title as another will be created.

Could you paste a list of these?

[gbp]

Could you paste a list of these?

irb(main):002:0> PublicBodyCategory.all.select { _1.public_body_headings.count > 1 }.map(&:title).sort
=>
["Ambulance Services",
 "Approved regulators of legal services",
 "Areas of Outstanding Natural Beauty Conservation Boards",
 "Associations of Local Councils",
 "Dance companies",
 "Education authority",
 "Education regulators",
 "Financial regulators",
 "Groups of universities",
 "Health and Social Care Partnerships (Scotland)",
 "Health and social care regulators",
 "Health regulators",
 "Heraldic authorities",
 "Highways Operators",
 "Housing ALMOs",
 "Housing regulators",
 "Integrated Care Partnerships",
 "Integration Joint Boards",
 "Media regulators",
 "Military colleges",
 "Money laundering supervisory authorities",
 "Police regulators",
 "Telecommunications companies",
 "Theatres",
 "Transport regulators",
 "Utility regulators",
 "Veterans Advisory and Pensions Committees"]

[garethrees]

Looks good as discussed on call / demo.

Main thing is to make sure that we can add categories to many Taggable things in future. Seems like we should be able to push the currently hard-coded things referencing an explicit model into a concern:

# BEFORE:
Category.public_body_tree.each do |heading|

# AFTER: 
PublicBody.categories.each do |heading|

# BEFORE: In category
def self.public_body_root
  Category.roots.find_or_create_by(title: 'PublicBody')
end

def self.public_body_tree
  tree(public_body_root)
end


# AFTER: In categorisable
def self.category_root
  Category.roots.find_or_create_by(title: self.class.name)
end

def self.categories
  Category.tree(category_root)
end

[gbp]

@garethrees this has been reworked to address the concern we noticed the other day.

I have left the fixups so you can see what has been changed. But basically this is combination of the initial approach and the ideas we came up with when we discussed this.

Main difference is instead of switching to having a model_type column, I have left the PublicBody root category as the top-level parent. I noticed if the headings didn't have a parent then there would be no CategoryRelationship instances and no place to store position, so with a Category#model_type column we would also need a Category#root_position column which makes instance ordering more complex and would mean we needed separate parent and child category reordering controller actions. Leaving the root model category concept simplifies the model and controller actions.

[gbp]

Reviewed and approved on a call together.