Re-add and apply MDL rule MD040
We were following it about half of the time and we even added it to our former `.mdlrc` file. However, for some reason, MDL doesn't detect this rule when specified in the `.mdlrc` file, so we didn't notice we weren't following it in many cases. Now that we're using a style file to configure MDL, we can enable this rule again and apply it, since now MDL correctly includes it in its report.
This commit is contained in:
Javi Martín
@@ -38,7 +38,7 @@ La información a rellenar esta dividida en tres apartados:
|
||||
|
||||
Para ayudar a entender como rellenar cada uno de los campos, nos basaremos en un supuesto WebService que recibe un método llamado `:get_habita_datos` con la siguiente estructura:
|
||||
|
||||
```
|
||||
```ruby
|
||||
{
|
||||
request: {
|
||||
codigo_institucion: 12, #Valor estático
|
||||
@@ -99,7 +99,7 @@ La información a rellenar esta dividida en tres apartados:
|
||||
|
||||
Al igual que en el apartado anterior definiremos un ejemplo de respuesta, para ayudar a entender como rellenar cada uno de los campos de esta sección.
|
||||
|
||||
```
|
||||
```ruby
|
||||
{
|
||||
get_habita_datos_response: {
|
||||
get_habita_datos_return: {
|
||||
|
||||
@@ -8,7 +8,7 @@ Hay que definir los atributos que se quieran traducir en el modelo. Para ello, h
|
||||
|
||||
También deberemos añadir la opción `globalize_accessors` con todos aquellos locales a los que queramos tener acceso. Esta gema generará los métodos `title_en`, `title_es`, etc., y que se usan en la aplicación. Si lo que quieres es incluir **todos** los campos traducidos en **todos** los idiomas definidos en tu aplicación, puedes llamar a `globalize_accessors` sin ninguna opción (tal y como se explica en la [documentación](https://github.com/globalize/globalize-accessors#example)).
|
||||
|
||||
```
|
||||
```ruby
|
||||
# Suponiendo un modelo Post con attributos title y text
|
||||
|
||||
class Post < ActiveRecord::Base
|
||||
@@ -21,7 +21,7 @@ end
|
||||
|
||||
Hay que crear una migración para generar la tabla donde se almacenarán todas las traducciones de ese modelo. La tabla deberá tener una columna por cada atributo que queramos traducir. Para migrar los datos ya almacenados (en la tabla original), hay que añadir la opción `:migrate_data => true` en la propia migración:
|
||||
|
||||
```
|
||||
```ruby
|
||||
class AddTranslatePost < ActiveRecord::Migration
|
||||
def self.up
|
||||
Post.create_translation_table!({
|
||||
@@ -42,7 +42,7 @@ end
|
||||
|
||||
Añadir el módulo `Translatable` en el controlador que vaya a gestionar las traducciones.
|
||||
|
||||
```
|
||||
```ruby
|
||||
class Post < Admin::BaseController
|
||||
include Translatable
|
||||
...
|
||||
@@ -50,7 +50,7 @@ class Post < Admin::BaseController
|
||||
|
||||
Hay que asegurarse de que este controlador tiene las funciones `resource_model` y `resource`, que devuelven el nombre del modelo y el objeto para el que se van a gestionar las traducciones, respectivamente.
|
||||
|
||||
```
|
||||
```ruby
|
||||
...
|
||||
def resource_model
|
||||
Post
|
||||
@@ -66,7 +66,7 @@ Hay que asegurarse de que este controlador tiene las funciones `resource_model`
|
||||
|
||||
Añadir como parámetros permitidos aquellos que estén dedicados a las traducciones. Para eso, el módulo `Translatable` posee una función llamada `translation_params(params)`, a la que se le pasan el parámetro del objeto. A partir de esos parámetros, y teniendo en cuenta los idiomas definidos para ese modelo, la función devuelve aquellos parámetros que contengan un valor.
|
||||
|
||||
```
|
||||
```ruby
|
||||
# Siguiendo con el ejemplo, en este caso se le pasarían los parámetros params[:post], porque es el
|
||||
# hash que contiene toda la información.
|
||||
|
||||
@@ -86,7 +86,7 @@ Recuerda que, para evitar errores al usar locales como `pt-BR`, `es-ES`, etc. (a
|
||||
|
||||
Al formulario que se use para editar las traducciones se le deberá añadir el parámetro oculto que las marca para que se borren:
|
||||
|
||||
```
|
||||
```erb
|
||||
<%= hidden_field_tag "delete_translations[#{locale}]", 0 %>
|
||||
```
|
||||
|
||||
@@ -96,7 +96,7 @@ También habrá que añadir el link de "Eliminar idioma", que deberá tener:
|
||||
- un atributo `data-locale` con el valor de `neutral_locale(locale)`.
|
||||
- la clase `delete-language`.
|
||||
|
||||
```
|
||||
```erb
|
||||
<%= link_to t("admin.milestones.form.remove_language"), "#",
|
||||
id: "delete-#{neutral_locale(locale)}",
|
||||
class: 'delete-language',
|
||||
@@ -109,7 +109,7 @@ Los estilos de CSS y el resto de clases que se le quieran añadir dependerán de
|
||||
|
||||
Para que se generen cuando se restablezca la base de datos. Por ejemplo, para crear un post cuya descripción está traducida:
|
||||
|
||||
```
|
||||
```ruby
|
||||
section "Creating post with translations" do
|
||||
post = Post.new(title: title)
|
||||
I18n.available_locales.map do |locale|
|
||||
|
||||
@@ -36,7 +36,7 @@ Una de las caracteríticas que diferencian una API REST de una GraphQL es que co
|
||||
|
||||
Las consultas en GraphQL están escritas siguiendo un estándar que presenta ciertas similitudes con el formato JSON, por ejemplo:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposal(id: 1) {
|
||||
id,
|
||||
@@ -140,7 +140,7 @@ La lista de modelos es la siguiente:
|
||||
|
||||
<h3 id="recuperar-un-unico-elemento-de-una-coleccion">Recuperar un único elemento de una colección</h3>
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposal(id: 2) {
|
||||
id,
|
||||
@@ -166,7 +166,7 @@ Respuesta:
|
||||
|
||||
<h3 id="recuperar-una-coleccion-completa">Recuperar una colección completa</h3>
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposals {
|
||||
edges {
|
||||
@@ -205,7 +205,7 @@ Respuesta:
|
||||
|
||||
Actualmente el número máximo (y por defecto) de elementos que se devuelven en cada página está establecido a 25. Para poder navegar por las distintas páginas es necesario solicitar además información relativa al `endCursor`:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposals(first: 25) {
|
||||
pageInfo {
|
||||
@@ -242,7 +242,7 @@ La respuesta:
|
||||
|
||||
Para recuperar la siguiente página, hay que pasar como parámetro el cursor recibido en la petición anterior, y así sucesivamente:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposals(first: 25, after: "NQ==") {
|
||||
pageInfo {
|
||||
@@ -262,7 +262,7 @@ Para recuperar la siguiente página, hay que pasar como parámetro el cursor rec
|
||||
|
||||
Esta consulta solicita información relativa a varios modelos distintos en una única petición: `Proposal`, `User`, `Geozone` y `Comment`:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
proposal(id: 15262) {
|
||||
id,
|
||||
@@ -298,7 +298,7 @@ Existen tres mecanismos principales para evitar este tipo de abusos:
|
||||
|
||||
La profundidad máxima de las consultas está actualmente establecida en 8. Consultas más profundas (como la siguiente), serán rechazadas:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
user(id: 1) {
|
||||
public_proposals {
|
||||
@@ -339,7 +339,7 @@ La respuesta obtenida tendrá el siguiente aspecto:
|
||||
|
||||
El principal factor de riesgo se da cuando se solicitan varias colecciones de recursos en una misma consulta. El máximo número de colecciones que pueden aparecer en una misma consulta está limitado a 2. La siguiente consulta solicita información de las colecciónes `users`, `debates` y `proposals`, así que será rechazada:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
users {
|
||||
edges {
|
||||
@@ -384,7 +384,7 @@ La respuesta obtenida tendrá el siguiente aspecto:
|
||||
|
||||
No obstante sí que es posible solicitar información perteneciente a más de dos modelos en una única consulta, siempre y cuando no se intente acceder a la colección completa. Por ejemplo, la siguiente consulta que accede a los modelos `User`, `Proposal` y `Geozone` es válida:
|
||||
|
||||
```
|
||||
```graphql
|
||||
{
|
||||
user(id: 468501) {
|
||||
id
|
||||
|
||||
@@ -14,7 +14,7 @@ Si has actualizado una instalación de Consul Democracy a la versión 2.0.0 desd
|
||||
|
||||
Así, en primer lugar, tras subir la versión 2.0.0 al servidor de producción, tendrás que ejecutar las tareas de actualización de versión:
|
||||
|
||||
```
|
||||
```bash
|
||||
RAILS_ENV=production bin/rails consul:execute_release_tasks
|
||||
```
|
||||
|
||||
@@ -26,13 +26,13 @@ Si es así, reincia la aplicación. Si no has recibido este aviso, comprueba que
|
||||
|
||||
Una vez hecho esto, deberás abrir una consola de base de datos utilizando un usuario que tenga permisos para crear y modificar extensiones de base de datos:
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo -u postgres psql -d consul_production
|
||||
```
|
||||
|
||||
Si no usaste el [instalador](https://github.com/consuldemocracy/installer/) para instalar Consul Democracy, es posible que tengas que ejecutar las siguientes consultas de base de datos para garantizar los permisos del usuario de Rails para crear esquemas así como el acceso al esquema de extensiones compartidas:
|
||||
|
||||
```
|
||||
```sql
|
||||
CREATE SCHEMA shared_extensions AUTHORIZATION <reemplazar_con_usuario_de_rails_de_base_de_datos>;
|
||||
GRANT CREATE ON DATABASE consul_production TO <reemplazar_con_usuario_de_rails_de_base_de_datos>;
|
||||
GRANT usage ON SCHEMA shared_extensions TO public;
|
||||
@@ -40,7 +40,7 @@ GRANT usage ON SCHEMA shared_extensions TO public;
|
||||
|
||||
Tanto si usaste el instalador como si no, ejecuta:
|
||||
|
||||
```
|
||||
```sql
|
||||
ALTER EXTENSION pg_trgm SET SCHEMA shared_extensions;
|
||||
ALTER EXTENSION unaccent SET SCHEMA shared_extensions;
|
||||
```
|
||||
@@ -88,13 +88,13 @@ Si has instalado Consul Democracy usando el instalador y estás usando Certbot p
|
||||
|
||||
Una opción es añadir manualmente cada certificado cada vez que creas una entidad. Por ejemplo, para añadir la entidad con subdominio `marte` al dominio `ejemplodesistemasolar.org`, ejecuta:
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo certbot certonly --nginx --noninteractive --agree-tos --expand -d ejemplodesistemasolar.org,marte.ejemplodesistemasolar.org
|
||||
```
|
||||
|
||||
Si vas a añadir muchos subdominios en distintos momentos, esta tarea puede resultar tediosa. Una alternativa es habilitar cualquier subdominio. Para conseguir esto, deberás tener acceso al panel de administración de tu dominio (DNS) para poder seguir las instrucciones al utilizar bien alguno de los [plugins DNS de Certbot](https://eff-certbot.readthedocs.io/en/stable/using.html#dns-plugins) o la [generación manual del certificado](https://eff-certbot.readthedocs.io/en/stable/using.html#manual) con la siguiente orden:
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo certbot certonly --manual --agree-tos --expand -d ejemplodesistemasolar.org,*.ejemplodesistemasolar.org
|
||||
```
|
||||
|
||||
@@ -110,7 +110,7 @@ Para disminuir la probabilidad de que los correos enviados por la aplicación se
|
||||
|
||||
Si quieres utilizar una configuración de envío de correo electrónico diferente para una entidad, como podría ser una que utilice `jupiter` como subdominio, edita el fichero `config/secrets.yml` de la siguiente manera:
|
||||
|
||||
```
|
||||
```yaml
|
||||
production:
|
||||
# (...) Otros secretos
|
||||
multitenancy: true
|
||||
@@ -138,7 +138,7 @@ Como primera opción, en el panel de configuración de Twitter/Google/Facebook/W
|
||||
|
||||
Y como segunda opción, puedes crear una nueva aplicación de Twitter/Google/Facebook/Wordpress y configurarla para su uso desde el dominio de la nueva entidad. En este caso, deberás añadir la configuración de esta aplicación al fichero `config/secrets.yml`. Por ejemplo, si administrases una entidad con el subdominio `saturno`, edita el fichero de esta manera, rellenando la información de aquellos servicios que estés utilizando:
|
||||
|
||||
```
|
||||
```yaml
|
||||
production:
|
||||
# (...) Otros secretos
|
||||
multitenancy: true
|
||||
@@ -172,7 +172,7 @@ Cuando la funcionalidad de multientidad está activada, Consul Democracy añade
|
||||
|
||||
Así, es posible sobrescribir los estilos para una entidad específica añadiendo a alguna hoja de estilos en la carpeta `app/assets/stylesheets/custom/`:
|
||||
|
||||
```
|
||||
```css
|
||||
.tenant-urano {
|
||||
// Estilos que solamente se aplican a Urano
|
||||
}
|
||||
@@ -180,7 +180,7 @@ Así, es posible sobrescribir los estilos para una entidad específica añadiend
|
||||
|
||||
Para cambiar los colores en una determinada entidad de forma sencilla, puedes utilizar variables de CSS; su uso aparece documentado en el fichero [app/assets/stylesheets/custom/tenants.scss](https://github.com/consuldemocracy/consuldemocracy/blob/master/app/assets/stylesheets/custom/tenants.scss). Por ejemplo, para utilizar tonos de verde en los colores principales de la entidad con subdominio `urano`, puedes escribir:
|
||||
|
||||
```
|
||||
```css
|
||||
.tenant-urano {
|
||||
--brand: #350;
|
||||
--brand-secondary: #173a00;
|
||||
|
||||
Reference in New Issue
Block a user