populatetools/gobierto

Plataforma de gobierno abierto open source

gobierto's Issues

Admin namespace: Sites management

Concept

TBD

Check-list

• Site management: Create, Update, switch statuses.
• Draft status concept.
• Module assignments.
• Extra fields management.

Admin namespace preparations

Here's a brief checklist:

• Admin model
• admin namespace
• Authentication and authorization
• Starting admin layout

Admin namespace: Users management

Concept

TBD

Check-list

• User list
• User support actions
• Census data bulk load

Set up Simplecov to measure test coverage

Motivation

Now that we have some foundations in place, we can start measuring how much of the codebase is not exercised when running tests, so that we can identify and mitigate risks when making changes.

Check-list

• Add the simplecov gem as a dependency: https://github.com/colszowka/simplecov.
• Set it up at test/test_helper.rb.
• Consider defining Simplecov's test filters and groups.
• Integrate a reporting service like Codecov, which has a free plan for open source projects. Here are some integration notes: https://github.com/codecov/example-ruby.
• Configure Codecov's notification channels.
• Configure our CI service (CircleCI) to report coverage results after each build by adding the Codecov's upload token from https://codecov.io/gh/populatetools/gobierto-dev.
• Run coverage only on demand.
• Make sure we're performing test coverage reporting to Codecov only on CI builds by checking the CI env variable.
• Add some docs on how to measure test coverage in local builds by setting the corresponding env variable.
• Add badge in README.

Handle Elasticsearch indices in test environment

As we discussed, it would be handy to include some fixtures providing a basic amount of data to populate™ the gobierto-budgets Elasticsearch indices, to be able to perform some end-to-end testing against them.

It could be also loaded in development environment as part of the script/setup command.

/cc @ferblape

Consultations module bootstrap

TBD

Check-list:

• Analysis and definition
• Starting data model implementation
• Gobierto module set up
• Starting Admin interactions
• Starting User interactions

Budget categories localization

Budget categories need to be localized. In order to achieve that we need to follow the follwing steps:

1 - use a collection from the big indexer, instead of a local index

2 - parameterize the collection depending on the site locale (each locale has a collection)

Password protected user control

Implement a reusable user control. It can be found here, and looks like in this screenshot:

Autocomplete site locations

Site entity association will be available, for the moment, just for municipalities.

To get the list of municipalities we are going to use The Big Indexer municipalities collection.

The endpoint to obtain the suggestions is to a given query is https://tbi.populate.tools/gobierto/collections/c-municipios-espanya/suggestions.

It requires a parameter query and an authorization header:

• query: contains the query argument to the suggestions.
• authorization: Bearer <TOKEN_BODY>

(I'll provide the token body in private). Maybe it'll make sense to set that token as an installation setting, because I suspect we are going to use The Big Indexer in some places in the future.

In javascript you can do this:

var settings = {
  "crossDomain": true,
  "url": "https://tbi.populate.tools/gobierto/collections/c-municipios-espanya/suggestions",
  "method": "GET",
  "dataType": "json",
  "data": { "query": "foo"},
  "headers": {
    "authorization": "Bearer <TOKEN_BODY>"
  }
}

$.ajax(settings).done(function(response) {
  console.log(response);
});

The output of the endpoint is an object with a key suggestions and all the suggestions, composed of a value, and a raw data object:

{
"suggestions": [
  {
    "value": "Abarán",
    "data": {
      "id": "30002",
      "name": "Abarán",
      "slug": "abaran",
      "municipality_id": 30002,
      "province_id": 30,
      "autonomous_region_id": 14
    }
  },
  {
    "value": "Abárzuza/Abartzuza",
    "data": {
      "id": "31002",
      "name": "Abárzuza/Abartzuza",
      "slug": "abarzuza-abartzuza",
      "municipality_id": 31002,
      "province_id": 31,
      "autonomous_region_id": 15
    }
  },
  {
    "value": "Abarca de Campos",
    "data": {
      "id": "34001",
      "name": "Abarca de Campos",
      "slug": "abarca-de-campos",
      "municipality_id": 34001,
      "province_id": 34,
      "autonomous_region_id": 7
    }
  }
]}

Communications regarding account verification processes

This comes from #56.

Let's think about notifying verification processes results or changes to the users. i.e.

• "Your account has been verified".
• "Your account verification has been revoked due to changes in census data".

Implement the Consultation reports interface

• Every Consultation should have a way to export its results in a portable format.
• Define that format, and implement an interface just to export the current Consultation responses anonymously.
• Think about providing some User (Participant) segmentation options.

Improve Consultation response UI

Make it look and behave like the prototype.

Allow an admin to edit header site links

User (Citizen) session handling

Concept

TBD

Check-list

• Registration
• Confirmation
• Password recovery
• Authentication and authorization
• Communications
  • Confirmation email
  • Password reset email
  • Welcome email

Think about refactoring the SearchEngine service as an adapter for the actual engine

Just to keep in mind, I'd say that abstracting the search engine's internals would be a good move in terms of architecture. That way, the actual search engine back-end (Elasticsearch) is never reached directly so the querying interfaces can be aligned to our business logic instead.

We could go from this:

GobiertoBudgets::SearchEngine.client.search(
  index: GobiertoBudgets::SearchEngineConfiguration::BudgetLine.index_forecast,
  type: @conditions[:area_name],
  body: query
)

To something like:

GobiertoBudgets::BudgetLine::Forecast.where(area_name: params[:area_name])

GobiertoBudgets::BudgetLine::Forecast.find_by(code: params[:code])

Recalculate User verification status after the Census data source changes

This comes from #56.

Indicators page

Retrieve budget lines from TBI when managing Budget Consultations

TBD

Admin namespace: Admins management

Concept

TBD

Check-list

• Admin creation.
  • Manual.
  • Invitation.
• Protected Admin concept (Godmode).
• Status management.
• Site assignments.
• Module assignments.
• Other permissions.

CSS problema in forms in Firefox

Implement Admin namespace as a built-in Gobierto module

Motivation

After having prepared the codebase to accept new modules, it feels like some Admin-related resources are not properly namespaced or could be out of context, so I'd say it's perfect time to refactor the current implementation and make it behave like a built-in module for consistency.

Check-list

• Do the complete refactor and make tests pass 😛

Change User's source site once verified against census data

This comes from #56.

Skip consultations home if there´s only one active consultation

If there's only one active consultation, skip the consultations home page and redirect to it.

Limit site management actions to Admins with manager authorization level

Basic test suite for GobiertoBudgets module

GobiertoBudgets module doesn't have any test right now that checks if the module is working.

Create a minimum test suite to cover at least:

• home page
  • home page boxes
  • home page main budget lines block
  • home page highlighted budget lines
• budget lines page
• budget line page
• execution page

Admin namespace: Front-end integration

The sandbox files come from #11.

Get rid off translated routes

We have decided to keep routes static, without localization.

Implement Consultation response sharing feature

Provide a unique URL to share any Consultation response anonymously.

Track activities over an admin

These activities that affect an admin need to be tracked

• Admin created (when created using the form or an invitation)
• Admin updated
• Admin sites updated
• Admin modules updated
• Admin user type updated
• Admin login on the app

Retrieve Budget context when responding to Consultations

TBD

Localize Admin UI

Since the latest features are pretty much stabilized, cover any missing translations within the GobiertoAdmin module's UI.

Also, consider enabling the config.action_view.raise_on_missing_translations setting to ensure everything is localized.

Set first available Site when no other is selected

User verification process against census data

Depends on #55.

Check-list:

• The user will explicitly request a verification process.
• The verification process may require filling in some more fields within the User context.
• The verification process will produce a verification status for the given User and data.
• Any verification request will be stored, so that it can be regenerated whenever needed.

Allow an admin to upload a site logo

For the moment we just need a simple upload to S3, without changing or cropping the image.

The result of the upload will be an attribute in the SiteConfiguration.

Set up a continuous integration service

Just to ensure the site builds successfully with each new change.

I'd go for CircleCI or Travis CI.

Admin management: Apply authorization level hierarchy

Protect User sign in and sign up actions against already signed in users

• Redirect them to after_sign_in_path.
• Show them the "You are already signed in" message.

/cc @ferblape

Improve Consultation items management UI

Make it look and behave like the prototype.

Check-list:

• Sortable Consultation items list
• Manage Consultation items in modals
• Autocomplete Budget lines

Migrate visualizations to D3.js v4

In the new indicators page we plan to use D3 v4, so we should migrate the old two visualizations we have in GobiertoBudgets module:

• Treemap: theoretically it should work as it is, so nothing to do here

• Line graph: probably just update the scales and domains, and the rest will work

Extract User-specific logic from ApplicationController

As seen today in the Staging environment, some User namespace-specific logic is defined at ApplicationController level so any other controllers are inheriting them.

In example, the authenticate_user_in_site callback should not be triggered in other namespaces but the User one.

Let's just write it down for a possible refactor.

User census data ingestion from a CSV file

Here's a quick check-list:

• Implement the data model to store census data per Site.
• Implement the UI to load the file containing that census data.
• Parse that file after identifying format and structure.
• Store document numbers securely.
• Track the corresponding Activity events to be able to provide a summary of the latest importing process.

Improvements:

• Perform the importing process in background and notify the requester (Admin) via email when it finishes.
• Perform Census item building in batches to avoid potential memory issues.

User census ingestion improvements

This is a follow up of #55

• Perform the importing process in background and notify the requester (Admin) via email when it finishes.
• Perform Census item building in batches to avoid potential memory issues.

Google Analytics code is not mandatory

Site google analytics code shouldn't be a mandatory field.

Integrate a static code analyzer for maintaining coding standards

I'd start playing with Rubocop in our case.

Allow an admin to edit @site.configuration.links through the UI

We are going to change a bit the links because we want a bit of flexibility, so instaead of an array of links we are going to store a raw HTML field.

Track activity log

Every action that updates the database (creates, updates or destroys a record) must be tracked in the system.

These actions need to reflect:

• the action itself. I.e. site.created or user.updated
• the author of the action
• the subject of the action
• the receiver of the action, if applies
• the IP from which the author executed the action
• the timestamp

There are three kinds of actions:

1 - actions performed by regular users (citiziens) in the public or private site. I.e.: follow a budget line, vote for a comment, or update her personal data
2 - actions performed by an admin in a site, such as create a new participatory process
3 - actions performed by an admin not linked to a site, such as create a new admin, enable a site module, or disable a user account

The activity log will be displayed in different parts of the admin UI, not totally defined yet. For the moment:

• when visiting a user profile or admin profile, all the activity authored by the user will be displayed
• pending to define:
  • where to view generic activity (3)

User management: Scope by current site

Increase test coverage

Codecov is reporting 89.11% of coverage, so let's take a look and try to cover the most obvious cases to increase it above ~92%, for now.

Suggest budgets items when typing

In the consultation item page, we are shoing a lot of budget items to the user, and it's a bit complex to pick a specific budget line.

Change the behaviour and implement a typeahead (auto-suggest) that suggest budgets while the user is typing.

Implement User namespace as a built-in Gobierto module

Motivation

Pretty much like #82, it'd be good to properly namespace every single independent piece in Gobierto as modules for ease and portability. In this case I was thinking of a gobierto-core built-in module to hold what is the User namespace now.

Check-list

• Do the complete refactor and make tests pass.