Hola a todos, ya ha transcurrido un tiempo desde que abrimos la votación para seleccionar en qué proyecto podíamos hacer mejoras a Liferay.

La propuesta ganadora es Quota Control for Sites and Organizations. Una vez hemos elegido la propuesta, deberíamos darnos un plazo para realizar la recogida de requisitos y debatir las funcionalidades de la propuesta ganadora. Os propongo utilizar este hilo de discusión para recoger los requisitos.

Ya existe una primera versión aportada por Corak-IT, http://www.corak-it.de/liferay/downloads.html/-/software_catalog/products/50626, Este hook llamado "Document Library Quota Hook" podría ser el inicio de nuestro proyecto.

Aquellos que queráis participar en este proyecto y podáis hacerlo, además de añadir los requisitos que consideráis, indicad que queréis colaborar en este proyecto y el rol que podéis desempeñar (documentar, programar, probar, diseñar, ...)

Aprovecho la ocasión para anunciar que hemos creado una organización en Github.com donde pondremos todo el código que aportemos. Esta organización se llama #LSUG-Projects (https://github.com/organizations/LSUG-Projects). Aquellos que os queráis hacer miembros, sólo tenéis que pedirlo y decir qué nombre de usuario tenéis en GitHub.

Nos podríamos marcar un plazo de 10 días (hasta 21-23 de noviembre) para aportar requisitos y después cerrar una fecha para hacer una quedada, para programar/probar/documentar/diseñar y cerrar este primer proyecto. En el hilo de la última quedada ya se proponer un lugar: Zona Norte de España.

Ánimo y a aportar ideas!!!

Buenos días!
Estuve probando el hook para la document library, os paso un pequeño resumen y las propuestas que he recopilado para el proyecto.

Document Library Quota Hook
-Despliegue en 6.1 GA1 sin incidencias
-Configuración mediante fichero portal.properties: Quitando comentarios tenemos opción de activar/desactivar una misma cuota para las document library de todas las organizaciones y/o todos los sites.
-En caso de exceder la cuota aparece un aviso a continuación del intento del upload indicando que se ha alcanzado la misma
-Aparentemente hay soporte multi-idioma, incluye ficheros Language_en y Language_de, he probado a añadir el fichero Language_es.properties y la línea correspondiente en liferay-hook.xml, pero no ha funcionado. he omitido algo?
-Curiosidad: En el Language.properties hay una línea de mensaje para "virus-found-exception"

Propuestas para Quota Control for Sites and Organizations
Queridos reyes magos:
-Aplicable a Instancias, Organizaciones, sitios web, usuarios y/o roles
-Ubicación: En panel de control en los distintos formularios para añadir cada uno de estos elementos o bien en algún apartado en los detalles (panel derecho)
-Asignación: Limitación de máximo disponible en base a un cálculo del total disponible menos cuotas ya asignadas. La definición del total disponible no tengo clara cual sería la forma óptima.
-Visualización de espacio asignado y espacio consumido para usuarios y administradores
-Botón/Petición para solicitar aumento de cuota: Desde instancias al administrador de la instancia principal, desde el resto de elementos al administrador de la instancia.
-"Quota rates" en panel de control para administradores. Relación de asignaciones y consumos.
-Evitar reboot para aplicar cambios

Dudas:
-Gestión de adjuntos en otros portlets?

Bueno si se me ocurre alguna cosilla más hago un update.
Saludos!!

¿Has añadido en portlet.xml?

No existía el portlet.xml, pero lo he creado añadiéndole esa línea y efectivamente funciona ok.

Luis, +1 a lo del histórico/evolución y sobre todo para las alertas.

Hola,

Enhorabuena!! Esto toma cuerpo y tiene pinta de ser un éxito más de la comunidad Liferay. Luís, gracias en nombre de todos.

Poco con sustancia se puede añadir a lo que ya esta dicho, aunque tal vez sugerencias en lo que a arquitectura se refiere aun tienen cabida. A ver que os parece el siguiente planteamiento, voy a empezar definiendo la configuración y de ahí voy estirando.

Persistencia de configuración, aquí guardamos las diferentes configuraciones que deseamos, por ejemplo:

- quotaId
- quotaModel: Donde indicaríamos a que type de modelo queremos poner limites (Instancia, Organización, Usuario, Rol, etc.)
- quotaType: Donde indicaríamos que tipo de cuota deseamos (nº archivos, ocupación, entradas de foro, etc.)
- quotaAsigned: Indicamos la cantidad máxima asignada.
- quotaUsed: Donde se lleva la cuenta de lo usado.
- quotaActive: Por si deseamos desactivarla o activarla en un momento dado.
- quotaLog: si es true, llevaremos histórico de movimientos else nos lo ahorramos.

¿Porque persistencia en BBDD? Porque de esta forma podemos cambiar fácilmente todo en “vivo”, sin reiniciar el Server. Hacer una configuración “extensa” con un fichero .properties es algo un poco “no user friendly”, imaginaos que los usuarios “compran” sus cuotas. (Aunque la idea funcionaría igual en .properties)

¿Por qué quotaModel y quotaType? Porque separamos en pequeños “problemas” la programación, pudiendo resolver las cuotas para algunos casos mas evidentes “users/ocupación” o “instancia/ocupación” y después la arquitectura permite ir añadiendo otros casos menos obvios como “roles/entradas en el foro”. Si mañana aparecen nuevas necesidades, extendemos por aquí.

¿Por qué 1 registro x cuota? Porque de esta forma se pueden definir cuotas al estilo de los permisos, pudiendo por ejemplo un usuario alcanzar su cuota de “grupo de usuarios” o de “instancia” sin haber alcanzado la suya de “usuario”, y viceversa, es decir varias cuotas pueden influir en diferentes entes, como los permisos de Liferay, el usuario hereda la cuota de su instancia, grupo.....

¿Por qué quotaAsigned y quotaUsed? Porque de esta forma, útiles como el panel de “Quota Rates” propuesto, seria muy sencillo de realizar. El contrapunto malo es que cada evento que requiere actualizar, leerá y/o tocará uno o varios registros de esta tabla. (Esto no me gusta, sugerencias please)

¿Por qué quotaActive y quotaLog? Porque desactivar una cuota no implica borrarla a ella y su histórico llegado el caso, y también, puede no ser necesario llevar un log de los movimientos de cuota, por lo que se puede evitar igualmente.

Todo lo anterior seria muy interesante controlarlo desde un solo punto (a ser posible), por lo que cada vez que se fuese ha hacer una operación de grabado, se comprobaría si afecta a alguna cuota (recordad que puede que algún usuario tenga y otros no) y actuar en consecuencia. Caso contrario iríamos extendiendo servicios Liferay, que aunque fácil, generaría mucho más código, pero vemos que es muy sencillo, como en el portlet "Document Library Quota Hook".

Para la persistencia del Log, sugiero algo parecido a esto:
- quotaLogId
- quotaId: La cuota que a disparado esta línea
- userId, date, time, etc.
- quotaEventDescription: origen del evento (biblioteca documentos, foro, etc.)
- quotaOldValue: Valor antes de actualizar.
- quotaNewValue: valor después de actualizar

Notas:
- se podría añadir uno o dos campos a la persistencia de configuración, que indicasen si se le permite al usuario incrementar la cuota y en cuanto. O algo parecido para hacer más fácil la existencia de un útil para solicitar el aumento de cuota, que es una idea excelente.
- Cuando se instala el portlet, podría darse de alta todos los registros necesarios de configuración para instancia, roles, usuarios, etc. Con cuota “0” y desactivada para que le fuese más fácil al administrador gestionarlas. Podemos encontrarnos que se instala en portales en activo y con muchos usuarios.
- Cuando se diese de alta algún objeto con posibilidad de ser usado con cuotas (usuario, grupo, rol, etc.) podría igualmente darse de alta en configuración, con cuota “0”, etc. Eliminarse igual.
- Posibilidad de regenerar las cuotas desde el Log.


Bueno lo dejo, que si sigo poniendo ideas, escribo un libro.
Saludos, Jack.

Hola #LSUG: ¡alegra ver que la iniciativa va cogiendo forma!
Os escribo a continuación mis pensamientos/opiniones/recomendaciones

- Nota mental a tener en cuenta en el diseño a abordar: debemos intentar que el impacto en el código del core de Liferay debe ser MÍNIMO, por lo que cuanto más "separado" tengamos nuestro código mejor que mejor.

Respecto a la forma de trabajo, creo que el desarrollo iterativo (muchos ciclos pequeños con funcionalidad terminada) cuadra con este equipo distribuido de personas colaborando en su tiempo libre. Hagamos un roadmap de milestones y vamos viendo la velocidad de iteración a la hora de liberar versiones.

Resumen de requisitos propuestos hasta ahora (más alguno mío):
#1 Control de Cuota debe ser aplicable a: instancias, organizaciones, sitios web, usuarios, roles, grupos de usuarios y teams
#2 Visualización de espacio asignado y espacio consumido para usuarios y administradores (mostrar histórico y evolución del consumo):
#3 Mensajes de alerta cuando se llega a X% o cantidad de cuota determinada (vía mail y visual en la UI)
#4 Deberá tener en cuenta los attachments de todos los portlets (escucha de servicios varios)
#5 Solicitud de aumento de cuota: forma de notificar al admin. Esto debería ser opcional (configurable)
#6 Integración en el sistema de permisos: definir acciones tales como crear, editar, eliminar cuota
#7 Log/auditoría de cambios en la configuración
#8 Poder visualizar cuotas desde Liferay Sync
#9 Soporte para control de cuotas de otras entidades: número de blogs, número de MBDiscussions, número de carpetas...


Propuesta: para irnos organizando, yo haría las siguientes milestones para la versión 1.0:
Milestone #1: funcionalidades #1, #2, #3, #4
Milestone #2: funcionalidades #5 y #6

A partir de ahí, tendríamos algo valioso y "liberable" y ya podríamos seguir iterando y mejorando con nuevas funcionalidades versión a versión. Para la siguiente versión podríamos implementar las #7, #8, #9 y las que vaya proponiendo la comunidad.

Respecto a la implementación, mi opinión aquí es que, para tener el menor impacto posible en el core, esto debe ser implementado en varios portlets (como el portlet de workflow, por ejemplo), de forma que según tu rol puedas configurar unas cosas u otras. La lista de portlets que he pensado es la siguiente:
1) Server Quota: portlet de adminstración general para cuotas de instancias en la sección "Server" del panel de control. Será usado por sysadmins.
2) Portal Quota: otro portlet para la gestión de cuotas para roles, usergroups y sites en la sección "Portal". Será usado por portal admins.
3) Site Quota: portlet de gestión específica de site en la sección del control panel de cada site: se gestionará la cuota de cada usuario y team. Será usado por site admins.
4) My Quota: portlet para cada usuario, donde podrá ver qué ha consumido, qué le queda aún y donde estará la opción de solicitar más espacio (ver funcionalidad #5)

Evidentemente todos vendrán empaquetados en el mismo WAR y usarán el servicio común Quota(Local)ServiceUtil.
Cada uno de estos portlets podrá tener una pestaña de estadísticas gráficas donde se muestre la evolución del consumo con respecto al límite marcado. (Ver la captura de mi teléfono android: podría ser algo parecido)

¿Algún diseñador gráfico o de UX en la sala para hacer un par de mockups de la idea de estos portlets? La interfaz no es trivial de diseñar...para que sea usable

Respecto al backend del servicio (tras una discusión con Jack en su propuesta), sería algo así:


En fin, mi grano de arena. Ya me diréis si os parece o no
Un saludo,
Juan Fernández

Me autoasigno los mockups de la UI de los 4 portlets (ya que no es dev)

Me gusta!!!

Estoy de acuerdo en que hay que vigilar mucho la usabilidad y la accesibilidad.

Esto es a lo que me refería con una gráfica estadística de control del gasto de cuota de Android

Por cierto, otro perfil que necesitamos es alguien bueno en algoritmia. Este portlet tendrá un algoritmo de cálculo de cuotas y de espacio restante que deberá tener en cuenta muchas variables (sumatorios de instancias, agrupaciones por sites, roles, user groups, teams, espacio disponible para asignación al usuario teniendo en cuenta lo anterior...), y que además debe ser bastante óptimo en tiempo de ejecución, por que tendrá un potencial gran impacto en el rendimiento del portal de los usuarios que estén subiendo documentos.

¿Alguien tiene este perfil? ¿A alguien le han brillado los ojitos mientras explicaba el caso?
Un saludo

No he estado siguiendo mucho esta discusión, pero pienso que debería plantearse como un conjunto de hooks que intercepten servicios que significan consumo o liberación de recursos y anotar las varaciones de consumo etiquetando por usuario, sitio, organización, etc, y que se guarde en una tabla, de modo que el consumo sea una llamada al servicio, para obtener el total consumido para cada uno de los hitos del modelo de quota, de forma que se pueda obtener el espacio disponible instantáneo. No parece muy complicado.

En vez/además de hooks, se puede programar un job que reevalúe los datos periódicamente, porque puede haber información que sea complicado evaluar instantáneamente.

Lo cambio por un curso de #$¿¡*@|@ª! Git.

Saludos

¡Hola Aniceto!


Pues es lo que teníamos pensado. El hook que compartió Luis en el primer post es un hook para la DocLib, y será el primero que integraremos enviando datos a nuestro servicios de cuotas, pero evolucionaremos para que se puedan enchufar fácilmente más hooks con listeners para otros servicios.



Hum... tendremos que estudiarlo... ideas valiosas...¿te subes al carro?



¡Ahí va una ayuda! http://try.github.com/levels/1/challenges/1... acabarás amándolo
Un saludo,
Juan

Muy buenas,

Me uno tarde pero espero que a tiempo de hacer una sugerencia y que no llegue a destiempo. Quizá sería interesante prever la posibilidad de establecer cuotas no bloqueantes. De hecho, imagino que esto facilitaría la adopción del control de cuotas en instalaciones ya en marcha.

El caso es que esta opción tiene ciertas implicaciones sobre el esquema de datos. La solución más sencilla que se me ocurre es admitir un tercer valor para quotaStatus, de forma que admita tres valores. Algo así como: [active, onlyAlert, inactive]. En caso de que una cuota esté en estado onlyAlert, se lanzará la correspondiente notificación al llegar a quotaAlert pero se permitirá seguir trabajando una vez que quotaUsed >= quotaAsigned.

Por cierto, en cuanto al sistema de notificaciones, no sé si tenéis ya pensado cómo implementarlo. En el caso de que se conviva con SocialOffice, se me ocurre que sería genial usar el sistema de notificaciones propio de SocialOffice. Sin embargo, para un Liferay Portal "puro", no se me ocurre cómo. ¿Hay algo pensado? ¿mensajes al usuario? ¿generación de excepciones? (Aún soy un poco novato en Liferay así que si estoy diciendo algún disparate, por favor, corregidme).

Un abrazo

Hola Carlos:



Hum... interesante...sería como una versión "soft" del control de cuotas, donde sólo se avise al usuario de que ha excedido pero que permita seguir consumiendo... sería como el modelo de aviso de las telefónicas, donde se te avisa (si quieres) de que has alcanzado un límite de consumo, pero se permite seguir haciendo llamadas... me gusta.



En principio lo más inmediato (y que ya está implementado en el 1º hook) es el mostrar un mensaje con una excepción en pantalla al alcanzar el límite. También podríamos avisar al admin de que el usuario X llegó a su límite. Respecto a Social Office, sería guay lo que dices, pero vamos a intentar ser lo más estándares posibles. La opción de enviar un mail al usuario con el mensaje "Has llegado al límite. Si quieres más cuota, haz click aquí" con un link a la pantalla de solicitud de ampliación... sería interesante. Creo que todas estas cosas son temas de usabilidad que iremos ajustando en sucesivas iteraciones.

Muchas gracias por participar y compartir tus ideas, que son más que bienvenidas... ¡que sigan llegando!
Un saludo,
Juan

Yo me sumo a que no estaría mal que en el Liferay Estándar hubiera un sistema de notificaciones al estilo de los móviles, para los Workflows, para este Hook, para los Foros a los que estás suscrito, etc... Notificaciones en la Dockbar y Panel de notificaciones.

A mí también me parece una opción interesante a considerar. Respecto al bloqueo de instalaciones en producción os informo que cuando hice las pruebas del Document Library Quota Hook vi que parece tener esto en cuenta y es posible activarlo en portales dónde ya existen bibliotecas que excedan el límite. El aviso del exceso de cuota se muestra en el siguiente intento de upload.

Añado otra posible funcionalidad de este control de cuotas:

Limitar el número de versiones a grabar. Se configuraría a nivel genérico del portal, por sitio o por organización (¿tiene sentido por usuario, rol o grupo?). Si se indicara un valor X distinto de 0 guardaría únicamente las últimas X versiones.

Se ha pedido dos o tres veces en el foro:

• http://www.liferay.com/community/forums/-/message_boards/message/18664303
• http://www.liferay.com/es/community/forums/-/message_boards/message/13043346
• http://www.liferay.com/community/forums/-/message_boards/message/10956778

Es buena idea, pero creo que se queda fuera del objetivo... son dos cosas diferentes. Si instalas un plugin de control de quota, no esperas encontrarte control del número de versiones del historico... habrá mucha gente que necesite una cosa y no la otra. De hacerse, creo que deberían ser "hooks" separados.

Buenas tardes a todos!!
Algo más tarde de lo que esperaba... pero por fin puedo subir mi primera contribución al proyecto.
Adjunto 4 wireframes de lo que podría ser el Quota Server.
En el primer boceto (quota-control-1.png) ya echo en falta un acceso a estadísticas globales (todas las instancias) pero con esto ya tenemos material para ir debatiendo.

Espero que os guste!

archivos adjuntos:

quota-control-1.png (86,8k), quota-control-2.png (86,3k), quota-control-3-1.png (92,1k), quota-control-3-2.png (83,6k)

Hola Miguel Angel,

La gráfica de histórico, ¿qué histórico mostrará? ¿El histórico de consumo o el histórico de cuota asignada o ambas cosas? A la gráfica quizás le falte una leyenda.

Os pongo 2 ejemplos de alternativos más a la pantalla de Android que subió @juanferrub más arriba. Son tomadas de iPad y de jDiskReport.

Saludos, Luis

archivos adjuntos:

IMG_0557.PNG (195,2k), jdiskreportChart.png (90,1k), jdiskreportTop50.png (123,5k)

La propuesta inicial de la gráfica (última versión en el wiki del proyecto) muestra evolución de consumo por instancia. En la pestaña histórico tendríamos una relación de espacio consumido en el momento del cambio de la configuración y el nuevo espacio asignado.

De forma complementaria a la evolución de consumo, se podrían solapar los datos de modificaciones en una vertical, sobre la fecha en la que se realizan los cambios, con un tooltip que responda a un hover o similar. Este tooltip también es extensible a cada punto de la gráfica con su dato correspondiente.

Como opciones interesantes para enriquecer las gráficas podemos ver en una segunda fase el reparto de espacio consumido por portlets (biblio, adjuntos a wikis, foros, etc...) o lo que has comentado de listar ficheros pesados, etc. Esto último puede ser muy útil para usuarios.

saludos!!