Add Contact Topics (#5388)

[elasticspoon]

Purpose

Fixes #5388

Models

Adds 2 Models, modifies 2 existing models:

Why?

I tried an approach where every topic would be a single record, however, that leads to a lot of duplicated information in the database. Saving a details with every record would result in a lot of extra data.

Technically, we could store details and question as single objects and have each ContactTopic reference then, however, that result in issues with cross org changes to those records. Given in production there are 10 Orgs and 44k Cases that optimization did not seem worth it.

Testing

• casa_org: checks that correct defaults are generated
• case_contact: checks the creation method works
• contact_topic: checks that correct defaults are used and invalid values do not pass

Controllers

Added contact_topic controller. Call don't happen directly, happen as nested attributes from orgs
Added policy for changing contact topics: only same org admin can CRUD.
Generation of new topics happen after org creation in controller

Tests

• contact_topics: test new, edit, create, update and soft delete
• form: tests update functions correctly during details, notes and final steps
• case_contacts: checks that new case_contacts copy org topics
• casa_org: check that topics can be edited, created

policy:

• only same org admins should be able to change topics

Views

Admin Panel:

Delete Modal:

Form Details:

Form Notes:

Tests

Systems tests focused on checking the javascript: making sure the dropdowns, read more/less work

Components

The admin panel called for a kebab menu and a modal. I chose to make them generic and extract them to ViewComponents.

DropdownMenu Component: added a generic drop down menu component to wrap bootstrap behavior. It expects a body of items and have options to change how the button for the dropdown itself appears. The default if no icon is given and label is disabled is a kebab style icon. (I would have prefered to not add the svg but the icon pack did not include that icon)

Modal Component:

• group: combines a header, body and footer into a working modal. requires only the header or body + footer. needs a open button or link separately to open it.
• header: generic header with optional icon and text. if given content that will override
• body: takes text as string or array of strings and wraps in p tags. if given content that will override
• footer: has a close button, take content which it will render next to the close button
• open button/link: button/link to open the modal. requires the id of the modal to work. take optional icon. content overrides.

Other Notes

[bcastillo32]

@elasticspoon do you need this approved and merged to continue with the original ticket? Let me know and I can help get that done.

[schoork]

@elasticspoon I would highly suggest adding in the views for the Casa Org portion of this. That will give you more information about the UX, which should drive the backend as much as possible.

[elasticspoon]

@schoork I have redone the models and such and added the org views. They are not complete yet but I think they give a general sense of the UX. I could not for the life of me figure out how to properly test policies. So those tests are currently incorrect. This PR has gotten extremely large, so I would love some more input before I move in any direction.

[schoork]

Overall it's looking great, and I can tell you've put a lot of time in this.

[elasticspoon]

@schoork I'll fix the stuff you mentioned. I didn't actually you realize you would go straight to UX tests. Most of the view stuff is pretty incomplete because I didn't want to build on models that I was unsure about.

[elasticspoon]

After some clarification on how topics are represented in reports I went back on the idea of sorting topics in alphabetical order. Casa wants them in a particular order for the reports which is not alphabetical.

Depending on how it goes there might be need to implement reordering of topics. That said, apparently topics rarely change so that should not be much of an issue.

[schoork]

These change order when you move through and back in the form. A little confusing. Can we do alphabetical?

[schoork]

This seems pretty restrictive to what can go in to the body. Why not just insert what the content is and do something like this when rendering...?

<% component.with_body do %>
  <p>
    This topic and its related questions...
  </p>
  <p>
    This will not affect case contacts that...
  </p>
<% end %>

[elasticspoon]

You can do that, currently if you provide a block it overrides and text is optional.

It's just if you provide text as a string or array of strings. It gets wrapped in ptags.

casa/spec/components/modal/body_component_spec.rb

Line 20 in 897d5f7

it "renders the body with content" do

[schoork]

I don't think you're using this anymore. Is there a reason to keep this?

[elasticspoon]

The idea was to provide two different options to open the model. As a button tag and a link tag, they format slightly differently.

In most situations you would want to use a button because it's semantically correct. But in some situations you're forced to use a link like in my case. So I wanted to have both.

[schoork]

This is a really flaky test. I think I wrote it. And I'm fine with you removing it. Maybe change it to an xit so we know to re-write it in the future.

[schoork]

@elasticspoon This looks really good! A few extra notes. Nothing blocking that I can see. Ready when you are to get this across the line.

[elasticspoon]

@schoork Cleaned up the remaining comments. I think we are good to go with this part. I will work on the report generation in a new PR.