Asegurarse que no se puede meter código malicioso.
Comprobar:

• Controlador Debates
• Nube de etiquetas
• Helper Tag list

Ahora mismo se renderiza como una string normal:

Hay que:

• Renderizarla utilizando sanitize
• Añadir un test que asegure que no admitimos ataques de inyección de javascript

Hace falta que metamos algún sistema para hacer "lo que hace google analytics pero sin hacer google analytics".

El objetivo es poder tener métricas tipo: dónde entra la gente y dónde no, cuántos accesos por móvil hay, etc. Para poder hacer tests tipo "hemos perdido usuarios con este cambio"

Opciones:

• Lo que tenga el IAM (si tiene algo)
• Algo open-source (yo he usado piwik )
• Montar algo nosotros desde cero (poco probable que podamos llegar al nivel de piwik o similiares a no ser que ya haya algo para rails hecho)

Idealmente hay que dejar la puerta abierta para que el resto de organismos que lo utilicen puedan usar otra cosa (como google analytics)

Necesitamos añadir las traducciones de los distintos modelos utilizados en la aplicación - como indica esta sección de la guía de internacionalización

• Bienvenido (registro)
• Cambio de contraseña
• Comentario en tu debate
• Respuesta a tu comentario

Considerad añadir una licencia ya que en caso contrario es código público pero no tenemos derecho de modificar y redistribuirlo, por ejemplo.

Más información:https://help.github.com/articles/open-source-licensing/#what-happens-if-i-dont-choose-a-license

Configurar y mostrar en los READMEs insignias de buenas prácticas sobre:

• Calidad del código
• Últimas versiones de gemas
• Integración Continua
• Cobertura de tests

Sugerencias: http://elgalu.github.io/2013/add-achievement-badges-to-your-gem-readme/

Limitar a 80 caracteres el campo de título en los debates.

Cumplir los estándares de accesibilidad.

@jaimeiniesta ha escrito una gema fantástica para esto https://github.com/sitevalidator/accessibility

Hay que meter internacionalización y a partir de entonces no incluir más textos sin i18n en el interfaz

Básicamente un highlight es un "Banner" que aparece en algunas views. Lo configura el administrador.

Un highlight pueden ser varias cosas:

• Una Iniciativa (Aparece su foto si la tiene, texto y si haces click en ella te lleva a la iniciativa)
• Un enlace externo con un link (por ejemplo a una noticia relacionada con la democracia participativa)

Sugerencia: hacer que siempre sea un combinado link+texto+imagen, y luego permitir a los administradores "crear destacado de esta iniciativa" y que les rellene el texto (así lo pueden cambiar)

Pasos para reproducir:

• Hacer logout
• Ir a un debate mediante su url (eg /debate/1)
• Intentar votar

Qué ocurre:
Da un error javascript - unauthorized

Qué debería ocurrir:
Cuando un usuario intenta votar sin abrir una sesión la aplicación le debería mostrar el diálogo de login. No deberían producirse errores de javascript.

Sugerencia: si el usuario no está identificado, los links a votar deberían ser links a identificarse (manteniendo como referer la url actual)

El atributo debate.description es html. En las vistas hay que acordarse de hacer html_safe. Al hacer un cambio de estilo se ha perdido el html_safe y el html se ha perdido.

Sugerencias:

• hacer que debate.description devuelva html_safe
• añadir un test que no solamente chequee la sanitización, sino también que el html no se escapa

Cuando se crea un nuevo debate deberían aparecer un listado de "temas sugeridos" o frecuentes que el usuario pueda seleccionar. También podrán añadir etiquetas manualmente en un input del formulario.

Jbuilder no parece estar siendo usado, de modo que mejor eliminarlo para evitar tener que mantenerlo.

En la misma línea, nadie parece estar usando sdoc, especialmente porque genera la documentación en /doc, pero el directorio no está en el .gitignore. De ser así el caso, mejor eliminarlo también, pudiendo dejar abierta la alternativa a otras herramientas de documentación si se quisiera.

Los usuarios deberían poder escoger entre inglés y castellano de una manera simple. La navegación en el resto de enlaces de la aplicación debería ser en el idioma seleccionado.

Sugerencias:

• http://guides.rubyonrails.org/i18n.html#setting-and-passing-the-locale
• http://guides.rubyonrails.org/i18n.html#setting-the-locale-from-the-url-params

En el caso de que en un debate no haya votos, se debería mostrar "0% 0% 0 votos", ahora los números sólo se muestran cuando un debate tiene algún voto.

Desde "mi cuenta" debería poder borrar mi cuenta.
El usuario debería dar opcionalmente una razón para borrar su cuenta.
En los debates y comentarios de un usuario borrado, en lugar de su nombre, debería aparecer el texto "usuario eliminado"

Wireframes:

Mi cuenta

Confirmación

Comentario de usuario borrado

Sugerencias:
Crear una acción destroy para el controlador account, que utilice la gema Paranoia para marcar al usuario como borrado. Utilizar páginas completas en lugar de lightboxes. Utilizar un helper majo para mostrar que el usuario ha sido eliminado en los debates y comentarios.

Para cumplir la LOPD, aunque no borremos la instancia del usuario, debemos borrar todos los datos del usuario, que de momento son nombre, apellidos, email y nickname.

Los administradores también deberían poder borrar usuarios desde su dashboard.

Los debates deberían poder ser compartidos en las redes sociales principales (Facebook, Twitter y Google+)

Sugerencia: https://github.com/huacnlee/social-share-button

Necesitamos un controlador y vista distinto de Debates#index para la acción "root" de los ciudadanos normales. La Home presentará la información de una forma distinta a Debates#index.

Incluir breadcrumbs en todas las páginas antes del contenido. Ejemplo:

Una feature bastante usual es que cuando hay "cambios" (en nuestro caso, nuevos comentarios) desde la última vez que se abrió un debate, éste se "distinga visualmente" en el listado de debates de alguna manera.

Depende un poco de cómo de "forero" quieren que sea la herramienta.

@decabeza: ¿qué opinas?

"No podemos hacer que cada vez que alguien entra en un proceso participativo Google lo sepa".

Observaciones: Existe la posibilidad de preguntar al IAM cómo lo hacen ellos. Pero sus páginas usan JSP así que probablemente sea algo java-centric.

Sugerencia: https://github.com/pludoni/simple-captcha

Es deseable que los usuarios puedan participar de forma anónima en algunos procesos de la página.

• Además de los campos de nombre y apellidos, necesitamos un campo "pseudónimo" (o nickname)
• También necesitamos un flag de "usar pseudónimo en lugar de nombre y apellidos". Si está activado, y el pseudónimo está relleno, se utilizará en lugar del nombre y los apellidos.
• El usuario debe ser capaz de cambiar de "usar nombre real" a "usar pseudónimo" y viceversa editando su perfil, además de cuando se da de alta en la aplicación.
• La validación de un usuario pasa a ser: con el flag desactivado, nombre y apellidos son obligatorios. Con el flag activado, el pseudónimo es obligatorio (pero no nombres y apellidos).
• Nótese que el nombre y los apellidos tendrán un papel importante a la hora de aumentar el nivel de seguridad de un usuario, incluso si éste actúa bajo un pseudónimo. No se debe "desactivar la opción de introducir nombre y apellidos" si se activa el flag de pseudónimo.

Deberá ser posible introducir asociaciones en la aplicación.

Las asociaciones son un tipo de usuario que únicamente puede comentar y proponer iniciativas, pero no apoyar iniciativas ni comentarios.

Las asociaciones tienen su propio formulario de alta (accesible desde el formulario de alta por defecto mediante un enlace). Solamente requieren el nombre de la asociación, un email de contacto y un teléfono.

Las asociaciones no se dan de alta inmediatamente, sino que deben ser aprobadas por un administrador.

Los administradores necesitan una página de administración para aprobar/rechazar este tipo de usuario. Cuando se apruebe una petición de creación de un usuario de tipo Asociación, se le debe enviar un email de confirmación.

Si el administrador rechaza la petición de la asociación, se les deberá enviar un email informando del rechazo.

Sugerencias: Podemos utilizar dos campos booleanos en la tabla de usuarios, is_organization y organization_verifed_at

Actualmente estamos utilizando devise_error_messages! en los formularios de devise, y otras cosas, o nada (ej. formulario de account/show) en los demás.

Tenemos que dar una solución coherente a esto, y usar lo mismo en todos sitios.

Sugerencia: crear un helper que pinte un mensaje genérico de que ha habido errores de validación y pintar divs debajo del los inputs con errores.

Un debate solo puede ser editado por el autor y únicamente si todavía no ha sido votado por nadie.
La idea es impedir que cuando el debate ya haya conseguido apoyos, el autor no pueda modificar el texto inicial.

• Nuevo comentario
• Responder comentario

Pry es una conocida herramienta de debugging que complementa a byebug y puede sustituir a irb. Con ella puedes hacer cd en objectos, edit sus métodos, play líneas individuales, y todo esto mientras el código se ejecuta.

Personalmente es una herramienta indispensable, profesionalmente lo recomiendo siempre a todo aquel que no lo haya probado. Sería genial poder tenerlo entre las herramientas de desarrollo en este repositorio.

Primer email mandado al responsable de Ciudadano360

Buenas,
[...]
Uno de los retos a los que nos enfrentamos es: queremos que el login entre las dos webs sea lo más transparente posible; que cuando alguien tenga una cuenta en la página de democracia participativa pueda entrar con sus datos de Ciudadano 360, y viceversa.

Esto es un primer email para ir abriendo el camino y barajando opciones. Te explico cómo lo veo yo:

Para hacer la primera parte, necesitaríamos un endpoint de Ciudadano360 al que poder decir "este usuario y passwords (o esta cuenta de Google o Facebook), son correctos? Si sí, qué nivel de seguridad tienen?". Con una respuesta positiva, podríamos crear una cuenta en la web y marcarla como "autenticada".

Para hacer la segunda parte (el "viceversa") necesitaríamos que la web de participación ciudadana pudiera crear usuarios en Ciudadano360. Haría falta un endpoint tipo "Crea este usuario nuevo con este login+password/facebook/google").

No tienen por qué ser dos endpoints distintos: podría ser uno único en plan "crea o valida este usuario en Ciudadano360, y devuélveme su nivel".

Como es una petición muy concreta me imagino que no tendréis algo así ya hecho. De todas formas esto es la idea que yo tengo, sin saber cómo funciona Ciudadano360. A lo mejor hay alguna otra cosa que ya tengáis que podamos utilizar (por ejemplo, si Ciudadano360 ya tiene un servicio existente de importación/exportación de usuarios)

[...]

Para usuarios logueados, siempre visible:

• Formulario para dejar un comentario dentro de un debate.
• Botón de "Deja un comentario".

Para usuarios no logueados:

• Formulario para dejar un comentario dentro de un debate: oculto.
• Botón de "Deja un comentario" sustituirlo por un texto tipo: "Debes entrar en tu cuenta para comentar este debate"

Necesitamos preparar un script básico para empezar las pruebas de despliegue a los entornos de staging y preproducción.

Actualizar el readme del proyecto indicando de que va, en vez de usar el generico de Ruby

Recordatorio: no podemos usar el de google. El IAM nos dara info sobre el suyo.

Un cargo público no tiene ningún permiso adicional ni ninguna restricción comparado con los de cualquier otro ciudadano: podrán hacer propuestas, comentar, apoyar iniciativas, etc.

La única diferencia será visual: deberá ser evidente para el resto de los ciudadanos que se trata de cargos públicos.

En la parte de la administración de la página, los administradores deberán poder añadir, editar, y borrar usuarios con cargos públicos. Hay que añadir a la tabla usuarios un campo 'official_position' que representa el cargo de este usuario. Además se definirán 5 niveles de tipo de usuario cargo público.

Hace falta poder administrar también qué nombre poner a esos cinco niveles. En nuestra aplicación inicialmente serán:
"Alcaldes", "Concejales", "Directores generales", "Funcionariado", "Organización Municipal".

http://fortawesome.github.io/Font-Awesome/

Ahora, los botones de apoyar (like/unlike) aparecen siempre de color gris, hay que añadirle una clase CSS (.active-vote, .voted, active..) para poner en color verde o rojo aquellas que ya ha votado el usuario.

¿Queremos que la gente sepa que les han respondido a un comentario de forma visual? Y de ser así, ¿cómo lo mostramos? Ejemplos: Con un "inbox arriba", tipo facebook ("5 respuestas a tus comentarios", pulsa aquí para desplegar y verlos), o con un numerito en cada debate ("2 respuestas en este debate").

@decabeza, te invoco.

Tanto los debates como los comentarios deberían estar paginados.

Sugerencias: https://github.com/amatsuda/kaminari
Paginar sin ajax. Para los comentarios, paginar sólo al primer nivel.

Relacionado con #58 .

Dado que configurar ruby + rails es complicado, y requiere modificaciones significativas en el entorno de desarrollo. Es deseable utilizar un entorno de virtualización que:

• Sea lo más parecido posible al entorno de producción
• Instale todas las dependencias y configuraciones necesarias para el desarrollo en una máquina virtual
• Permita ejecutar una versión de desarrollo de la aplicación
• Permita ejecutar los tests de la aplicación

Aunque Vagrant permite realizar esta tarea, hemos decidido utilizar Docker (ver #69)

En estos momentos el entorno de producción que se está barajando es RHEL+Apache+Passenger con una base de datos PostgreSQL. Se recomienda utilizar CentOS como imagen base en Docker, ya que RHEL es problemático en este sentido por temas de licencia y disponibilidad.

Mostrar tipo de usuario en los comentarios. (¿Mostrar también en la zona de perfil de usuario?)

Tipos:

• Ciudadano
• Asociación #99
• Cargo público #100
• Creador del debate
• Usuario eliminado #103