lunes, 22 de junio de 2009

Como indexar un campo

0 comentarios
 
Cuando creamos un patrón nuevo que contiene campos nuevos, y queremos usar algunos de esos campos para filtrar proyectos, ya sea a través de la configuración de filtros, ya sea a través de algún listado, necesitamos que ese campo se encuentre indexado en el catálogo de Zope.

Por ejemplo, imaginemos que tenemos un campo 'contacto_relacionado' que queremos indexar. Tendremos que irnos al ZMI, al objeto "portal_catalog", pestaña "Indexes", y añadir allí un índice del tipo "FieldIndex" indicando que el atributo a indexar sea "contacto_relacionado" y que su identificador sea ese mismo nombre. Una vez creado el índice, marcamos el checkbox que se encuentra a su izquierda, y pulsamos en el botón "Reindex Index", tras lo cual ya podrá usarse ese índice

En caso que el atributo a indexar sea más complejo, como un string que deba normalizarse, puede usarse índices del tipo "Managable FieldIndex", indicando así fórmulas de prenormalizado.
Leer más...

Encodings al editar usando ZMI

0 comentarios
 
Cuando queremos editar configuraciones avanzadas recurrimos a la interficie que nos proporciona Zope, llamada Zope Managemente Interfaces (ZMI), típicamente accedida usando http://maquina:puerto/manage Cuando se usa esa interfície, suelen aparecer problemas con los acentos y demás carácteres no ASCII. Por ejemplo, si queremos configurar un mensaje de una notificación, dentro de un campo "KMKey User Role Field", y queremos que el título sea "Nueva Revisión", nos encontramos con sorpresas desagradables con frecuencia, porque se codifican mal los caracteres.

Todo ello tiene fácil solución, pero poco documentada. Se trata de ir a la pestaña "Properties" de nuestro sitio, y añadir una propiedad de tipo string que se llame "management_page_charset", con valor "iso-8859-15". Después de eso la edición de acentos en propiedades usando ZMI dejará de ser un problema
Leer más...
miércoles, 17 de junio de 2009

Configuración opciones KMKey

0 comentarios
 
Parámetros de configuración de un site.
Estas opciones se dan de alta directamente a nivel de site des del ZMI --> properties

PERSONALIZACIÓN
==================
Title ---> título del site
logo_text --> Texto que sale junto al logo en la pantalla de login
logo_header ---> Header de la pantalla de login
logo_header_path --> path de la imagen del logo
logo_color --> Color del logo_text
navtree_sort_subitems_by --> lista de campos separados por coma para indicar el criterio de ordenación de las tareas en el árbol de navegación


CORREO
======
pop3_server
pop3_user
pop3_password --> servidor, usuario y password de la cuenta de correo utilizada para el mail_scan
mail_reply_to --> dirección de correo a la q se responderán los mensajes generados en KM
mail_descriptive_name --> nombre de la dirección de correo


CONTABILIDAD/ECONOMÍA
==================
subcuenta_iva_soportado_4
subcuenta_iva_repercutido_4
subcuenta_iva_soportado_7
subcuenta_iva_repercutido_7
subcuenta_iva_soportado_16
subcuenta_iva_repercutido_16

*Estas opciones definen las cuentas contables asociadas a cada tipo de iva para la exportación de la contabilidad a contaplus (Admin ---> exportar contabilidad)

same_date_for_invoice_lines --> Si true --> modifica automáticamente las fechas de todas las lineas de una factura con la fecha de emisión de la factura


GESTIÓN DE RECURSOS
===================
kmkey_filter_resources_only_assigned --> Por defecto 0. Si true --> unicamente muestra los usuarios directamente asociados al expediente, no todos los q tienen acceso 'indirecto'
kmkey_filter_resources --> Por defecto 1. Si 1--> muestra unicamente usuarios asignados. Si 0, muestra todos los usuarios, independientemente de la opción anterior

GESTIÓN DE NOTIFICACIONES
========================
send_notification_at_task_begin --> Envía una notificación al responsable de tarea al iniciarla
send_notification_at_task_close --> Idem, al cerrar tarea
send_notification_at_task_create --> Envía notificación al crear o modificar el reponsable de la tarea
block_notifications --> Por defecto 0. Si true --> no envía ninguna notificación desde KM (útil para actualizaciones massivas q impliquen un commit de alguna pill o expediente q puede generar notificaciones)

OTROS
======
task_name_to_create_purchases --> Nombre de la tarea donde se crearan las compras al sincronizar desde km2. Si no se especifica, se crearan en el proyecto
economic_plan_lines_sort_on --> orden por defecto de las lineas en la view de una previsión
gantt_period --> período del gantt por defecto (days, months)
execute_sql_reports --> Indica si los listados genéricos (compras, ventas, etc) se generarán via sql o via zodb
Leer más...

Documentos en el sistema de ficheros

0 comentarios
 
Por defecto, cuando subimos archivos adjuntos, ya sea mediante la entrada de píldoras documento o mediante el envío de mails, estos acaban guardándose en la BBDD. Eso puede significar en ZODB (sobre el storage que tenga configurado), o bien postgreSQL si tenemos configurado así el schema. En cualquier caso, las BBDD y los archivos no se han llevado bién históricamente, por lo que lo más recomendable es poder almacenar esos archivos en una estructura de directorios y ficheros.

Como no, KMKey incorpora la posibilidad de activar dicha funcionalidad de forma totalmente transparente al usuario. Basta con acceder via ZMI (http://ip:puerto/manage), acceder a nuestro sitio, en el apartado "portal_schemas", y en la pestaña "Properties" añadir una propiedad que se llame "disk_storage_path", y que contenga el path del directorio base (que por supuesto debe tener permisos de escritura concedidos al usuario que ejecute el servidor de aplicaciones). Por ejemplo, disk_storage_path = /var/zope/storages/adjuntos creará una estructura de 2 niveles de profundidad para ir almacenando los archivos en disco.

Finalmente, no olvidemos configurar un backup apropiado del directorio al activar está opción.
Leer más...
jueves, 11 de junio de 2009

Lástima que la primera cita sea de Bill Gates...

0 comentarios
 






Leer más...
miércoles, 10 de junio de 2009

Plantillas Generables asociadas a un patrón

0 comentarios
 
KMKey permite generar documentos de plantillas OO a partir de un expediente, tarea, etc

Una de las formas es vincular un documento generable a un patrón. Los pasos a seguir son los siguiente

- Crear una Plantilla Open Office y guardarla dentro de un expediente. Normalemente el expediente,tarea o documento deberá tener acceso de lectura para todo el mundo

- En el patrón que nos interese generar esta plantillas, en modificar, vermos el campo "Generable Objects" que nos permite indicar un xml con los objetos que podremos general , del estilo :


<document
default_title="Informe de visita a obra.doc"
formats="doc#@sxw#@pdf#@oo"
getDocid="1588407473"
default_format="doc"
view_class="Products.KMKeyDefault.reportsview.SpanishReportsView"
view_context="context"
/>


La entrada 'document' indica que el objeto generable será un documento, los parámetros :

- default_title --> título por defecto
- formats --> lista de formatos generables
- getDocid --> docid que hace referencia al documento plantillas que hemos colgado antes
- default_format
- view_class , por defecto siempre Products.KMKeyDefault.reportsview.SpanishReportsView, pero podemos especificar una view propia
- view_context, por defecto 'context' --> el contexto de trabajo

Por norma general, lo único que modificaresmos será el título,los formatos y el getDocid

una vez agregado este xml al patrón, si vamos a un expediente generado con este patrón, al añadir un documento, veremos que nos permite seleccionar la plantilla generable

Ejemplo de plantilla generable sobre un expediente :

Por ejemplo, generamos un nuevo documento de OO, lo titularemos "plantilla.sxw", y escribiremos directamente el siguiente contenido:

<define unit here['getParentProject']()/>
<define datos view.datosLegibles(unit)/>
<define dm datos['dm']/>
<define boa view.getProyectoRelacionado(dm['xxx'])/>

<content datos['Title']/>
<content datos['Description']/>

<content datos['campo_numerico']/>
o
<content dm['campo_numerico']/>


Guardamos la plantilla, la colgamos dentro del expediente de plantillas, y luego vamos al expediente des de el que queremos generala, la generamos i... voilà! tenemos los datos volcados del expediente (título y descripción) en un documento de word (o pdf, ya que podemos hacer cualquier conversión). Y lo mismo para excel

Las instrucciones son bastante intuitivas:

<define unit here['getParentProject']()/>
** declara una variable llamada 'unit' que apunta al expediente

<define datos view.datosLegibles(unit)/>
** view es el python asociado a la plantilla, y es donde estan todas las funciones accesibles que nos facilitan mucho la vida.
datosLegibles es una función que acepta un proxy, y nos devuelve un diccionario con todos los campos del objeto, formateados, en modo vista (generados a partir del Layout)

<define dm datos['dm']/>
** datos['dm'] contiene el apuntador al datamodel, por si nos interesa acceder a los datos tal cual, sin estar formateados

<define boa view.getProyectoRelacionado(dm['xxx'])/>
** Esta función , getProyectoRelacionado, nos devuelve los datos legibles del proyecto relacionado del campo 'xxxx' del expediente.

Para hacer el output del campo, utilizamos el tag 'content'

<content datos['campo_numerico']/> --> salida de un campo numérico, formateado
o
<content dm['campo_numerico']/> --> sin formatear, por si nos interesa hacer cálculos en un excel

En otra entrada del blog tenemos una referencia rápida de los tags disponibles :
http://kmkey-es.blogspot.com/2009/06/usando-openoffice-para-hacer-listados-i.html

En otra entrada publicaremos una referencia rapida de todas las funciones disponibles en el view, que de momento podéis consultar directamente en el .py ubicado en Products/KMKeyDefault/reportsview.py

Leer más...
martes, 9 de junio de 2009

Un buen plan hoy es mejor que un plan perfecto mañana

0 comentarios
 
"A good plan today is better than a perfect plan tomorrow"
George S. Patton (1885-1945)

En KMKey estamos de acuerdo con uno de los mejores estrategas de los últimos tiempos y hacemos de KMKey una herramienta útil y flexible para saber el estado de los proyectos HOY y como van a evolucionar MAÑANA.
La programación "perfecta" no existe porque las empresas no son perfectas. Todas las herramientas de predicción, para ser fiables, necesitan que algunas de las variables que intervienen se puedan fijar. Ya sea el tiempo, los recursos disponibles o la economía prevista.
Si mantener la predicciones en un solo proyecto ya es difícil, la realidad nos dice que cuando hay varios, los recursos son variables y las condiciones también, nos parece iluso hacer predicciones exactas de lo que va a acontecer.
KMKey soluciona esta problemática permitiendo trabajar la planificación con dos niveles de ZOOM:

PRISMÁTICO:
Donde tendremos una idea de lo que está previsto que ocurra en una franja temporal amplia. A menudo mediante porcentages.
-Porcentage de ocupación de recursos (o recurso) en un periodo
-Periodo de ejecución previsto de una tarea
-Gastos previstos para un period

LUPA

Cuando existe la certeza (o casi) de que un suceso acontecerá en una determinada fecha, se puede planificar en KMKey con todo lujo de detalles
-Tal dia de 8 a 12 elSr Tal y el Sr Pascual estaran reunidos
-Tengo previsto gastar X€ en el desplazamiento de la próxima semana
-Voy a dedicar X horas a la tarea N del proyecto A.

Esta dualidad nos permite escoger entre un "buen plan hoy" o "uno perfecto mañana".
Leer más...

Usando OpenOffice para hacer listados (I)

5 comentarios
 
KMKey dispone de un sistema de fabricación de listados poco habitual, pero muy útil. Se trata de confeccionar los listados o documentos generables usando OpenOffice, e incorporar dentro del documento, con el mismo OpenOffice, sentencias XML/python que permiten su dinamización y combinación con los datos de la aplicación. El resultado final puede obtenerse en el mismo formato OpenOffice, en PDF o en formato MS/Office (doc / xls), gracias a las capacidades que OpenOffice nos ofrece.

La forma de combinar datos puede variar en función de la configuración de schemas que tengamos en ZODB o en SQL (hay una entrada sobre este tema en este mismo blog). En general, los documentos generables afectan datos de un sólo expediente, por lo que pueden abordarse sin problemas usando datos via ZODB, lo que los hace más genéricos y reusables. En cambio, los listados que se obtienen sobre un filtro de expedientes pueden manejar volúmenes importantes de datos, y suele valer la pena tener los schemas implicados en SQL y usar sentencias SQL para la recuperación de datos.

En este primer capítulo, vamos a dar un breve repaso a las sentencias XML disponibles, y en capítulos posteriores abordaremos cómo realizar la instalación de los listados, o las expresiones python de uso más frecuente.
  • <define nombre_variable expresion_python /> Sirve para definir variables que vamos a usar posteriormente. La expresión python puede ser una llamada a un método, una llamada a una setencia SQL a través de un conector, o simplemente un tratamiento de datos python. Por ejemplo, para obtener el proyecto dentro de un documento generable, podemos usar <define proyecto self.getContent().getKMProject() />
  • <content expresion_python />Escribe texto en el documento. El texto escrito, óbviamente, es el resultado de evaluar la expresión python. Puede ser un nombre de variable, un método, un atributo de un objeto, etc. Siguiendo con el ejemplo anterior, para escribir el título del proyecto usaríamos <content proyecto['Title']() />
  • <date expresion_python /> Igual que content, pero se espera que el resultado de la expresión python se corresponda con una fecha del tipo DateTime. Sólo es necesario usarla si estamos generando hojas de cáculo y queremos que el tipo de datos resultante sea una fecha, si nos vale con que sea string se puede usar content perfectamente.
  • <float expresion_python /> Exactamente lo mismo que el caso de las fechas, pero con los tipos de datos numéricos. Del mismo modo, sólo tiene sentido para generar hojas de cálculo
  • <image expresion_path_imagen /> Si la expresión python devuelve un path de imagen, ésta se incorpora en el documento generado
  • <repeat nombre_variable expresion_python > ... </repeat>. Realiza un bucle sobre la expresión python, asignando nombre_variable en cada iteración. Para que funcione adecuadamente, debe situarse en una hoja de cálculo, o en una tabla si estamos en el procesador de textos, de otra forma el sistema no es capaz de llevar a cabo el bucle de construcción del documento
  • <if expresion_python > ... </if>. Sólo ejecuta el interior del condiciona si la expresion python devuelve un valor True. Igual que en el caso del repeat, debe usarse en una hoja de cálculo o en una tabla
  • checkboxs. Para generar checkbox activos o inactivos, se puede activar el modo formulario de OpenOffice y definir como nombre de campo del chekbox una variable. Si esa variable se encuentra definida y vale True, entonces el checkbox aparecerá marcado. En caso contrario, aparecerá desmarcado.
Leer más...

Activando el sistema de e-mails

0 comentarios
 
Quizá no todo el mundo sepa que KMKey, entre otras muchas cosas, es capaz de enviar y recibir correos electrónicos, siempre asociados a proyectos o tareas. Para conseguirlo, KMKey se sirve de una cuenta de correo propia, de forma que cuando el usuario petito de la empresa nuestrodominio envia una mail des de su KMKey, el mail sale con un FROM pepito@earcon.com, pero con un REPLY-TO pepito@earcon.com, kmkey@nuestrodominio.com. O sea, las respuestas a ese e-mail llegaran a quien lo haya enviado, pero también llegarán a KMKey, que lo incorporará en la tarea o proyecto correspondiente.

Además es posible reenviar a nuestro KMKey un correo electrónico que nos haya llegado directamente a nosotros, pero que tenga que ver con algún proyecto que estamos gestionando en KMKey. En ese caso, podemos reenviar nuestro correo a kmkey@nuestrodominio.com. Pero ¿ cómo sabe en qué proyecto o tarea queremos dejarlo ? Muy fácil, hay que incluir el Código E-mail en el título del mail. Si en KMKey vamos a la pestaña Definición de un proyecto o tarea, veremos ese código e-mail, que suele ser del tipo project_999999999 o task_999999999. Lo copiamos y lo añadimos en el título del mail que estamos reenviando, y eso es todo, el e-mail llegará a KMKey, se añadirá donde le hayamos indicado, y además si tiene adjuntos estos serán incluidos como documentos.

Para activar estas funcionalidades en nuestra instalación, es necesario seguir algunos pasos en el ZMI (accediendo a zope a través de http://site:puerto/manage):

1) Ir a la raiz del site KMKey, a la pestaña Properties y añadir las siguientes propiedades de tipo string:
  • pop3_server: DNS o IP del servidor POP3 de donde leer correos
  • pop3_user: usuaroi de pop3, puede ser con dominio o sin el
  • pop3_password: clave del usuario en el servidor pop3
  • mail_reply_to: e-mail associado al kmkey, si es distinto del pop3_user
  • mail_descriptive_name: Nombre descriptivo del e-mail del KMKey: "KMKey Nombre Empresa"
2) Dentro del site KMKey, hay un objeto llamado MailHost, que se usa para los envíos de mails. Entrar en él y definir:
  • SMTP Host: IP o DNS del servidor smtp a usar
  • Authentication ID: kmkey@midominio.com
  • Password: Clave del usuario SMTP
3) Finalmente sólo nos queda activar la lectura periódica de e-mails. Para ello disponemos de los scripts email_scan.sh y email_scan.py, situados en el directorio KMKeyCore/utils. Los podemos activar usando cron, por ejemplo cada 10 minutos, y ya tenemos el email integrado en nuestro KMKey
Leer más...
miércoles, 3 de junio de 2009

Liberado KMKey 3 versión "Durruti"

0 comentarios
 
Nos complace anunciar la liberación de KMKey 3 versión “Durruti”. KMKey (Knowledge Management Key) es una plataforma de gestión de proyectos / expedientes construida sobre un gestor documental, con tres usos principales (aunque no únicos): gestión de proyectos, gestión de calidad, y helpdesk. Funciona en entorno web y facilita enormemente el trabajo colaborativo, permite la consolidación de datos en empresas multisede, implementa el trabajo basado en procedimientos, y además permite la gestión y el control de proyectos en todos sus ejes: temporal, de esfuerzo, informativo y económico.

Es un producto desarrollado aquí, basado en la experiencia empresarial acumulada (ésta es la tercera reescritura de un software que empezó propietario hace más de 8 años), pero sobretodo es un software usado en el día a día de un buen número de empresas y administraciones. Su gran capacidad de configuración lo ha hecho útil para la mayoría de empresas de servicios, y muchas de ellas lo estan usando ya para mejorar su forma de trabajar y salir reforzadas de la crisis. Para facilitar su expansión y poner así nuestro granito de arena, hemos configurado incluso un disco para VirtualBox con una instalación de KMKey preconfigurada para gestión de calidad, que está disponible via torrent. Y además tiene licencia GPL. ¿ A qué esperais para probarlo ?
Leer más...

Como Instalarse KMKey Durruti

17 comentarios
 
En primer lugar, dejar claro que KMKey requiere un servidor web con Zope 2.9.4, python 2.4 y sistema operativo GNU/Linux, preferentemente Debian. Aunque algunas partes pueden llegar a funcionar sobre Windows, no se soporta este sistema operativo

En las estaciones cliente, se soporta tanto Mozilla Firefox como IE >= 6, sobre cualquier sistema operativo.

Dicho esto, si alguien quiere instalarse KMKey en sus dependencias, tiene varias opciones:

1) Usar la máquina virtual de virtualbox con kmkey preconfigurado. Esta es la opción que tarda más en desacargar, pero la más rápida de poner en práctica, y la única si usais Windows. Se trata de un disco para virtualbox con una Debian Lenny + KMKey instalado, y un site preconfigurado para gestión de calidad (aunque puede configurarse para otros menesteres, claro). Sólo se necesita crear la máquina, adjuntar el disco, y acceder por http://ip.de.maquina a vuestro KMKey. El password de root de la máquina es "demokm", y el usuario administrador de KMKey se llama "adminkmkey" con clave "demokm". Podeis descargar la máquina desde megaupload http://www.megaupload.com/?d=C2UKHM3J

2) Descargar los fuentes de JOINUP Necesitais tener Linux y Zope2.9.4 A partir de ahí, descomprimir los fuentes en el directorio Products de Zope, y seguir las instrucciones de KMKeyCore/doc/INSTALL. El site que se necesita también lo podeis descargar del mismo sitio, viene preconfigurado con patrones de gestión de calidad, su usuario administrador es "adminkmkey", y su clave "demokm"

3) Instalar subversion y acceder a descargar la última rama stable, ejecutando "svn co https://joinup.ec.europa.eu/svn/kmkey/bundles/kmkey-stable" Los requisitos son los mismos que en el punto 2

Espero que lo disfruteis
Leer más...