Now the banner component accepts either a banner or a section and loads
the banner if it's a section, so we don't have to add the `@banners`
variable in several controllers.
We have three filters: "pending", "all" and "reviewed". Where "pending"
is the default one.
Now we are rendering the `shared/_filter_subnav` partial we need to stub
helper methods defined at the controller and the helper methods that
rely on the request parameters to test the component.
These cards will be displayed in the SDG homepage.
Note there seems to be a strange behavior in cancancan. If we define
these rules:
can :manage, Widget::Card, page_type: "SDG::Phase"
can :manage, Widget::Card
The expected behavior is the first rule will always be ignored because
the second one overwrites it. However, when creating a new card with
`load_and_authorize_resource` will automatically add `page_type:
"SDG::Phase"`.
Similarly, if we do something like:
can :manage, Widget::Card, id: 3
can :manage, Widget::Card
Then the new card will have `3` as an ID.
Maybe upgrading cancancan solves the issue; we haven't tried it. For now
we're defining a different rule when creating widget cards.
We use a different logic to load the card depending on the controller
we're using, and then share the rest of the code. This way we simplify
the code a bit, since we don't have to check for the page_id parameter.
Note we're using the code instead of the ID to get the goal in the URL.
IMHO this is what most people would expect; visiting a URL with a "7"
takes you to SDG number 7, and not to the one with "7" as a database ID.
In order to avoid tests (either automated tests or manual tests) passing
by coincidence due to the goal ID and the goal code being the same, I'm
shuffling the codes before entering them in the databse.
I've tried using `resolve` in the routes so the code is automatically
taken into account, but it doesn't work since `resolve` cannot be used
inside a namespace, and here we're within the `sdg` namespace.
Note using `params[:relatable_type].classify` is recognized as a
security risk by some tools. However, it's a false positive, since we've
added constraints to the URL so that paramenter can only have the values
we trust.
There are some sections where we are not reusing it:
* The budget investments search is completely different, so this
component isn't appropriate there
* Booth assignment and officers are slightly different, and I'm not
entirely sure it's safe to refactor these cases
