Comunidad KMKey en Español

Carga automática de valores en vocabularios

2012-01-27T13:14:00.006+01:00

Como ya sabemos, ya sea vía edición de patrón (Admin,Patrones,Campos) o vía zmi; portal_vocabularies, cargar manualmente valores en un vocabulario es algo engorroso, sobre todo cuando tenemos muchos valores

Para facilitarlo hemos habilitado la url /uploadCSV que permite cargar los valores de un vocabulario a partir de un archivos .csv separado por ";"

Especificaciones del archivo de entrada:
- 2 columnas. La primera contiene el ID y la segunda el texto
- Separado por ; (punto y coma)
- Sin comillas ni separador de campos
- Cada item separado por salto de línea \n

Ejemplo:

A;valor1
B;valor2
C;valor3

Método de grabación de vídeos en GNU/Linux

2012-01-24T14:27:00.001+01:00

Para aquellos que estén interesados en cómo grabamos nuestros vídeos de KMKey desde nuestros PC's con GNU/Linux, aquí os adjunto las instrucciones:

1) Instalar gtk-recordmydesktop:

    sudo apt-get install gtk-recordmydesktop mencoder

2) Ejecutarlo con gtk-recordmydesktop y, ANTES de grabar, indicar el destino con el botón "Guardar Como"

3) Seleccionar una área de grabación arrastrando el mouse sobre el Preview

4) Eso nos generará un vídeo en format OGV. Para poder subirlo a youtube necesitamos pasarlo a AVI, ejecutando:

    mencoder video.ogv -o video.avi -oac mp3lame -ovc lavc

 

Video presentación de la configuración SGI

2012-01-24T14:17:00.001+01:00

Adjuntamos vídeo de presentación de la nueva configuración de KMKey Quality para Sistemas de Gestión Integrados (Calidad, Medio Ambiente y Seguridad):

Se puede obtener más información en la página comercial: KMKey SGI

Personalizar envío de notificaciones

2012-01-12T10:59:00.005+01:00

Veréis que al agregar una pill tenéis la opción de "Notificar". Esto envía una notificación por defecto a los usuarios seleccionados

Para personalizar esta notificación realizaremos los siguientes pasos:

1 - Crear un scrit en zmi/portal_skins/custom. (podéis utilizar cualquier nombre de script)
2 - Parámetros de entrada : ob,project,notif,field,translate,_=None,usernames=''

3 - Contenido orientativo del script :

if not ob:
return False

proxy = ob
dm = ob.getContent().getDataModel()
project_dm = project.getContent().getDataModel()
utool = context.portal_url

subject = "Mi Subject"
if not usernames:
usernames = dm['notify_to']

mfrom=''
member = dm['member']
remitente = ''
if member:
brains = catalog(username=member)
if len(brains):
remitente = brains[0].Title
aux = brains[0].getObject().getContent().getDataModel()
if aux['email']:
mfrom = aux['email']

url = utool.getRelativeContentURL(proxy)
if '__' in url:
url = '/'.join(url.split('/')[:-1])

body = """
Aquí va el texto del cuerpo del mensaje, donde podemos adjuntar todos los datos
obtenidos
"""

notif.notifyUsersFromIds(members_ids=usernames, subject=subject, body=body,related_path='',mfrom=mfrom,send_notification_url=False)
something_done = True
return True

4 - Finalmente damos una propiedad a nivel de site (zmi , pestaña properties) , llamada : "custom_skin_for_sendNotifications", del tipo string, y le daremos el nombre de nuestro script

a partir de ahí, las notificaciones enviadas con un campo del tipo KMKey Notification Field, utilizarán este custom script

LDAP en KMKey

2011-12-16T19:53:00.000+01:00

Hace algún tiempo describimos cómo llevar a cabo un Single Sign On (SSO) en KMKey. Hoy vamos a detallar cómo conseguir autentificarnos contra un servidor LDAP, como puede ser Active Directory, sin necesidad de SSO, simplemente usando los mismos nombres de usuario y clave en la página de login de KMKey.

1) Lo primero que vamos a necesitar es instalar algunas librerías y el módulo de python ldap para python2.4:

# Comprobar que disponemos de la rama non-free activada en nuestro /etc/apt/sources.list
suapt-get install libldap-2.4-2 libldap2-dev libnss-ldap python-ldap
apt-get install libsasl2-modules-ldap libsasl2-dev
apt-get source python-ldap
python2.4 setup.py install

2) Seguidamente necesitaremos actualizar o instalar algunos módulos de KMKey. Los podemos obtener mediante subversion:

cd /usr/local/kmkey/zope/Products/
svn co https://joinup.ec.europa.eu/svn/kmkey/products/KMKeyLDAP/trunk KMKeyLDAP
svn co https://joinup.ec.europa.eu/svn/kmkey/vendors/CPSDirectory/branches/kmkey CPSDirectory
svn co https://joinup.ec.europa.eu/svn/kmkey/vendors/CPSUserFolder/branches/kmkey CPSUserFolder

/usr/local/kmkey/zope/bin/zopectl restart

3) Entrar en el Zope Management Interfac (ZMI), ir a portal_directories, y añadir un "CPS LDAP Backing Directory" que se llame "members_ldap", con estas propiedades:

Schemas (old style - for backward compatibility) -> members_ldap
Additional schemas (new style - merged with the previous) -> members_readonly_entry_flag_true
Is the directory read-only? -> Marcado
ACL: entry create roles -> Manager
ACL: entry delete roles -> Manager
ACL: entry view roles -> Manager
ACL: entry edit roles -> Manager
Field for entry title -> cn
Fields with substring search -> cn givenName sn mail
Field for password (if authentication) -> userPassword
LDAP server -> IP del servidor LDAP
LDAP port -> 389
LDAP base -> CN=Users,DC=dominio,DC=win (este es el defecto, pero puede cambiar para cada LDAP)
LDAP scope -> SUBTREE
LDAP object classes (search) -> top, person
LDAP bind dn -> usuariocreado@DOMINI.WIN (corresponde al usuario creado en el punto 2)
LDAP bind password -> clave correspondiente al usuario creado en el punto 2
LDAP rdn attribute (create) -> sAMAccountName
LDAP object classes (create) -> top, person
Field that contains a list of sub entries id for hierarchical directory -> None
attr used as id for children_attr default is ldap_rdn_attr. -> cn
LDAP auto reconnect feature: maximum retry -> 1
LDAP auto reconnect feature: delay in seconds before retrying -> 60.0
LDAP network timeout in seconds for any request (0 means no limit) -> 0.0
Una vez hecho esto, se puede comprobar que funciona la conexión con el LDAP usando la pestaña "Search" del propio directory

4) Finalmente, en el mismo ZMI, en kmkey/portal_setup pestaña Profiles debemos importar el profile "KMKey LDAP"

Y ya lo tenemos disponible. A partir de este momento nuestro KMKey admitirá tanto usuarios locales como usuarios de nuestro LDAP. A éstos últimos se les generará automáticamente un usuario local de KMKey la primera vez que entren, aunque el password será siempre validado contra el LDAP.

Finalmente, tenemos la posibilidad de añadir en portal_skins/custom un script con nombre getLanguageFromLDAP que reciba como parámetro el DN del usuario y devuelva un idioma por defecto, y getSecurityGroupsFromLDAP que reciba el mismo parámetro y devuelva los grupos de permisos a asignar al usuario por defecto durante el proceso de creación.

Mejoras de usabilidad

2011-10-31T14:40:00.000+01:00

Otra de las novedades de la próxima versión de KMKey son sus mejoras en usabilidad. Entre otras cosas, destacan los cambios siguientes:

Hemos rediseñado la forma en que el árbol de navegación se relaciona visualmente con el contenido del cuerpo de pantalla
Hemos ido hacia un entorno con menos color de fondo y menos cargado
Se han cambiado elementos poco intuitivos como los filtros específicos de las pantallas
Se ha relacionado visualmente el filtro de expedientes en curso con el árbol de navegación
Se han reorganizado los menús en 3 niveles: Tab principal, vista actual dentro del Tab y acciones realizables
Se ha cambiado gran parte de la navegación de la aplicación para que ésta pase a realizarse mediante llamadas AJAX, mejorando mucho la experiencia de usuario y evitando recargas de pantalla

Os dejamos una captura de pantalla para que os hagais una idea de cómo se refleja todo lo anterior en el programa:

Facturación Ágil en KMKey

2011-10-31T11:46:00.000+01:00

En la última versión de KMKey hemos desarrollado una funcionalidad adicional para la agilización de la facturación, para los clientes que tienen necesidades de facturar servicios de forma repetitiva, o muchos pequeños importes de golpe. Consiste en una nueva pantalla de facturación donde, a partir de un filtro de expedientes y un período, el programa propone todas las facturas a emitir, permitiéndole al usuario seleccionar las que desee o corregir los importes, para después generar la píldora ingreso, el documento factura en el formato elegido, e incluso enviarlo automáticamente por email a una persona de contacto.

Por el momento existen tres esquemas bajo los que se puede usar dicha facturación, puediéndose aplicar todos a la vez (distinguiéndolos según expediente), o usar únicamente uno de ellos:

Importe fijo. Debe existir en cada expediente una o más Ofertas económicas (previsiones económicas de tipo oferta) aceptadas formalmente. El programa propone en ese caso facturar el importe de la oferta, usando sus mismas línias de factura, conceptos contables, IVA's, etc
Por horas de servicio realizadas. En este caso es necesario que a cada expediente se le asocie una tarifa de precios, donde se especiquen los precios/hora por día laborable o festivo. Opcionalmente se puede asociar un calendario laboral, para diferenciar los días festivos. El programa propondrá facturar el resultado de multiplicar las horas trabajadas en el período por el precio/hora de la tarifa según el día en que se realizaron los servicios fuera laborable o festivo.
Importe diario. Deben existir en cada expediente un o más Ofertas económica aceptada formalmente, y además tener asociado un calendario laboral. El programa propondrá facturar el resultado de mutiplicar el número de días laborables por el importe de la oferta aceptada.

Soporte para folleto bancario 19

2011-09-15T18:34:00.005+02:00

Acabamos de desarrollar en KMKey soporte para la creación de folletos bancarios modelo 19 para presentación telemática, generando un fichero para entregar al banco para que gestione el cobro de recibos. La funcionalidad es bastante simple: con una nueva opción de menú Generar CSB19 tenemos una pantalla con las píldoras ingreso pendientes de cobro.

Antes de empezar debemos definir el emisor. Para ello crearemos una entrada de empresa en la pantalla de grupos que represente la nuestra, si es que no existe ya, y rellenaremos el campo de cuenta cliente que se usará para el ingreso de los recibos. Una vez creado, tendremos que añadir la propiedad 'csb_presentador_docid' en la raíz del site vía ZMI en la que escribiremos el docid del grupo.

Podemos generar el fichero bancario tantas veces como deseemos, por defecto sólo nos saldrán marcados aquellas líneas que no se hayan exportado aún, y en las que sí se haya realizado alguna exportación nos aparecerá la fecha de la misma. No saldrán las ya cobradas. Aquí también es importante que los clientes tengan definido en la ficha de grupo su cuenta corriente, en caso contrario la línea será ignorada en el proceso y no incluída en el fichero de salida.

Una vez pulsemos en Generar, se creará el fichero bancario a enviar al banco.

Próximamente se implementarán otros folletos bancarios.

Como personalizar el logo de KMKey

2011-09-13T17:03:00.000+02:00

Es frecuente que en nuestro KMKey queramos ver el logotipo corporativo de nuestra empresa o institución. Para personalizarlo tenemos que acceder al ZMI (Zope Management Interface), para lo cual necesitaremos un usuario administrador y abrir en un navegador la dirección http://url_de_kmkey/manage

Nos aparecerán las internalidades de KMKey, algo parecido a esto:

En esta interficie tenemos que navegar hasta la carpeta portal_skins/custom y añadir allí un objeto del tipo Image, seleccionando una imagen de nuestro disco duro. Recomendamos usar logos con una altura de entre 50px y 60px para no distorsionar la interficie de KMKey. Debemos recordar el ID que le ponemos a nuestra imagen, por ejemplo logo_empresa.png.

Una vez tenemos la imagen dentro de nuestro ZMI, debemos volver a la raíz del mismo y, en el frame de la derecha, buscar la pestaña Properties. Allí tendremos definidas, y si no lo están las podemos añadir, dos propiedades llamadas logo_path y logo_header_path La primera corresponde al logo que se muestra en la pantalla de login, y el segundo al que se muestra una vez dentro de la aplicación. Debemos completarlas con el valor del ID de la imagen que hemos subido, en nuestro ejemplo sería logo_empresa.png Y con eso ya tenemos nuestro KMKey con logo personalizado

Sustitución de recursos

2011-09-13T12:21:00.000+02:00

En la nueva versión de KMKey disponemos ya de una utilidad para la sustitución automática de recursos, de forma que cuando un recurso, por el motivo que sea (baja, vacaciones, etc), no puede atender los servicios, se puede definir una sustitución por parte de un nuevo recurso durante un período de tiempo. Así, con una sola acción, se borrarán todas las asignaciones de los recursos sustituidos, y se crearan asignaciones nuevas para el recurso sustitutor. La nueva utilidad se encuentra disponible desde la acción Sustituir recurso en las pantallas de Planificar / Recursos y Planificar / Agenda

Formación para Administradores: Los Patrones

2011-09-12T13:53:00.000+02:00

KMKey incorpora un concepto clave, llamado Patrón de trabajo, que podríamos definir como la representación informática de un procedimiento, término muy usado en la gestión de calidad. En informática se asemejaría a un tipo de datos, con la diferencia de que los patrones son configurables visualmente por un administrador, y que además incorporan otras cosas como tratamiento de permisos, flujos de trabajo, o creación de subobjetos.

Siempre que creamos un expediente o proyecto en KMKey lo haremos en base a un Patrón de trabajo. El patrón nos va a determinar, como mínimo:

Qué campos componen la definición del expediente o proyecto
Qué Perfiles vamos a poder asignar a los usuarios de ese expediente o proyecto
Qué estructura de tareas y subtareas, con plazos y esfuerzos, se va a generar asociado al expediente o proyecto
Qué documentos pueden generarse a partir de plantillas en ese expediente o proyecto
Qué conceptos contables van a poder usarse al entrar información económica del proyecto

Para poder crear o editar patrones de trabajo, tenemos que ser usuarios administradores. Si lo somos podemos visitar la opción Admin / Patrones y observar alguno de ellos. Si estando en un patrón visitamos la opción Campos nos aparecerá una pantalla parecida a ésta:

En ella vemos que podemos ir definiendo los campos que necesitamos para componer nuestro patrón o procedimiento. La primera columna corresponde al identificador interno del campo, y es importante NO usar acentos ni espacios en blanco. Se recomienda además usar minúsculas. Obsérvese también que haciendo click en esta columna se puede definir una ayuda asociada al campo, cosa muy útil para procedimientos a usar por usuarios noveles. La segunda columna corresponde a la etiqueta que van a visualizar los usuarios asociada al campo, y es un texto libre. La tercera columna es el tipo de datos, seguida del tipo de widget que se quiere usar para su representación. Después viene el grupo de campos (se pueden definir agrupaciones en la parte final del mismo formulario), el ancho en pantalla, el valor por defecto y una marca que define si el campo es obligatorio. Todo ello acaba generando una pantalla de definición como ésta:

Como widgets principales podemos destacar la Cadena (una linia de texto), el Texto (un bloque de texto), la Selección (donde podremos definir un conjunto de valores internos/externos posibles), la Fecha (que nos deja elegir sobre un calendario) y la Relación con Grupo (que nos deja relacionar el expediente con un cliente, por ejemplo). Hay muchos más widgets disponibles desde las interficies avanzadas, cada uno con sus peculiaridades, pero sólo están disponibles para usuarios con perfil técnico por su mayor complejidad.

Si dejamos la pantalla de Campos y vamos a la pantalla Modificar patrón, veremos que después del título y descripción aparece una campo llamado XML de Creación de objetos. Este XML se usa principalmente para definir la estructura de tareas y subtareas, con plazos y esfuerzos previstos, asociada al patrón, aunque puede tener otros muchos usos. Si usted esta familiarizado con la sintaxis XML, le recomendamos la lectura de la guía Definición del XML de creación de objetos y Usos avanzados del XML de creación de objetos De lo contrario no se preocupe, también disponemos de un Excel capaz de generar el XML básico para la definición de tareas

El siguiente campo corresponde a un XML de Objetos Generables. Se refiere a plantillas OpenOffice contenidas dentro de nuestro propio KMKey que contienen instrucciones para combinarse con datos de nuestros expedientes y generar un documento cumplimentado o semi-cumplimentado. Ejemplos de estos usos son un informe de incidencia, un documento factura o cualquier tipo de informe o documento asociado al patrón que pueda automatizarse. Para la creación de estas plantillas recomendamos la lectura de la Guía para definición de listados Para su uso desde un patrón, se entra en el campo XML algo parecido a:

document
default_title="registro_de_incidencia.doc"
formats="doc#@oo#@pdf"
default_format="pdf"
getDocid="403424947"
view_class="Products.KMKeyDefault.reportsview.SpanishReportsView"
view_context="context.getContent().getKMProject()"/

Donde se especifican formatos de salida, formato por defecto, nombre por defecto, y los más importante, el getDocId o identificador interno de la plantilla.

Nos queda únicamente definir las relaciones Patrón - Perfiles, que son varias:

Campo Perfiles que pueden ser asignados en expedientes creados con este patrón. Permite definir los perfiles que podrán se usados desde los expedientes
Campo Perfiles bloqueados en objetos creados con este patrón. Define los perfiles que se bloquean automáticamente al crear los expedientes con este patrón. Típicamente tendrá marcados los valores Acceso Básico y Creadores de proyectos y contactos.
Campo Los miembros de estos grupos tendrán acceso a todos los expedientes creados con este patrón. Automatismo para asignar grupos de usuarios a todos los expedientes durante su creación. Los grupos marcados serán asignados a cada expediente que se cree asociados al perfil que ellos mismo definen
Pantalla de la opción Acceso al patrón. Esta opción es especialmente importante porque controla qué usuarios podrán crear expedientes usando este patrón. En la columna de la izquierda tenemos los perfiles bloqueados (de nuevo típicamente Acceso Básico y Creadores de proyectos y contactos) y en la columna de la derecha los grupos de usuarios explícitamente permitidos. Para entender el funcionamiento de esta pantalla es necesario haber comprendido previamente el uso de permisos para lo cual recomendamos la Formación sobre permisos NOTA: si crea patrones nuevos por defecto aparecerán todos los grupos bloqueados para evitar que sus usuarios los usen mientras se están definiendo. Ajuste los permisos cuando puedan empezar a usarlo.

Formación para Administradores: Los Permisos

2011-09-12T11:45:00.000+02:00

En primer lugar, para gestionar los permisos es necesario comprender que KMKey tiene una estructura de árbol de objetos: hay una raíz a la que llamamos aplicación, que contiene expedientes o proyectos que a su vez contienen tareas, y éstas contienen lo que llamamos píldoras de información (documentos, notas, horas trabajadas, etc). Por otro lado, tenemos los Perfiles, que no son más que conjuntos de permisos.

La gestión de permisos lo que hace es otorgar un perfil a un usuario en un punto concreto del árbol, lo que le proporciona unos permisos desde ese punto hacia arriba. Esa es la idea principal. Todo lo que viene a continuación son matices sobre esta idea fundamental que no se debe perder de vista. Para ilustrarla con un ejemplo, imaginemos que tenemos un perfil llamado "Jefe de Proyecto", que proporciona todos los permisos, y queremos que el usuario "juan" se el jefe de los proyectos "A" y "C", mientras "pepe" es el jefe del proyecto "B". Si nos vamos a la opción Equipo / Permisos en cada uno de los proyectos y asignamos los respectivos usuarios a su perfil, éstos pasarán a tener control total sobre esos proyectos concretos, sin ni siquiera visualizar los proyectos de otros ("juan" no ve el proyecto "B", por ejemeplo, pero ve todo lo que sucede en "A" y "C")

Bueno, en realidad, además de otorgar un Perfil a un usuario también podemos dárselo a un grupo de usuarios, caso útil si un grupo de empleados trabajan siempre juntos, eso es lo que aparece en el primer cuadro de la pantalla Equipo / Permisos cuando estamos en un expediente o tarea.

Para crear nuevos Perfiles, podremos hacerlo desde la opción Equipo / Grupos / Añadir Grupo / Grupo de Permisos siempre y cuando seamos administradores del sitio. Para crear usuarios haremos lo mismo desde la opción Equipo / Contactos / Añadir Contacto Si somos administradores podremos proporcionarle un nombre de usuario y una clave, y desde la opción Equipo / Permisos (previa selección del punto del árbol en la estructura de navegación de la izquierda), podremos ir asignándole Perfiles.

Observaremos que los perfiles que podemos otorgar van variando según el punto del árbol, son distintos en la raíz que en los proyectos, incluso pueden ser distintos según el tipo de proyecto o expediente. Eso es porque KMKey permite definir qué perfiles son de Aplicación (mediante un checkbox al crear), y qué perfiles son de Patrón (se asocian a cada patrón de trabajo, se hablará de ello en el post específico de patrones de trabajo)

Nos queda por resolver una paradoja. Si creamos un Perfil de Aplicación con permiso de lectura, ¿ eso otorgará a los usuarios que sean asignados acceso a toda la información de KMKey ? Pues sí, efectivamente. ¿ Y cómo funciona el perfil Acceso Básico, que NO da acceso a todo el KMKey ? Pues mediante un sistema que se llama Bloqueo de Perfiles, y que desautoriza un Perfil desde un punto determinado hacia arriba del árbol. Podemos observar esta funcionalidad en la parte final de la pantalla Equipo / Permisos , donde aparece el cuadro titulado "Perfiles bloqueados desde". Tambiés es posible (e imprescindible de hecho), automatizar este bloqueo definiendolo en los patrones de trabajo. Es muy recomendable que todo patrón de trabajo bloquee al menos los Perfiles de Aplicación definidos por defecto (el Acceso Básico y el Creador de proyectos y contactos), de los contrario los expedientes creados con ese patrón serán visibles a todos los usuarios.

Ya para acabar, comentar la existencia un perfil un tanto especial, llamado Owner o Propietario Este perfil existe y proporciona todos los permisos, y se asigna automáticamente al usuario que crea cada objeto. Por ejemplo, si yo creo una nota en un expediente, seré Propietario de esa nota, cosa que me proporcionará el permiso para poder borrarla, por ejemplo, cosa que no podré hacer con la nota de mi vecino, a no ser que posea algún otro Perfil que me deje borrar cualquier cosa en ese expediente. No contradice nada de lo anterior, pero es importante conocer su funcionamiento

Ya para terminar, algunas referencias a otras entradas relacionadas con la temática expuesta:

Filtros y Búsquedas por atributos y contenido

2011-08-24T09:19:00.005+02:00

Describiremos de forma rápida las diferentes formas de buscar información dentro de KM

En KMKey podemos decir que tenemos tres elementos principales de información: Proyectos, Tareas y Pills (Documentos, imputación de horas, gastos, etc)

Tenemos los siguientes tipos de búsqueda:

Búsqueda global de expedientes (Por atributos predefinidos y SearchableText -Cuadro de búsqueda arriba izquierda-)
Búsqueda global dentro de todo KMKey (Por atributos predefinidos y contenido - Cuadro de búsqueda arriba derecha-)
Filtros de Expedientes/Tareas (Por atributos de expediente y tarea, totalmente configurable. - Filtros personalizados-)
Filtros de Pills (Filtramos Documentos, imputaciones, etc. Por atributos predefinidos y búsqueda global (SearchableText) -Gestión --> Historia --> Filtrar-)
Filtros para Informes (Personalizables -Control --> Informes-). Esta opción nos permite listar caulquier tipo de objeto, personalizando todos los atributos y criterios

Las búsquedas globales buscan un texto o palabra clave dentro de todo el contenido de cada objeto y documento (utilizando los campos indexados en el SearchableText y el contenido de los documentos)

Por ejemplo, si buscamos la palabra "Instalación", utilizando el cuadro de búsqueda global (arriba a la derecha) , Nos aparecerá el listado de TODOS los elementos de KM (Proyectos, Tareas, Contactos, Empresas, Documentos) que contengan esa palabra clave en alguno de sus atributos o en el contenido de los documentos adjuntos

Las búsquedas por atributo permiten indicar qué valores o rangos filtramos en cada uno de los atributos (Por ejemplo : "Proyectos del tipo 'Contrato', del los clientes x,j y k, abiertos entre enero y marzo, con un importe de gestión mayor que z", o "Documentos creados entre enero y marzo por el usuario x, que contengan la palabra xxxx")

Finalmente , a través de Control ---> Informes , podemos configurar filtros totalmente personalizados para los reports

Grupos de permisos y Perfiles

2011-07-19T17:41:00.000+02:00

Los grupos de permisos sirven en KMKey para distintas funciones, y ello ha llevado frecuentemente a confusiones. Acabamos de instalar en beta un pequeña mejora para facilitar su comprensión. Aprovechamos aquí para explicar el funcionamiento de cada caso:

1) Perfiles de Aplicación. Cuando un grupo de permisos sirve para crear un perfil que otorga permisos sobre toda la aplicación y su contenido, entonces deberá crearse marcando el checkbox "Es un perfil de Aplicación"

2) Perfiles de Patrones. Cuando un grupo de permisos sirve para crear un perfil que otorga permisos exclusivamente dentro de proyectos o tareas concretos, entonces deberá crearse marcando el checkbox "Es un perfil de Patrones"

3) Grupos de Recursos. Cuando el grupo de permisos se usa para clasificar usuarios como recursos (esto es, las agrupaciones que aparecen en PLANIFICAR / Recursos dentro de un proyecto), entonces deberemos marcar el checkbox "Es un grupo de Recursos". En este caso no son de utilidad los permisos, puesto que no estamos definiendo ningún perfil.

4) Ninguno de los anteriores. En ocasiones un grupo de permisos sirve simplemente para agrupar usuarios y otorgarles permisos en grupo, dando permisos en determinados expedientes o funcionalidades a todo el grupo en su conjunto. En estaas ocasiones no hay que marcar ningún checkbox, y además tampoco son de utilidad los permisos, puesto que no estamos definiendo ningún perfil, sino únicamente una agrupación de usuarios

Nótese que a veces un mismo grupo de permisos puede usarse para más de una funcionalidad a la vez, pero por claridad no se recomienda hacerlo.

La mejora que hemos llevado a cabo permite clasificar mejor los grupos de permisos, y además hemos deshabilitado la opción de asignarlos desde la ficha de contactos, puesto que aparecían todos juntos y despistaban mucho a los usuarios. En su lugar ahora forzamos a que se use la pantalla de EQUIPO / Permisos, que está pensada para ello

Edición en línia de documentos

2011-07-11T11:52:00.000+02:00

KMKey dispone de un sistema de edición en línia de documentos. Eso significa que podemos abrir el documento directamente desde nuestro navegador, editarlo, y que los cambios queden guardatos en KMKey, evitando así el proceso de descargar el documento, guardarlo en nuestro disco duro, editarlo, y después subirlo de nuevo a KMKey.

Para que esto sea posible, es imprescindible que las estaciones cliente (los PC's de los usuarios), tengan instalado el programa zopeedit. Este programa es el que permite la comunicación entre KMKey y nuestro editor. Se trata también software libre, y se encuentra disponible tanto para Windows como para Linux. Se puede descargar desde
http://www.plope.com/software/ExternalEditor

La distribución binaria para Windows incluye todo lo necesario para instalar la aplicación auxiliar. Simplemente hay que lanzar el ejecutable de instalación para instalar y configurar la aplicación auxiliar para uso con Internet Explorer. También puede registrarse (zopeedit.exe) directamente con otros navegadores.

Una vez tengamos instalado zopeedit, ya podemos ir a nuestro KMKey, ir a la pantalla de edición de un documento, y pulsar en el link "Edición en línia": Una vez hecho esto, si el navegador nos pide con qué aplicación queremos abrirlo, tendremos que escoger "zopeedit.exe", y éste a su vez tendría que lanzar el editor correspondiente al formato del documento. Si ésto no sucediera así, tendríamos que revisar el fichero de configuración de zopeedit (zopeedit.ini en Windows, .zope-external-edit en Linux), donde se relacionan los tipos de documento con los editores correspondientes.

Hay más información disponible en la página del producto

Como requerir passwords fuertes en KMKey

2011-07-08T13:12:00.000+02:00

Es una buena costumbre definir una política de seguridad que requiera a los la necesidad de usar claves fuertes, en cualquier sistema informático. En KMKey eso puede llevarse a cabo fácilmente, entrando como administradores al ZMI (http://tusitio/manage), y editando las propiedades del widget "portal_layous/kmkey_contact/w__password". Concretamente las propiedades útiles en este sentido son:
- "Minimum input width", para definir la longitud mínima
- "Checking at least one lower case [a-z]", para forzar al menos una letra minúscula
- "Checking at least one upper case [A-Z]", para forzar al menos una letra mayúscula
- "Checking at least one digit [0-9]", para forzar al menos un numérico
- "Checking at least one extra char other than [a-zA-Z0-9]", para forzar al menos un caracter que no sea alfabético ni numérico

Asignación rápida de contactos desde grupos

2011-04-19T12:53:00.003+02:00

Se ha incorporado al KMKey una mejora de usabilidad para facilitar la gestión de grupos y contactos. Hasta ahora las relaciones se definían editando un contacto y seleccionando desde allí a qué grupos pertenece y a cuáles no. Ahora se ha añadido la posibilidad de asociar contactos existentes rápidamente desde la pantalla de equipo con un cuadro de texto con funcionalidad de autocompletado, el mismo que aparece en otras partes de la aplicación.

Pero la mejora no sólo se queda aquí: también permite la creación rápida de un contacto e asociarlo immediatamente con el grupo seleccionado, si entramos un nombre que no esté aún dado de alta en la aplicación. El campo se puede rellenar tanto en formato “Apellidos, Nombre” como la visualización de los demás contactos así como el más natural “Nombre Apellidos” para los nombres simples. Además de crear el contacto, permite añadir algunos datos básicos como la dirección de correo electrónico o los teléfonos, que por defecto tomará del grupo.

Novedades en KMKey: pantalla de documentos y algo más

2011-04-05T13:56:00.000+02:00

La pantalla del listado de documentos, accessible a través de la pestaña Gestión, ha sido rehecha con nuevas funcionalidades. Con un aspecto más similar al historial de píldoras, que ya permite filtrar por sólo documentos, podría parecer que no aporta nada nuevo, pero no es así.

Esta pantalla permite descargar directamente los ficheros publicados haciendo clic en su título, y muestra los detalles al hacer clic en el símbolo «+». Los iconos de la derecha son una representación gráfica del estado de cada documento. La primera columna nos dice si el documento es una versioń final (verde), bloqueada (naranja) o en proceso de edición (azul). Las otras columnas nos detallan en qué etapa del proceso de edición se encuentran, algo especialmente útil para visualizar rápidamente en qué estado de un ciclo documental ISO nos hallamos: aquí los círculos verdes son las etapas ya superadas y el azul la actual. La información del ciclo de edición no se limita a eso, si ubicamos el cursor encima del círculo azul de la etapa en proceso obtendremos una lista de los usuarios de la aplicación que pueden actuar sobre el documento, sabiendo pues en qué manos se encuentra el ciclo.

También se han programado filtros específicos para que sea más fácil localizar documentos. Además del criterio de contenido del documento, podemos buscar aquellos que estén en una etapa específica del ciclo de edición o aquellos que se encuentren en un estado definitivo, sin modificaciones de versiones pendientes, así como aquellos documentos en edición para los que un usuario pueda actuar sobre ellos. Así un usuario puede obtener la lista de documentos para los que se espera actúe de una forma u otra.

Adicionalmente, y relacionado con los filtros, se ha añadido la posibilidad de definir un filtro de proyectos y tareas por defecto a nivel de site. Una vez creado el filtro dentro de KMKey, podemos tomar el parámetro kmkey_menu_option de la URL del filtro y ponerlo en una nueva propiedad de site llamada default_menu_option configurable vía ZMI.

KMKey Help Desk y mejoras en la productividad.

2011-03-07T11:36:00.014+01:00

¿Cómo monitorizar las entradas de incidencias ? : Con la ayuda de un televisor de gran formato y KMKey Help Desk

Poco después de terminar una reciente instalación de KMKey Help Desk en Colombia el cliente nos comentó que tenía la idea de conectar el sistema a un televisor de gran formato de manera que los técnicos pudiesen visualizar la entrada de incidencias asignadas a su nombre y se dispusieran para su solución de inmediato.
La compañía se dedica a la instalación, gestión y mantenimiento de redes eléctricas, redes de datos, sistemas de seguridad, telecomunicaciones y centralitas telefónicas de las que tiene instaladas una buena cantidad y es una empresa en pleno creciemiento que ha confiado la gestión de sus incidencias en KMKey Help Desk

Estos eran sus comentarios:

"Adjunto la foto del televisor que dejamos para tener registro de incidencias activas y donde todo el personal puede visualizar todos los servicios asignados. Llevamos 2 días con el televisor activado y ha generado muy buenos resultados ya que todos los involucrados se preocupan bastante por los tiempos de solución y cierre de tickets y comparan sus resultados con los de los otros compañeros, ninguno quiere ver su registro en rojo y de inmediato proceden a realizar la gestión de la incidencia, Ayuda a acelerar el proceso de incorporación de KMkey en los procesos de la empresa."

J. Castaño.
Redesistemas
http://www.redesistemas.com/

Integración con BinarySender para envío de SMS's

2011-03-04T19:14:00.006+01:00

Recientemente hemos llevado a cabo una integración entre KMKey y la plataforma de envío de SMS's binarysender La aplicación principal es el envío de notificaciones desde KMKey Helpdesk, tanto para avisar a técnicos de nuevas incidencias, para notificar a clientes el plazo de ejecución de una incidencia, o para comunicarle su feliz resolución :-) Este es una funcionalidad muy valorada por los usuarios de KMKey Helpdesk, puesto que aporta un importante valor añadido al servicio que ofrecen.

Se ha elegido esta plataforma por sus precios competitivos, por su uniformidad de precios en el envío de SMS's a Sudamerica (donde tenemos numerosos KMKey's en marcha), y por la facilidad que ofrece su entorno web a nuestros usuarios para adquirir paquetes de mensajes y controlar el gasto en SMS's al detalle, pudiendo incluso consultar uno por uno los SMS's enviados desde KMKey. Si eres un técnico de Helpdesk lo sentimos por ti, a partir de ahora no vas a poder decir que no te has enterado de una incidencia, ya que estos SMS's tienen además acuse de recibo.

La integración se ha llevado a cabo mediante SOAP y usando el web service de la plataforma, del cual se puede consultar el WSDL

Para su correcto funcionamiento en KMKey hay que instalar el módulo python suds, así:
sudo easy_install-2.4 suds

Nuevos Vídeos de Ayuda para KMKey Help Desk

2011-03-04T12:07:00.003+01:00

Se han actualizado los vídeos demostrativos de la aplicación KMKey Help Desk.
Respondiendo al rediseño y mejora de algunas de las prestaciones de KMKey Help Desk se han incorporado 4 nuevos vídeos de demostración de su funcionamiento.

En el primero podemos ver la simulación del ciclo de una incidencia, desde su recepción hasta su solución y se muestran los automatismos y notificaciones que se generan entre los participantes.

Ver vídeo

En el segundo vídeo podemos ver como se registra y gestiona un mantenimiento preventivo, su asignación a un receptor y la simulación de una primera intervención del mismo.

Ver vídeo

En el trercer vídeo podemos ver como se realiza la creación de un contrato de servicio y de paso se muestran los procedimientos básicos para dar de alta un cliente, un contacto y asociar el contacto a un contrato de servicio.

Ver vídeo

Por último en el cuarto vídeo se muestra cómo obtener informes y listados de todas las actividades realizadas con KMKey Help Desk y obtener la información relativa a las incidencias, los contratos de servicio, los elementos a mantener, el esfuerzo realizado, los clientes y los contactos asociados.

Ver vídeo

Soporte para múltiples zonas horarias

2011-02-23T18:03:00.003+01:00

Acabamos de incorporar en entorno beta (rama svn trunk) un conjunto de cambios para ofrecer detección y soporte del uso horario. El uso horario se detecta y aplica por usuario, de forma que incluso dentro de un mismo KMKey cada usuario podrá trabajar y visualizar su propio uso horario. Esta mejora facilita enormemente la implantación de servicios SAAS (Software As A Service) internacionales basados en KMKey, y también el trabajo en KMKey's con usuarios provinientes de múltiples paises.

Por poner un ejemplo, ahora cuando un comercial de México abra una oferta de implantación a las 10:00 de la mañana hora local, en Europa veremos aparecer sus intervenciones registradas a las 17:00. Cada uno verá su hora local, y el sistema se encargará de automatizar los cambios horarios de forma transparente.

En cuanto a los detalles de la implementación, se ha realizado llevando a cabo una detección del uso horario en javascript, en la pantalla de login. Esa información se guarda en una cookie, que después es usada para llevar a cabo las conversiones. En base de datos, la información es guardada siempre en el uso horario configurado en el servidor para simplificar la explotación. Finalmente, es necesario parchear un módulo de zope, concretamente el DateTime.py Adjuntamos aquí la dirección del parche por ser éste un tema largamente demandado por usuarios de Plone y que puede ser fácilmente transplantado desde KMKey a Plone:
https://svn.forge.osor.eu/svn/kmkey/patches/timezone

Vídeos en Inglés

2010-12-13T17:57:00.002+01:00

Para la comunidad de usuarios anglófona se han traducido al inglés los vídeos más importantes de las páginas:

http://www.kmkey.com/en/help/project

y también en:

http://www.kmkey.com/en/help/helpdesk

Registro de Infraestructuras, Planes de Calibración/Mantenimiento y registro de las Acciones de Calibración/Mantenimiento.

2010-10-05T13:00:00.003+02:00

Después de solucionar puntualmente el problema para algunos clientes nos decidimos a fabricar un patrón/esquema de trabajo que pudiese solucionar de forma conjunta y coherente los siguientes aspectos:

El registro de la maquinaria (Instrumental, equipamientos) que una organización puede tener en el desempeño de sus actividades operativas.
Los planes de mantenimiento y/o calibración asociados a dicha máquina.
El registro de las acciones de Mantenimiento y/o calibración efectuados en dicha máquina.

Registro de maquinaria/Instrumental
Para ello confeccionamos un patrón cuyo cometido es el de dar de alta a cada máquina por separado cumplimentando campos tan generales como. Fabricante, Modelo, Nº de Serie, Fecha de compra, Fecha de Instalación, Localización de la misma, etc.
Se entiende que cada cliente podrá adaptar estos campos a sus necesidades.
Se crea un expediente en el navtree por cada una de la máquinas que se registran.

Planes de Intervenciones
En este expediente se incluye una tarea genérica que se denomina: Planes de Mantenimiento/Calibración.
Cuando la tenemos seleccionada podemos ir al TAB PLANIFICAR > Flujo de Trabajo y vemos como se nos ofrece la posibilidad de elegir un plan de Mantenimiento/Calibración con una duración de un año y distintas periodicidades para la revisión, desde una al año hasta una cada mes.
Estos periodos figuran como ejemplo y cada cliente también los puede o podrá, ajustar a sus necesidades.
Lo que sucede a continuación es que se crea una Agrupación con tantas tareas como divisiones hemos hecho del año, mensual=12, bimensual=6, trimestral=4, etc...
Cada una de esas tareas tiene una fecha de inicio y una fecha de final que corresponde al periodo previsto en el cual se deben llevar a cabo los trabajos de Mantenimiento y/o Calibración a dicha instalación.

Registro de Acciones de Mantenimiento/Calibración
Así pues, llegado el día de efectuar la acción de Mantenimiento y/o Calibración en dicha máquina se puede registrar la misma a través de una "pill" personalizada.
Esta "pill" se encuentra en el TAB GESTIÓN > Añadir.
Como en el caso anterior, los campos de la misma se podrán adaptar a las necesidades de cada cliente y si a es una acción de Mantenimiento o es una acción de Calibración.
Una vez registrada se pueden añadir más elementos de gestión (notas, documentos, e-mails, horas de esfuerzo, etc) a través de las pills habituales.

Planes para otros años/periodos
Llegado el caso, podemos haber agotado ya las revisiones a efectuar a dicha máquina y nos vemos con la necesidad de añadir un nuevo Plan de Mantenimiento y/o Calibración para el año siguiente.
Pues bien, en dicho caso, bastará con volver a seleccionar la tarea genérica: Planes de Mantenimiento/Calibración, seleccionar la fecha de referencia adecuada y volver a solicitar la inclusión de un Plan, con la periodicidad que queramos.
De esta forma se mantiene la unidad documental y de registro para cada máquina y puede mantenerse durante el tiempo de vida de la misma.

Informes
Al final del ejemplo se añadieron dos informes.
Con uno podemos obtener un listado de todas las máquinas instaladas en la organización.
Y con el otro, este ya dedicado a cada máquina en particular, se puede obtener un resumen de las intervenciones que se habían efectuado en la misma a través del tiempo.

Ver ejemplo en el vídeo dedicado.

Enlazar datos de KMKey desde aplicaciones externas

2010-06-29T16:52:00.002+02:00

Es frecuente la necesidad de enlazar o volcar datos de KMKey desde aplicaciones externas, como puede ser algún programa de gestión externo, una intranet, etc. Una forma de abordar esos casos es escribiendo código python y usando ZODB, pero ese es un camino poco conocido para la mayoría de técnicos, y que requiere un tiempo de aprendizaje elevado. Afortunadamente, hay un camino mucho más sencillo y que conocen la gran mayoría de los técnicos: el uso de SQL.

En primer lugar, necesitamos instalar el conector python-psycopg y el producto ZPsycopgDA, tal y como se explicó en http://kmkey-es.blogspot.com/2009/05/pasar-schemas-sql.html

Una vez hecho esto, vamos al ZMI (http://sitio/manage), a portal_schemas, y localizamos los schemas o schemas de los cuales queremos obtener información y los configuramos para que usen SQL. Por ejemplo, imaginemos que queremos obtener información de documentos de un sistema de calidad, iríamos a portal_schemas/kmkey_document, pestaña "SQL", pondríamos el nombre de nuestra conexión "db" y pulsaríamos el botón "Migrate to SQL". Si después de hacer eso visitamos nuestra base de datos PostgreSQL veremos que ha aparecido una tabla nueva de nombre "kmkey_document" que contiene información de los documentos existentes en KMKey.

A partir de aquí, se trata de atacar esa base de datos SQL desde nuestro entorno preferido (todos ellos dispondrán de un sistema de conexión a PostgreSQL). Siguiendo con el ejemplo, imaginemos que tenemos un expediente de gestión documental de ISO 9001 y que queremos obtener información de todos los documentos del punto 4 de la norma. Ejecutaríamos algo como:

select * from kmkey_document where proxy_path like 'workspaces/kmkey/iso-9001-san-nicolas/4-sistema-de-gestion-de/%';

Observemos que en el campo "file" llega una estructura de valores id#=#title#=#content_type#=#filename Con el filename podremos ir a buscar el físicamente el fichero que se encontrará típicamente en nuestro servidor bajo /var/zope/storages/kmkey/files/A/B/filename siendo A/B las dos primeras letras de filename

Las sentencias pueden ser todo lo elaborados que sea necesario, por ejemplo si queremos mostra únicamente la última versión de cada documento, quedaría algo como:

select * from kmkey_document d where proxy_path like 'workspaces/kmkey/iso-9001-san-nicolas/4-sistema-de-gestion-de/%' and current_revision = (select max(current_revision) from kmkey_document d2 where d.internal_docid = d2.internal_docid);

Como se puede observar, una de las ventajas de usar un sistema de código abierto es que no hay información oculta, y podemos integrarla fácilmente con el resto de entornos de la empresa

Patrones de trabajo avanzados

2010-06-14T12:30:00.005+02:00

Anteriormente se documentó la forma de definir XML's básicos de patrones de trabajo. Puede
consultarse dicha entrada en: Comunidad KMKey en Español: XML para definir objetos en patrones

Ahora vamos a centrarnos en introducir funcionalidades más avanzadas, de forma que empecemos a usar todo el potencial de esta herramienta que son los patrones de trabajo.

Bloquear o desbloquear perfiles en una tarea

Nos permite bloquear o desbloquear explícitamente ciertos perfiles en una tarea del patrón. Corresponde al apartado de Perfiles Bloqueados de la pantalla de Equipo / Permisos cuando nos encontramos en un expediente ya creado. Los role1, role2, .. etc, corresponden al nombre interno
del perfil, que puede consultarse en el campo Perfil Relacionado de un grupo de permisos.

Asignar perfiles a usuarios o grupos concretos

La nomenclatura es usernames="user1,user2" roles="role_para_user1,role_para_user2", manteniendo una concordancia de usuarios y perfiles.

La misma sintaxis puede usarse para asignar perfiles a usuarios o grupos dentro de una tarea concreta, usando la jerarquía del XML:

</task>

Uso de patrones de tareas distintos

El tag default_portal_type permite asociar un portal_type por defecto a un tag XML. El caso más típico es el de los tags task usados para la definición de tareas. Pero podemos desear que ciertas tareas se creen usando otro patrón de tareas, por ejemplo en casos que necesiten disponer de campos específicos en la definición de la tarea. En esos casos, se puede usar el atributo portal_type dentro del propio tag task para definir un patrón de tarea a utilizar distinto del establecido por defecto.

<?xml version="1.0" encoding="iso-8859-1" ?>

<default_portal_type tag="task" portal_type="KMKey Task" />

</objects>

Uso de TAL para cambiar el patrón segun valores de los campos de Definición

Otra funcionalidad muy interesante es la de poder hacer uso del sistema de plantillas TAL para generar un XML dinámico de definición del patrón de trabajo. Se puede encontrar más información sobre la sintaxis del Template Attributes Language en la red, pero dejamos aquí un enlace a una guía introductoria: http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/ZPT.stx

El uso de TAL nos permite, por ejemplo, condicionar ciertas tareas a determinados valores de campos de la Definición del expediente, o incluso hacer bucles para crear una tarea N veces. Hay que tener claro que las instrucciones TAL se ejecuta en primer lugar, generando un XML resultante que se procesa en segundo lugar, dando lugar a la generación del expediente. Veamos aquí un ejemplo de una tarea condicional:

<?xml version="1.0" encoding="iso-8859-1" ?>

<default_portal_type tag="task" portal_type="KMKey Task" />

Subir el IVA en KMKey

2010-06-11T17:28:00.002+02:00

Como algunos de vosotros sabreis, el gobierno español ha decretado subir los tipos de IVA a partir del próximo mes de julio de 2010, pasando a ser del 18%, 8% y 4% respectivamente. Este cambio quedará lógicamente incorporado en próximas versiones de KMKey, pero como la entrada en vigor es inminente, explicamos aquí los pasos a seguir para incorporar los nuevos tipos de IVA, sea cual sea nuestra versión de KMKey:

1) Entramos en el ZMI (http://url_de_nuestro_kmkey/manage)
2) Vamos al site kmkey, apartado portal_skins/custom
3) Creamos un objeto de tipo "Script (python)", escogiéndolo en el seleccionable de arriba a la derecha
4) Lo podemos llamar, por ejemplo "paga_y_calla", y pulsamos el botón "Add and Edit"
5) Escribimos o copiamos las siguientes linias de codigo:

voc = context.portal_vocabularies.kmkey_tax
voc.clear()
voc.set('18.0', '18 %')
voc.set('16.0', '16 %')
voc.set('8.0', '8 %')
voc.set('7.0', '7 %')
voc.set('4.0', '4 %')
voc.set('0.0', '0 %')
return 'Subida del IVA completada'

6) Pulsamos la pestaña "Test"

Y eso es todo, ya estamos preparados para pagar un 18% de IVA (o no)

Ordenar menús y filtros

2010-06-10T14:58:00.003+02:00

Para ordenar la lista de menús tenemos una variable de site

menu_sort_item

entramos a zmi, damos de alta la nueva propiedad en el site (string) y le indicamos el nombre del campo por el cual queremos ordenar (title para alfabético, por defecto ordena por id)

Sistema de backups con xdelta

2010-05-13T10:08:00.005+02:00

Un sistema de backups es a un entorno informático como la red anticaídas a un equilibrista, nos puede salvar la vida ante un tropezón. Un buen sistema debe permitir recuperar el estado de los datos lo más cercano posible al momento clave ante cualquier desastre, por improbable que parezca. Además debe permitir recuperar datos a una fecha más o menos lejana, sin mayores dificultades.

Para entornos de alta disponibilidad, y con datos muy críticos, la mejor opción sin duda es la replicación de bases de datos en vivo. Pero lo más habitual es que exista una tolerancia de un día, es decir, disponer siempre del backup de la noche anterior es suficiente. En estos casos, se puede optar por un sistema de backups incrementales, o por uno de backups siempre completos. El primero ahorra espacio, pero el segundo facilita una recuperación más rápida y simplifica los procesos de generación del backup. Existe una tercera vía, que es la de los backups completos y rotativos, más el uso de xdelta para ahorrar espacio, y ésa versión menos habitual es la que vamos a exponer aquí

xdelta es un software libre capaz de generar ficheros de diferencias a partir de dos ficheros binarios. También permite regenerar un fichero binario a partir de una versión antigua + un fichero de diferencias . Además se usará rsync para replicar usando poco ancho de banda. Para los usuarios de Debian, su instalación no puede ser más sencilla:

apt-get install xdelta rsync

Para implementar el sistema de backups, necesitamos un mínimo de 3 máquinas: los servidores de bases de datos, el servidor de backups y el servidor de réplicas remotas. El servidor de base de datos (pueden ser varios) y el de backups deben estar en el mismo datacenter, con una conexión LAN entre ellos. El servidor de réplicas remotas debe encontrarse en otra ubicación con una conexión dedicada SDSL o similar. A partir de aquí los pasos son:

1) En el servidor de backups, rotamos a diario 6 copias de seguridad de la semana, manteniendo una completa en daily.0 pero un diff binario respecto a la semanal en el resto.

rm -r daily.5
mv dailiy.4 daily.5
mv dailiy.3 daily.4
mv daily.2. daily.3
mv daily.1 daily.2
mv daily.0 dailiy.1
xdelta delta weekly.0/fichero daily.1/fichero daily.1/fichero.diff
rm daily.1/fichero
mkdir daily.0

2) En el servidor de base de datos, generamos a diario la copia completa en el disco local , y la replicamos sobre un servidor de backups (sobre daily.0)

3) Semanalmente, el servidor de backups convierte una copia diaria en una semanal:

cp -a daily.0 weekly.0

4) También semanalmente, el servidor de réplicas rota y copia las semanales mediante un rsync (cosa que sólo transfiere las diferencias de datos respecto a la semana anterior, en lugar de hacer una copia completa por línea):

rm -r weekly.4
mv weekly.3 weeky.4
mv weekly.2 weekly.3
mv weekly.1 weekly.2
cp -a weekly.0 weekly.1
rsync -av --timeout=180 -e "ssh -p 22" usuario@servidor_backups:/path/a/weekly.0 /path/a/weekly.0

Con este sistema podemos recuperar cualquier copia completa de la última semana, y copias semanales de todo el mes anterior. Si se considera necesario guardar más antiguedad, sólo hay que añadir una rotación mensual en el servidor de réplicas. Si hay problemas en el servidor de datos, podemos recuperar la copia nocturna del día anterior del servidor de backups, y si explotara el datacenter entero, tendríamos los datos recuperables con una máximo de una semana de antiguedad en el servidor de réplicas. Garantías más que suficientes para el 95% de los negocios. Y tus datos, ¿ están así de seguros ?

Widgets para mapas en KMKey

2010-05-05T19:42:00.004+02:00

Hemos añadido a KMKey uns nuevo widget muy interesante. Hace uso de openlayers y openstreetmap para localizar ubicaciones a partir de campos de los expedientes, y mostrar completos mapas interactivos de las mismas, al más puro estijo google maps, pero asociados a nuestros expedientes de KMKey. No contentos con ello, el widget permite además añadir datos al mapa, como linias o polígonos que representen una parcela, una obra o un edificio. Estos datos son guardados como una capa propia, y se superponen a los provenientes de openstreetmap.

Para usar este widget es suficiente con ir al ZMI portal_layouts/nuestro_patron y añadir un widget del tipo "KMKey map widget". Debemos asociar 3 campos que previamente deben haberse creado en el portal_schemas/nuestro_patron. Por este orden, son longitud (float), latitud (float) y zoom (int). También nos da la posibilidad de configurar los ID's de los campos de calle, población y país a partir de los cuales llevar a cabo la localización de ubicaciones. Finalmente, nos pide laURL del servidor featureserver que se encarga de guardar los datos de la capa de modificaciones. Lo mejor para este servidor featureserver es instalarlo como CGI bajo el mismo dominio que estemos usando (las instrucciones de instalación de este software estan bien detalladas en featureserver.org)

Bueno, ¿ quien dijo que con software libre no se pueden tener soluciones profesionales ?

Soporte para IMAP y servidores con SSL

2010-04-29T17:44:00.004+02:00

Hasta la fecha el sistema de recepción de mensajes a KMKey para su inclusión automática sólo era posible mediante una cuenta de correo accesible vía el protocolo POP3 sin cifrado SSL. Ahora se han implementado tanto el acceso a un buzón mediante el protocolo IMAP así como el uso de SSL en ambos protocolos para acceder a los mismos. En esta entrada se explicarán los pasos a seguir para configurar un site KMKey ya en funcionamiento para hacer uso de las nuevas funcionalidades.

En primer lugar, para usar un buzón IMAP habrá que sustituir el fichero KMKeyCore/utils/email_scan.py por el nuevo email_imap_scan.py. Los parámetros de configuración pop3_server, pop3_user y pop3_password, pese a su nombre, serán utilizados para el acceso vía IMAP al buzón. Estos parámetros son modificables desde la pestaña “Properties” del site en el Zope Management Interface (ZMI). Si dichas propiedades no existieran por no haberse configurado aún ningún servicio de correo, se pueden crear siguiendo estas instrucciones.

Una de las características del protocolo IMAP es que permite mútiples buzones para una misma cuenta. Eso hay que tenerlo en cuenta en el caso que los correos destinados al KMKey no lleguen a un buzón llamado INBOX. Lo usual es que sea así, pero si no fuera el caso basta con editar el script Python, buscar la declaración imap_folder = 'INBOX' y cambiarla por el valor adecuado.

Finalmente, para habilitar el acceso vía SSL al buzón, sea por el protocolo IMAP o el POP3, sólo hay que añadir una propiedad llamada pop3_ssl de tipo booleano en las propiedades del site vía ZMI. Aparecerá entonces una casilla seleccionable que, de estar marcada, hará que el script de captura de correo use el acceso cifrado al buzón.

Single Sign On (SSO) con KMKey

2010-03-26T15:51:00.009+01:00

Es frecuente plantearse integrar KMKey con algun sistema de autentificación de usuarios tipo LDAP o Active Directory. En el presente artículo vamos a explicar cómo puede conseguirse que una instalación de KMKey detecte nuestro usuario de trabajo en el dominio (a través del navegador) y ni tan sólo nos pida password si ya nos hemos validado contra el dominio

1) Para ello lo primero que vamos a necesitar es instalar algunas librerías, y el producto SSOAuth, que podemos descargar usando subversion:

# Comprobar que disponemos de la rama non-free activada en nuestro /etc/apt/sources.list
su
apt-get install libldap-2.4-2 libldap2-dev libnss-ldap python-ldap
apt-get install krb5-clients krb5-config krb5-user libkrb5-dev libkrb53
libpam-krb5 libapache2-mod-auth-kerb libkadm55 libapache2-mod-fastcgi
libsasl2-gssapi-mit libsasl2-modules-gssapi-mit libsasl2-modules-ldap

su zope
cd /usr/local/kmkey/zope/Products/
svn co https://svn.forge.osor.eu/svn/kmkey/products/SSOAuth/trunk SSOAuth
/usr/local/kmkey/zope/bin/zopectl restart

2) Crear un usuario en al Active Directory / LDAP, con password que NO CADUQUE. No hace falta que sea administrador, pero si que tenga lectura sobre todas las ramas que necesiten autentificarse en KMKey

3) Entrar en el Zope Management Interfac (ZMI), ir a portal_directories, y añadir un "CPS LDAP Backing Directory" que se llame "members_ldap", con estas propiedades:

Schemas (old style - for backward compatibility) -> members_ldap
Additional schemas (new style - merged with the previous) -> members_readonly_entry_flag_true
Is the directory read-only? -> Marcado
ACL: entry create roles -> Manager
ACL: entry delete roles -> Manager
ACL: entry view roles -> Manager
ACL: entry edit roles -> Manager
Field for entry title -> cn
Fields with substring search -> cn givenName sn mail
Field for password (if authentication) -> userPassword
LDAP server -> IP del servidor LDAP
LDAP port -> 389
LDAP base -> CN=Users,DC=dominio,DC=win (este es el defecto, pero puede cambiar para cada LDAP)
LDAP scope -> SUBTREE
LDAP object classes (search) -> top, person
LDAP bind dn -> usuariocreado@DOMINI.WIN (corresponde al usuario creado en el punto 2)
LDAP bind password -> clave correspondiente al usuario creado en el punto 2
LDAP rdn attribute (create) -> sAMAccountName
LDAP object classes (create) -> top, person
Field that contains a list of sub entries id for hierarchical directory -> None
attr used as id for children_attr default is ldap_rdn_attr. -> cn
LDAP auto reconnect feature: maximum retry -> 1
LDAP auto reconnect feature: delay in seconds before retrying -> 60.0
LDAP network timeout in seconds for any request (0 means no limit) -> 0.0

Una vez hecho esto, se puede comprobar que funciona la conexión con el LDAP usando la pestaña "Search" del propio directory

4) Entrar de nuevo via ZMI, borrar el objeto "cookie_authentication" y crear en su lugar un objeto "Secure Auth" con nombre "secure_auth"

5) Crear usuarios KMKey a partir de usuarios LDAP. Los usuarios de KMKey, además de tener un registro en portal_directories, necesitan tener un contacto asociado, con toda una serie de propiedades que no estan disponibles en un LDAP. Es por ello que la mejor opción es programar un script de traspaso periódico de usuarios del LDAP hacia KMKey. Este script puede ponerse en el cron y ejecutarse mediante zope/bin/zopectl run script.py diariamente, y lo que va a hacer es crear una entrada de usuario KMKey para cada usuario LDAP, SIN traspasar nunca el password, que siempre va a validarse contra el controlador de dominio. El contenido del script variará en función de la estructura del LDAP origen. Se incluye aquí un ejemplo de script:

from AccessControl.SecurityManagement import newSecurityManager
from Testing.makerequest import makerequest
from Products.KMKeyCore.pattern import KMObjectCreationAdapter
user = app.kmkey.acl_users.getUser('manager').__of__(app.kmkey.acl_users)
newSecurityManager({}, user)
app = makerequest(app)
km = app.kmkey
ldap = km.portal_directories.members_ldap
entries = ldap._searchEntries(return_fields=['*'])
user_entries = [entry for (id, entry) in entries if entry['sAMAccountName'] and entry['sn']]
container = km.workspaces.kmkey
portal_type = 'KMKey Contact'
adapter = KMObjectCreationAdapter(container)
ti = km.portal_types.getTypeInfo(portal_type)
cat = km.portal_catalog
for entry in user_entries:
brains = cat(meta_type='KM Contact', username=entry['sAMAccountName'])
if len(brains) == 1:
print "Ya existe " + brains[0].username
else:
dm = ti.getDataModel(ob=None, proxy=None, context=container)
dm['language'] = 'es'
dm['email'] = entry['mail']
dm['phone'] = entry['telephoneNumber']
dm['sn'] = entry['sn']
dm['username'] = entry['sAMAccountName']
dm['givenName'] = entry['givenName']
adapter.createObject(portal_type, dm)

get_transaction().commit()

6) Compilar el modulo mod_ntlm para apache2

Se puede descargar libremente de internet. Cuesta un poco compilarlo, porque el Makefile apunta a apxs en lugar de apxs2. También deja cosas dentro de .libs/ que luego no encuentra. Se debe ir haciendolo manualmente, pasito a pasito, hasta que funcione y tengamos el módulo válido

7) Configurar Zope para que escuche también por fascgi

sudo mkdir /var/run/zope
sudo chown -R zope.zope /var/run/zope

vi /usr/local/kmkey/zope/etc/zope.conf
<fast-cgi>
address /var/run/zope/fcgi
</fast-cgi>

8) Configurar Apache.

Es importante el tema del /htdocs o el módulo de FastCGI no funciona

sudo mkdir /htdocs
sudo touch /htdocs/zope
sudo cp /home/earcon/nommaquina.keytab /etc/apache2/
cd /etc/apache2/mods-enabled
sudo ln -s ../mods-available/fastcgi.* .

Antes del VirtualHost:
FastCgiExternalServer /htdocs/zope -socket /var/run/zope/fcgi -pass-header Authorization -pass-header Cookie

Dentro del VirtualHost:

<Location /zope >
Allow from all
Order allow,deny
SetHandler fastcgi-script
</Location>

<Location /zope/kmkey/ >
AuthType NTLM
NTLMAuth on
NTLMAuthoritative on
NTLMDomain DOMINIO.WIN
NTLMServer cpd-dc1
Require valid-user
</Location>

# Para acceder SIN SSO
RewriteCond %{REQUEST_URI} !^/zope.*
RewriteRule ^/(.*) balancer://lb/VirtualHostBase/http//%{HTTP_HOST}:80/kmkey/VirtualHostRoot/$1 [L,P]

9) Verificar, en las estaciones clientes, que el Internet Explorer tiene activada la casilla de "Autentificacion Integrada en Windows" en las opciones avanzadas. También que el dominio de KMKey se encuentra dentro de la zona "Intranet Local", en la configuración de sitios de confianza

Si se usa Firefox, se puede activar poniendo en la barra de direcciones: about:config y en la nueva barra network.automatic-ntlm-auth.trusted-uris

10) Ya se puede entrar con SSO desde http://nombredominio/zope/kmkey

NOTA IMPORTANTE: Si se prueba desde fuera del dominio, al entrar el usuario y la clave manualmente, debe hacerse en el formato DOMINIO\usuario para que lo acepte

KMKey y el proceso de cuestionarios EFQM

2010-03-23T16:44:00.007+01:00

KMKey y EFQM

El modelo de medición de la gestión de la calidad denominado EFQM tiene un cierto predicamento entre aquellas empresas, normalmente de medio/gran tamaño que buscan obtener de su SGC datos más relevantes para la mejora contínua y el acercamiento al concepto de Calidad Total.

Este modelo, está basado en la Autoevaluación continuada, y el objetivo final de la empresa u organización que la adopta suele ser (después de varios años de implantación) el de presentarse al premio europeo de la excelencia EFQM. Tanto es así que uno de los "estadios" de su implantación se denomina: Enfoque de Simulación de Presentación al Premio.

Existen otros enfoques como son, los enfoques proforma (basado en formularios), el enfoque matricial (que suele observar uno de los elementos de la "ecuación" EFQM de forma aíslada), el enfoque por grupos de trabajo, el de implicación paritaria y finalmente el enfoque o metodología basada en cuestionarios.

Cada uno de los métodos conlleva diferentes grados de dificultad en su concepción/implantación y distintos tipos de información obtenida.
En este sentido el modelo se muestra bastante eficiente en la señalización de puntos débiles y fuertes así como de las oportunidades de mejora.

Se critica que sea un modelo demasiado verbal, con un campo semántico difuso, que necesite de una cantidad elevada de esfuerzos en la autoevaluación continuada y en la "tutorización" y auditoría externa continuada a la que se ve sometida la organización que la quiere adoptar.

Tanpoco hay que olvidar el "sesgo inducido" en la redacción de muchas preguntas que dejan al encuestado sin demasiadas opciones para expresar su opinión fuera de las propuestas, o ciertas contradicciones que surgen en algunos subcriterios entre Puntos Fuertes y Areas de mejora, y la tendencia a procesarlas juntas o a promediar y después ponderar datos complejos, o bien la de distinguir entre una serie de indicadores "homogeneizados" aquellos que son realmente sensibles para los intereses de la organización auditada.

No obstante, el grado de satisfacción de las organizaciones que adoptan este modelo es elevado en lo que respecta a:

la amplicación de sus conocimientos sobre el grado de satisfacción de los clientes de la organización,
la gestión y mejora de los procesos internos y de;
los resultados económicos.

Por ello cuando en EARCON nos propusieron adaptar KMKey para automatizar una gestión de cuestionarios EFQM para una organización, aceptamos el reto sin dudarlo. No es misión de Earcon juzgar el grado de bondad del modelo adoptado por las organizaciones a las que presta sus servicios.

La dificultad principal de esta organización, además de redactar y diseñar las 71 preguntas de las que constaba su cuestionario EFQM, radicaba en la distribución y recogida del mismo, al tener sus sedes distribuidas en un ámbito geográfico medio/grande, así como en la capacidad para gestionar el proceso de rellenado de los cuestionarios y su reenvio para no dejar apartados o preguntas incompletos o sin responder. Además se debía llevar un estadillo del progreso del rellenado y devolución (rellenados) de los mismos.

Así pues se debía disponer de una herramienta como KMKey para gestionar todo aquello relacionado con los envios y recogidas de cuestionarios a los usuarios.
Adaptamos un patrón de KMKey a fin de recoger las 71 preguntas, divididas en 9 sublayouts, en los que se debían disponer las opciones de respuesta (5 respuestas posibles: A,B,C,D, y E) de cada una de las preguntas, junto con la exposición de la respuesta, con un "radio button" cada una, para seleccionar la opción.

La cantidad de cuestionarios correctamente rellenados se pueden monitorizar a diario y al acabar los resultados se pueden "exportar" en una tabla (.csv) y a partir de aqui se pueden introducir en un programa de análisis estadístico ad-hoc.

O bien procesarlos en una hoja de cálculo de la que en Earcon también nos hicimos cargo, con intención de poder presentar no sólo la gestión de la "oleada" de cuestionarios (de hecho el cliente podría tener varías oleadas en curso en distintos puntos de la geografía y con distintos objetivos y para diferentes empresas cada una), sino para poder tabular y presentar en un Informe automatizado, los resultados de aquella "oleada", segundos después de haber recibido el último cuestionario correctamente rellenado.

Este es sólo un ejemplo de capacidad y versatilidad de KMKey para adaptarse a las necesidades de gestión de cada sistema de gestión de la calidad adoptado por nuestros clientes.

Implantación de KMKey subvencionada

2010-03-05T10:17:00.003+01:00

Es posible obtener ayudas de la administración para la implantación de una solución como KMKey. El MINISTERIO DE INDUSTRIA, COMERCIO Y TURISMO mediante su Programa de Apoyo a la Innovación de las Pequeñas y Medianas Empresas "InnoEmpresa" (2007-2013) permite obtener subvenciones a las PYME que quieran utilizar KMKey como herramienta para la mejora de procesos.
Para mas información:
http://www.ipyme.org/es-ES/SubvencionesAyudas/InnoEmpresa/Paginas/InnoEmpresaNuevo.aspx

Alcanzar objetivos con KMKey

2010-03-03T10:19:00.007+01:00

Al utilizar un programa de gestión de proyectos como KMKey Project pretendemos poder controlar el estado de los mismos para poder tomar decisiones que garanticen su rendimiento. Este objetivo global de acceder en cualquier momento a "la foto" del estado de los proyectos puede desgranarse en objetivos parciales, según las necesidades de cada empresa o la fase de implantación en la que nos encontremos.
En las implantaciones, presentamos al coordinador los diferentes niveles de control a los que KMKey Project puede llegar para delimitar cuales de ellos vamos a utilizar en la fase que nos ocupa.
Estos, agrupados por ejes, son los siguientes:
Los 4 EJES de KMKey:
Información: gestión de documentos, e-mails, notas y avisos.
I1: Organización de la información según estructura de proyecto
Tiempo: calendario de realización de las tareas. Fechas previstas y reales.
T1: Fechas prevista y reales. Comparativa
Esfuerzo: horas/hombre invertidas para llevarlas a cabo
E1: Horas previstas y reales. Comparativa
E2: Asignación y Reserva de recursos
Economía: ingresos, costes y rendimientos del proyecto
$1: Cuenta de explotación prevista y real
$2: Ciclo Oferta > Factura
$3: Gestión cobros y pagos.

Recuperar / Restaurar objetos borrados a partir de una copia de seguridad

2010-01-28T14:12:00.005+01:00

Plantearemos la situación de tener que recuperar un proyecto borrado accidentalmente a partir de una copia de seguridad. Se supone que no tenemos la opción de undo y que no se ha hecho ningún purge dspués del borrado

El caso aquí planteado supone que la BD Main está en postgresql , y los schemas pueden o no estar replicados a postgresql

IMPORTANTE : Esto funcionará solo en el caso que NO se haya ejecutado ningún purge del portal_repository, ya que se habrań perdido las referencias a los proxies (en realidad restauraremos proxies, no los objetos reales, ya que estos no se borran hasta el purge)

Pasos a realizar:

Primera parte : Recuperar la copia de seguridad completa

- Parar la instancia original (no es estrComunidad KMKey en Españolgenictamente necesario)
- Copiar toda la instancia a un nuevo directorio (cp -a zope zope2)
- Modificar los archivos de configuración de la nueva instancia para que apunten al nuevo directorio (editar todos los archivos de /bin, y modificar el path)
- Modificar el archivo zope/etc/zope.conf, modificando el path de la instancia, el puerto http y el origen de datos de la bd main. Si la original se llama, por ejemplo 'kmkey_zodb', aquí la podemos renombrar a 'kmkey_zodb_back'
- Crear la nueva base de datos : createdb kmkey_zodb_back
- Recuperar la copia de seguridad a la nueva bd que hemos creado : pg_restore -d kmkey_zodb_back archivo_copia_de_seguridad (se da por hecho que se estan realizando copias diarias o semanales de seguridad con el comando pg_dump --format=c nombre_bd>archivo_copia_de_seguridad)
- si además tenemos los schemas en posgresql, tb debemos recuperarlos , aunque este paso se puede omitir, ya que las 2 instancias apuntaran al mismo

Si hemos realizado correctamente todos los pasos anteriores, deberíamos poder arrancar la segunda instancia que hemos configurado (/usr/local/kmkey/zope2/bin/zopectl start)

Segunda parte : recuperar el objeto borrado

- Entramos a zmi de la segunda instancia y hacemos un export del expediente u objeto que queremos recuperar
- Copiamos el archivo .zexp que se ha exportado a /var de la segunda instancia al directorio /import de la primera instancia
- Paramos la segunda instancia (no es estrictamente necesario, pero esta instancia la deshecharemos para cualquier otra cosa que no sea recuperar objetos via export)
- Entramos a zmi de la primera instancia, y nos posicionamos en el contenedor del objeto que queremos recuperar
- Importamos el objeto

A partir de este momento , ya podremos acceder al objeto recuperado si todo ha funcionado correctamente, pero tenemos que asegurarnos de que desactivamos la marca de borrado de los schemas si estos estan en postgresql

Si es así, debemos ejecutar una consulta del estilo : update kmkey_project set deleted=0 where internal_docid = xxxxx (o proxy_path, o container_path, o project_path, para hacerlo para todos los subobjetos)
Tener en cuenta q si se está recuperando un expediente, habrá que ejecutar esta consulta para cada una de las tablas que tengamos a psql (kmkey_task, kmkey_work, kmkey_email, kmek_document, kmkey_note, etc..)

suerte

Gestión de Recursos. Pasado, presente y futuro

2010-01-26T11:45:00.002+01:00

Una de las funcionlidades avanzadas de KMKey es la gestión de cargas de recursos humanos, esto es, la posibilidad de asignar y reservar horas de trabajo de gente en proyectos y tareas concretas. Esta gestión se lleva a cabo en la pestaña “PLANIFICAR” , apartado “Recursos”. En ella podemos seleccionar el nivel de detalle de la vista a:

Semanas, con lo que podremos asignar horas día a día dentro de cada semana
Meses, con lo que podremos asignar horas semana a semana dentro de cada mes

Una vez seleccionado el nivel de detalle, podemos pasar a asignar recursos en un período (día o semana) y una tarea concretas. Para ello hacemos click en la cuadrícula correspondiente, y nos aparece un desplegable con los recursos humanos disponibles. Entre paréntesis nos aparece la carga ya existente de ese recurso en ese período, con lo que podemos ver fácilmente si tiene tiempo disponible para la tarea que pretendemos asignarle.

En la parte inferior podemos entrar la nueva asignación al recurso elegido. Las asignaciones pueden ser de varios tipos, y además esta clasificación va a variar en KMKey Zapata, de forma que pasaremos a detallarlas tanto en la versión Zapata como en la versión Makhno:

Asignación en el período lo antes posible. En Makhno correspondía a tener marcado “Lo antes posible” y NO tener marcado “Asignación Periódica”. Funciona asignado el número de horas que se le indique en el período seleccionado, teniendo en cuenta la carga de recursos. Por ejemplo, si una semana un recurso tiene ocupados lunes y martes, y se le asignan 8 hores lo antes posible, las asignará el miércoles. Cabe tener en cuenta que si el volumen de horas es alto, en este tipo de asignaciones el sistema asignará igualmente las horas en el período indicado, sobrecargando el recurso. Por ejemplo si en el caso anterior se asignan 40 horas en la semana, se asignarán de miércoles a domingo.
Asignación en el período repartida. En Makhno correspondía a tener marcado “Durante el período” y NO tener marcado “Asignación Periódica”. En este caso, se reparten las horas proporcionalmente durante todo el período. Por ejemplo, si se asignan 20 horas en una semana a un recurso, se le estan asignando 4 horas de lunes a viernes. Igual que en el caso anterior, si se sobrepasa la capacidad disponible, el sistema sobrecarga al recurso.
Asignación de larga duración. En Makhno correspondía a tener marcado “Lo antes posible” y tener también marcado “Asignación Periódica”. Esta opción sirve para entrar un volumen de horas que sobrepasa el período, con lo va a ir asignándose hasta completar el total de horas indicado, siempre teniendo en cuenta la disponibilidad del recurso en cada día. Por ejemplo, asignar 350 horas entre el 1 de enero y el 31 de marzo.
Asignación periódica diaria. En Makhno se correspondía a tener marcado “Durante el período” y tener también marcado “Asignación Periódica”. En ese caso se indica el número de horas diarias a reservar entre dos fechas, pudiendo seleccionar días de la semana. Por ejemplo, podemos reservar 2 horas diarias cada dia entre el 1 de enero y el 31 de diciembre, o 4 horas todos los viernes entre el 1 de enero y el 30 de junio.

Ruta hacia KMKey Zapata. Mas revolución!!

2010-01-19T10:41:00.009+01:00

Tras liberar KMKey Makhno y sin tiempo que perder, ya estamos planificando y ejecutando las nuevas mejoras y funcionalidades que contendrá la nueva versión. Está dedicada al revolucionario Mexicano Emiliano Zapata que acuñó el lema "Tierra y Libertad".
El éxito que está alcanzando el programa y sobretodo la variedad de casuísticas a las que responde, hace que recibamos continuamente sugerencias por parte de los usuarios. Tras analizarlas, junto con propuestas del equipo de desarrollo, concluímos que antes que extender las funcionalidades a otras áreas, el interés se centra en refinar todavía mas el uso de lo existente. Por tanto, hemos dividido los trabajos a realizar para la nueva versión en tres areas principales:

1)Usabilidad.
El objetivo es hacer mas ágil e intuitivo el trabajo diario con KMKey, mejorando funciones existentes y añadiendo nuevas funcionalidades. Una muestra de ello serían los siguientes desarrollos previstos:
Facilidad de uso y velocidad en árbol de expedientes. Desplegar / Plegar
Mejoras en filtros. Unificar. Recordar. Por defecto
Píldoras de información. Copiar y mover. Responder mails. Añadir múltiples documentos.
Búsquedas avanzadas.
Mejoras en mensajes y notificaciones. Enviar desde asignaciones.
Equipo: Heredar datos. Entrada desde expedientes. Sub layouts. Conexión con Google maps.
Unificar: calendarios y agendas. También gestión de versiones.

2)Gestión de proyectos
Siendo el uso para la Gestión de Proyectos el mas extendido, es lógico que sea en esta área donde mas interés y peticiones recibimos. Sobretodo para profundizar en su alcance. Los desarrollos previstos mas destacados son:
Eje tiempo: mejoras en estructurar WBS. Nuevas vistas: progreso, previsión. Calendarios de grupos de recursos e individuos
Eje esfuerzo: mejoras en la imputación de horas. Entrada rápida. Horas del dia visibles. Mejoras en asignaciones de horas: modificar, previsto/ real..
Eje economía:
Cada vez mas usuarios utilizan la parte económica para la gestión de sus cuentas de explotación, ciclo oferta factura etc.. Sin pretender en ningún momento sustituir una contabilidad, mejoramos una serie de aspectos para que gran parte de la gestión se pueda llevar sobre KMKey. ejemplos de ello son:
Imputar conceptos según periodo de la tarea, organización en árbol de conceptos contables, generación de la curva S. Mejoras varias en facturación: justificaciones, repetitiva, enlace con productos, orden en filas etc..

3)Administración
Para facilitar el trabajo al administrador de la aplicación ponemos en marcha dos mejoras espectaculares: creación de un patrón desde un expediente y generación automática de los permisos (visibilidad de acciones) según la modalidad (Project, Quality o Help Desk) y el objetivo dentro de Project. De esta manera, solo con seleccionar como queremos trabajar se hará visible a los usuarios aquello que necesitan, quedando ocultas (pero disponibles) otras funcionalidades que por el momento no se van a utilizar.

Con esta serie de mejoras, el próximo Mayo, estará disponible KMKey Zapata para revolucionar mas si cabe el mundo de las aplicaciones empresariales en código abierto.
"Software y Libertad!!!"

Vocabularios / Select Box dinámicos

2010-01-18T13:23:00.002+01:00

Para configurar un select Box que depende de las entradas de otro select box tenemos accesible una funcion javascript , loadSelectValues

Ejemplo : Tenemos el campo-select box 'area' y un segundo campo-select box, 'proceso' , con opciones que dependen de lo que se haya seleccionado previamente en el campo 'Area'

Para configurarlo

- Creamos los 2 campos normalmente desde la edición de patrones
- Una vez creados, vamos al zmi (portal_layouts/layout_en_cuestion)

Campo area:
- Lo único que modificamos es la prpiedad "On change javascript action" , y escribimos lo siguiente : loadSelectValues(this.value, 'getProcesosPorArea', 'widget__proceso')

donde getProcesosPorArea es el nombre de un python script que crearemos debajo de portal_skins/custom, i 'widget__proceso' es el nombre del widget del cual depende. Así de simple

el contenido del script es el siguiente:

voc = container.portal_vocabularies['kmkey_nc_proveedores_proceso']
result = []
for key in voc.keys():
if key.split('#')[0] == str(id):
result.append({'key':key, 'value':voc[key]})
return result

Donde modificamos únicamente el nombre del vocabulario, el del campo dependiente, que obtenemos mirando la configuración de su widget asociado

Importante : En el campo 'Parameter list' del script debe indicarse 'id', para que acepte el valor como entrada

Lo único que nos queda, es configurar correctamente los valores de cada uno de los vocabularios.

Para vocabulario Area :
A1 --> Area 1
A2 --> Area 2
etc..

Para vocabulario Fuente
A1#1 --> Area 1.1
A1#2 --> Area 1.2
...
A2#1 --> Area 2.1

....

Como véis, la técnica se basa en utilizar el prefijo que hay antes del separador de campos '#'

Enlazar/Relacionar expedientes (relaciones n-->1 y m-->n)

2010-01-08T12:53:00.004+01:00

A veces nos interesa que un campo de un expediente nos permita seleccionar items que lo relacionen con otros expedientes

Por ejemplo, tenemos expedientes para introducir temas de personal, y tenemos otros expedientes donde introducimos las formaciones del personal. Aquí nos interesa tener una relación MN , donde un empleado puede estar en muchas formaciones y una formación tiene n empleados

Esta relación puede ser unilateral o simétrica (seleccionar en un sentido o en ambos)

A modo de ejemplo, pongamos q tenemos los patrones con portal_type 'kmkey_personal' y 'kmkey_formacion'

1- Agregar un campo "CPS String List" a los dos schemas afectados. Al campo lo llamaremos 'PER_r_FOR'. El campo debe agregarse y llamarse exactamente igual en los dos schemas.
La única propiedad que debe configurarse es la "Write: expression", y solo en el schema donde vayamos a hacer la selección (si es simétrica, lo haremos en ambos).

campo a agregar en el schema 'kmkey_formacion':

python:object and proxy and util.catalogCrossSetList('kmkey_personal','PER_r_FOR', PER_r_FOR,proxy.getDocid(),'getDocid') or PER_r_FOR

si quisieramos permitir que desde un expediente de personal se puedieran seleccionar n formaciones, haríamos lo mismo en kmkey_personal, utilizando esta expresión :

python:object and proxy and util.catalogCrossSetList('kmkey_formacion','PER_r_FOR', PER_r_FOR,proxy.getDocid(),'getDocid') or PER_r_FOR

fijarse bien en el uso del campo en los parámetros de la función : el segundo parámetro se pasa el nombre del campo (string) y el tercer parámetro es el propio valor del campo, sin comillas

2- Agregar el índice y metadata del campo creado (keyword index) al portal_catalog.

3- Agregar el widget con el nombre igual al nombre del campo al (los) layout correspondiente. Ha de ser un "KMKey Multi select pop up Widget"
Parámetros del widget:
- size : valor 1 --> permite únicamente seleccionar un elemento.
Si ponemos size 2 o más, podremos seleccionar n elementos (es o uno o n)
- vocabulary : kmkey_selected_units
- URL to pop up template : para permitir un solo elemento : 'selectUnitSimple.html', para permitir n elementos : 'selectUnits.html'
- Filter Meta Type (or Portal Type) : dejaremos en blanco para todo, o indicaremos una lista de portal types separados por comas, en el ejemplo, añadiremos el widget en el layout de kmkey_formacion, y en este campo pondremos 'kmkey_personal'.
- Token for view list : podemos indicar un token html para separar los diferentes valores seleccionados en el modo view del expediente, se puede utilizar por ejemplo la coma (,) o un <> para seaparlos con un salto de línea

Si vamos ahora a crear un expediente del tipo kmkey_formacion, veremos que nos aparece el campo y los botones que nos permite abrir el pop-up que visualiza la lista de expedientes de personal, donde relizaremos la selección

Activar módulos en KMKey

2010-01-07T10:58:00.001+01:00

KMKey Tiene 4 módulos diferenciados

- Información
- Temporal
- Esfuerzo
- Economía

Cada uno de ellos cons sus funcionalidades (Información general, planificación, imputación de horas y gestión económica -facturas de compra,venta, previsiones-)

Para activar y desactivar módulos vamos a la pestaña Admin --> Módulos, allí tenemos las opciones

Configurar Seleccionable / Autocomplete de Grupos / Empresas o Contactos

2009-12-28T12:59:00.004+01:00

Para configurar un campo relación asociado a una selección de grupos o empresas (o contactos), realizamos los siguientes pasos:

Para configurar una lista seleccionable (un select box)

- Agregar un Widget al layout : "KMKey Relation Select Widget"

- en el campo AdvancedQuery Expression (TALES) , utilizamos una expresión python que utlizará AdvancedQuery para ejecutar la consulta. Un ejemplo de filtro típico es filtrar los grupos de determinada categoría :
python:Eq('meta_type', 'KM Group')&In('categories',['customer','provider','lo que sea'])

o contactos

python:Eq('meta_type', 'KM Contact')

- Value to Show (TALES from the brain) : Aquí ponemos la expresión que se encarga de mostrar el valor :
python:brain.Title

Ya tenemos configurado nuestro seleccionable de empresas (o contactos)

En el caso de que haya muchos registros , no es conveniente, por motivos de rendimiento y de usabilidad, utilizar un seleccionable. Para ello podemos utilizar un autocomplete , con el mismo control, de la siguiente manera :

Para configurar un autocomplete:

- Realizamos exactamente los mismos pasos que antes
- Creamos , dentro de zmi/portal_skins/custom/ un python script. Lo llamaremos , por ejemplo "autocomplete_for_arquitectos"
- Establecemos el campo "Parameter list" a "value"
- El código del script deberá ser más o menos como el siguiente :

from Products.AdvancedQuery import MatchGlob, Eq, Le, Ge, In, Between, Generic

REQUEST = context.REQUEST
value = "*" + unicode(value, 'utf-8').encode('iso-8859-15') + "*"
catalog = context.portal_catalog

query = MatchGlob('Title', value) & Eq('meta_type', 'KM Group') & In('categories', 'Arquitecto')
brains = catalog.evalAdvancedQuery(query, ('Title' , ) )
result = ['< id="%s">%s< / li >' % (b.getDocid, b.Title) for b in brains]
result = ' <> ' + chr(10).join(result) + '< / ul >'
result = unicode(result, 'iso-8859-15')

REQUEST.RESPONSE.setHeader('Content-Type', 'text/xml;;charset=%s' % 'utf-8')
return result

- Finalmente, otra vez en el widget, establecemos el campo "Server method for autocompletation" con el nombre del script que hemos configurado antes (autocomplete_for_arquitecto, en el ejemplo)

Una vez hecho esto, en la pantalla de alta o edición, podemos establecer el campo utilizando la técnica del auto completado, escribiremos parte del nombre de la empresa a buscar, y la lista mostrará los elementos que coincidan, debiendo seleccionar uno de ellos

En caso de no aparecer ningún valor, revisar el script o mirar el error_log para localizar posibles errores

en el directorio de skins de KMKeyDefault, ya tenemos varios scipts por defecto que filtran grupos o contactos :

- auto_complete_for_contacts
- auto_complete_for_customers
- auto_complete_for_providers
- auto_complete_for_groups
- auto_complete_for_users_or_groups

Lo mismo que hemos hecho para grupos lo podemos hacer también para usuarios u otros objetos, simplemente cambiando las condiciones del query

Configurar qué se muestra en el navtree (título de los expedientes)

2009-12-23T11:46:00.005+01:00

Para personalizar qué información se visualiza en el navtree, simplemente tenemos que configurar, en cada schema asociado a cada patrón, un campo llamado 'navtree_title'

- Entramos a ZMI/schemas/schema_en_cuestion
- Añadir un campo string llamado 'navtree_title'
- Escribir la expresión que necesitemos en el campo 'Write : expresion', al estilo :

python: object and "%s - %s - %s" % (object.reference, object.title, object.planned_start.strftime(...)) or ''

o más complejo :

python:object and "SM.%s.%s"%(relacionados and len(relacionados)>=1 and util.relatedObjectAttribute(relacionados[0],'reference') or 'Sin Relación',serie) + ' - ' + object.title

Importante : Si utilizamos la read expression, esto se calcula cada vez, afectando al rendimiento, por eso lo usamos en la write expression, que solo se calcula cada vez que se guarda el objecto. El problema de esto segundo, es que si hacemos el cambio a posteriori (con expedientes ya creados) , hay que ejecutar un commit de cada objeto para que se actualice todo correctamente
Esto también es importante si tenemos los schemas en postgresql, ya que las read expresions NO se graban en las tablas

para ejecutar el commit tenemos la solución fácil por un lado, si hay pocos expedientes, que es editarlo uno por uno y guardarlo desde la propia aplicación

si hay muchos expedientes, no queda más remedio que ejecutar un zopectl debug y escribir esto (o crear un archivo de texto y ejecutarlo via zopectl run)

site = app.mi_site_de_km
site._p_jar.cacheGC()
site._p_jar.sync()
from AccessControl.SecurityManagement import newSecurityManager
from Testing.makerequest import makerequest
user = site.acl_users.getUser('un_usuarioa_dmin').__of__(site.acl_users)
newSecurityManager({}, user)
app = makerequest(app)
site = app.mi_site_de_km
from Products.CPSCore.EventServiceTool import getPublicEventService
from Products.AdvancedQuery import Eq,In
cat = site.portal_catalog
km = site.workspaces.kmkey
site._p_jar.cacheGC()
site._p_jar.sync()
brains = cat.evalAdvancedQuery(Eq('portal_type',el_portal_type_que_sea))

obs=[]
i=0
for brain in brains:
i=i+1
obs.append(brain.getObject())
if i%25==0:
site._p_jar.cacheGC()
site._p_jar.sync()

i=0
for proxy in obs:
ob = proxy.getContent()
dm = ob.getDataModel()
dm._commit()
proxy.reindexObject()
evtool = getPublicEventService(proxy)
evtool.notifyEvent('modify_object', proxy, {})
i=i+1
if i%5==0:
get_transaction().commit()
km._p_jar.cacheGC()
km._p_jar.sync()

Cómo seguir la evolución de KMKey ?

2009-12-14T12:04:00.003+01:00

Varias personas nos han manifestado su interés en seguir la evolución de KMKey, pero tienen dudas acerca de cómo hacerlo. Vamos a intentar aclararlo en esta entrada. Disponemos de 2 herramientas para la comunidad de KMKey en español:

1) El blog http://kmkey-es.blogspot.com en el que te encuentras. En él publicamos trucos de configuración, detalles técnicos del desarrollo, o no tan técnicos, instrucciones para la instalación, etc. Puedes hacerte seguidor del blog pulsando en el bóton "Seguir", pero necesitarás disponer de una cuenta google, yahoo o twitter para hacerte seguidor del mismo. En todo caso, te animamos que lo visites con cierta frecuencia y entres tus comentarios a nuestras entradas si lo crees oportuno

2) La lista de correo KMKey Spanish Es el método más dinámico y participativo, donde vamos explicando con más frecuencia los avances, e incluso debatimos funcionalidades a implementar. Una lista de correo es un sistema en el que la gente se suscribe con una cuenta de e-mail. Una vez suscrita, puede enviar e-mails a la lista escribiendo un mail con destinatario kmkey-spanish@lists.forge.osor.eu Asimismo, todas las personas suscritas reciben todos los emails que se envían a la lista. Es una buena forma de llegar rápidamente a todos los interesados en un tema, en este caso KMKey, y que lleva años usándose en el mundo del software libre (colaborativo por definición). Si a alguien le molesta recibir demasiados e-mails, puede elegir en las preferencias la opción "Digest", de forma que sólo recibiría un resumen periódico. Para suscribirte tienes que entrar tu e-mail y elegir un password, y recibirás un correo de confirmación con las instrucciones para finalizar la inscripción. Te esperamos !!

Liberado KMKey 3 versión Makhno

2009-12-03T09:33:00.006+01:00

Nos complace anunciar la liberación de KMKey Makhno, incluido dentro de la plataforma OSOR. Se puede obtener más información del producto y como descargarlo en la página comunitaria

Para quien no lo conozca, KMKey (Knowledge Management Key) es un software libre, con licencia GPL v2, que implementa gestión de proyectos y de calidad en un entorno web. Se encuentra desarrollado en lenguaje Python sobre el servidor de aplicaciones Zope y el gestor de contenidos CPS, y su principal utilidad es ofrecer una plataforma que cruza la planificación de proyectos con la gestión de contenidos y un cuadro de mando, convirtiéndolo en un entorno colaborativo tremendamente útil para cualquier empresa de servicios. Como valor añadido, el producto tiene una larga trayectoria empresarial y se encuentra en producción en multitud de empresas y organizaciones reales

En esta nueva versión se ha mejorado considerablemente la usabilidad, el rendimiento, y las utilidades disponibles pera el administrador. También se ha añadido la exportación e importación de patrones de trabajo con el fin de fomentar el intercambio de los mismos entre usuarios, y se han añadido nuevas vistas en el cuadro de mando. Esperamos que todo ello os resulte de la máxima utilidad

Los funciones que has sido objeto de revisión son:

DEFINICIÓN : Mayores capacidades de diseño de formularios con los “sublayouts”, ayudas y cabeceras
EQUIPO : Mejoras en la presentación de los grupos y contacto rediseño de la pagina de gestión de permisos
GESTIÓN: Mejoras en el cierre de proyecto
PLANIFICACIÓN: Mejoras en la edición de la planificacion
CONTROL: Mejoras con nuevas funciones en la presentación del Esfuerzo, presentación en % y en Gantt, comparativa Previsto/Real

Quieres colaborar con KMKey ?

2009-12-03T09:16:00.003+01:00

Necesitamos colaboradores para mejorar, difundir y documentar KMKey. Si te apetece pasar a formar parte de la comunidad KMKey en español seguro que puedes aportar tu granito de arena. Los principales perfiles, aunque no los únicos, que necesitamos son:

1) Administradores avanzados que ayuden a documentar las muchísimas opciones de configuración del sistema

2) Release managers, o personas encargadas de preparar y difundir las liberaciones de KMKey que se van llevando a cabo

3) Programadores python con ganas de aprender zope y de añadir nuevas funcionalidades a KMKey. Tenemos una lista de ideas interminable, pero faltan manos para implementarlas todas

4) Empaquetadores Debian o RedHad. También necesitamos gente capaz de generar un paquete .deb o .rpm para que KMKey pueda ser incluido como paquete disponible en las principales distribuciones de GNU/Linux

Es una buena oportunidad para aprender a implantar KMKey's, aprender a programar en zope o simplemente colaborar a difundir software libre. Si estás interesado envíanos un correo a la lista de correo KMKey Spanish

Como instalarse KMKey Makhno

2009-12-03T09:04:00.005+01:00

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 de momento

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=EP9DOO7Y

2) Descargar los fuentes de OSOR 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://svn.forge.osor.eu/svn/kmkey/bundles/kmkey-stable" Los requisitos son los mismos que en el punto 2

Espero que lo disfruteis

Notas sobre problemas de red en la máquina virtual

La máquina virtual puede presentar algunos problemas de red si la versión de VirtualBox es antigua y no soporta "Bridge" en el interfaz de red. Usad una versión de VirtualBox más moderna y configurad la interefaz de red de tipo "Bridge" para que funcione

También nos han notificado algun problema con el adaptador de red en Debian. Por lo visto al crear una máquina virtual nueva y adjuntar el disco, el MAC address de la targeta de red cambia, y eso a veces no le gusta a Debian que recuerda las MAC address a través de su sistema UDEV. La solución es sencilla, entrar en la máquina virtual y ejecutar

rm /etc/udev/rules.d/70-persistent-net.rules

Después de eso reiniciad la máquina virtual y ya aparecerá el interfaz eth0

Si tienes dudas o comentarios usa por favor la lista de correo KMKey Spanish Gracias

Cómo distinguir el Software del Humo

2009-11-12T07:31:00.000+01:00

Puede parecer una chorrada, pero el hecho es que cada vez estoy más convencido de la necesidad de crear un algoritmo capaz de determinar la cantidad de humo existente en un proyecto software. De hecho, si lo pensamos bien, el software y el humo son ambos elementos inmateriales que, vistos desde la distancia, pueden resultar muy difíciles de distinguir. Así que me he puesto manos a la obra.

Como ingeniero informático, soy perfectamente capaz de escribir un análisis de datos técnicos que nadie entienda, pero como aquí el objetivo es divisar el humo, le voy a dar a la fórmula un enfoque más mundano, para que la entiendan incluso los gerentes. Ahí va la definición de factores:

Factor A: ¿ Existe una web del producto, donde se describan claramente sus funcionalidades ?
Puntúa de 0 a 10, donde 0 = no hay web, y 10 = la web existe y es cojonuda

Factor B: ¿ La web contiene capturas de pantalla donde puedas hacerte una idea rápida ?
Puntúa de 0 a 10, donde 0 = no hay capturas, y 10 = las hay y molan

Factor C: ¿ Puedes conseguir fácilmente una demo del producto ?
Puntúa de 0 a 10, donde 0 = no hay demo que valga, y 10 = la hay y es fácil obtenerla

Factor D: ¿ La demo es completa, con todas las funcionalidades, o es una versión capada donde no puedes hacer casi nada ?
Puntúa de 0 a 10, donde 0 = te he dicho que no hay demo, y 10 = la hay y puedes hacer de todo en ella

Factor E: ¿ Te han enviado un tío con corbata y americana para convencerte ?
Puntúa de 0 a 10, donde 0 = el tío era un pijo pedante que sólo soltaba siglas que no entendías, y 10 = era un tío competente que sabía lo que hablaba

Factor F: ¿ Cómo se financió el desarrollo del producto ?
0 = Pillaron una subvención (eso huele a humo más que una hoguera)
5 = Con aportaciones externas de capital
10 = Con recursos propios

Factor G: ¿ Existen referencias contrastables de implantaciones exitosas ?
0 = Ni rastro de eso
5 = Hay algunas
10 = Con la gente que lo ha comprado, tiene que ser la ostia

Factor H: Pide un presupuesto de implantación, que incluya despliegue y formación para ti y/o tus técnicos. ¿ Cuanto te quieren clavar ?
0 = Más de 50.000 euros (el producto no existe y te lo quieren hacer a medida)
10 = Menos de 3000 euros (el producto existe y te van a cobrar los servicios)

Porcentaje de Humo = 100 – (A + B + C + D + E + F + G*2 + H*2)

Como consumidor te recomiendo que apliques la fórmula a rajatabla cada vez que te plantees implantar un software, no vaya a ser que estés comprando humo :-)

Copyleft: Eres libre de distribuir y reproducir el contenido de este artículo, total o parcialmente, por el medio que quieras, faltaría más.

Guía de Instalación de KMKey

2009-11-04T12:35:00.020+01:00

Ya hemos explicado anteriormente cómo instalarse KMKey de forma rápida, pero vamos a explicar también como hacerlo paso a paso, de forma detallada.

En primer lugar necesitamos un sistema GNU/Linux base, a ser posible Debian stable, aunque en Ubuntu funcionaremos sin inconveniente. Si somos de Windows, entonces lo primero es bajarse una versión nuevecita de la VirtualBox e instalarla. Después nos descargaremos el CD 1 o Netinst de Debian, lo conectaremos al CDROM de la máquina física o virtual, y procederemos a instalar el sistema básico. No son necesarios entornos gráficos ni paquetes adicionales, a posteriori instalaremos los imprescindibles.

En cuanto al hardware, las recomendaciones para un servidor de producción de buen rendimiento son 2 GB de RAM, 2 o 3 procesadores de velocidad >= 3 GHz y discos de buena calidad (a ser posible en RAID y de 15.000 rpm). Aunque obviamente se puede funcionar con menos, eso es lo recomendable para un KMKey que se vaya a usar con cierta intensidad.

Una vez tenemos nuestro Linux, entramos con usuario root y empezamos. Las instrucciones indicadas en esta guia son válidas para Debian Lenny, aunque pueden servir de ejemplo para la instalación en otras distribuciones:

1) Verificar que en /etc/apt/sources.list disponemos de acceso a los repositorios "main", "contrib" y "non-free". Por ejemplo:

deb http://ftp.us.debian.org/debian/ lenny main contrib non-free

2) Instalación de paquetes

apt-get update
apt-get -y install make gcc libc6 libc6-dev gettext apache2 subversion python2.4 python2.4-dev python2.4-egenix-mxdatetime xlhtml ppthtml xsltproc wv catdoc poppler-utils python-lxml patch lynx icewm-lite xserver-xorg xfonts-75dpi xfonts-100dpi xbase-clients exim4 tightvncserver xfonts-base sudo less ytnef gs-common msttcorefonts ntpdate

3) Creamos usuario zope

adduser zope

4) Instalamos Zope 2.9.4

wget -c http://www.zope.org/Products/Zope/2.9.4/Zope-2.9.4-final.tgz
tar -zxf Zope-2.9.4-final.tgz
cd Zope-2.9.4-final
vi configure y cambiar ACCEPTABLE="2.4.1 2.4.2" por ACCEPTABLE="2.4.1 2.4.2 2.4.3 2.4.4 24.5 2.4.6"
./configure --prefix=/usr/local/zope294
make
make install
chown -R zope.zope /usr/local/zope294
ln -s /usr/local/zope294 /usr/local/zope

5) Creamos la instancia zope para KMKey

mkdir /usr/local/kmkey
chown -R zope.zope /usr/local/kmkey
su zope
cd /usr/local/zope
bin/mkzopeinstance.py -d /usr/local/kmkey/zope -u admin:tupassword

6) Si queremos usar RelStorage, esto es, ZODB implementado sobre una BBDD postgresql, procedemos a su instalación. ATENCIÓN, este paso es opcional, y algunas de las instrucciones que se indican pueden NO ser recomendadas en servidores compartidos con otros servicios.

apt-get install patch python-psycopg2 postgresql-client-8.3 postgresql-8.3
/etc/init.d/postgresql-8.3 stop
mv /var/lib/postgresql/8.3 /var/zope/postgresql_8.3
ln -s /var/zope/postgresql_8.3 /var/lib/postgresql/8.3
chown postgres.postgres /var/lib/postgresql/8.3
dpkg-reconfigure locales (añadir es_ES@euro si no está)

su postgres
cd /var/lib/postgresql/8.3
mv main main_old
/usr/lib/postgresql/8.3/bin/initdb /var/lib/postgresql/8.3/main/ --locale=es_ES@euro --lc-ctype=es_ES@euro
cp main_old/postmaster.opts main/
/usr/lib/postgresql/8.3/bin/pg_resetxlog main
cp main_old/*crt main
cp main_old/*key main
exit

/etc/init.d/postgresql-8.3 start
cd
wget http://pypi.python.org/packages/source/R/RelStorage/RelStorage-1.1.3.tar.gz
tar xzf RelStorage-1.1.3.tar.gz
cd RelStorage-1.1.3
export PYTHONPATH="/usr/local/zope/lib/python/"
python2.4 setup.py install --install-lib=/usr/local/zope/lib/python
cd /usr/local/zope/lib/python/ZODB
patch < $HOME/RelStorage-1.1.3/poll-invalidation-1-zodb-3-7-1.patch su postgres psql -c "CREATE USER zope WITH password 'tupassword' createdb" template1 exit su zope createdb kmkey_zodb

Editamos /usr/local/kmkey/zope/etc/zope.conf y cambiamos el zodb_db main por este otro:

%import relstorage
<zodb_db>
mount-point /
cache-size 15000
<relstorage>
<postgresql>
dsn dbname='kmkey_zodb' user='zope' host='localhost' password='tupassword'
</postgresql>
</relstorage>
</zodb_db>

7) Añadir productos KMKey a Zope

su zope
cd /usr/local/kmkey
mkdir source
cd source
echo "Please accept our certificate"
svn co https://svn.forge.osor.eu/svn/kmkey/bundles/kmkey-stable
ln -s kmkey-stable current
cd current
python2.4 KMKeyCore/utils/generate_mo_files.py
cp ZOORRA/zoorra-config.xml.default ZOORRA/zoorra-config.xml
cp ZOORRA/server/zoorrad-config.xml.default ZOORRA/server/zoorrad-config.xml
cd /usr/local/kmkey/zope/Products
ln -s ../../source/current/* .
exit

cd /usr/local/kmkey/zope/Products/TextIndexNG3/extension_modules
python2.4 setup.py install

8) Creamos un script de arranque y reiniciamos Zope

cat > /etc/init.d/kmkey <<EOF
#!/bin/bash
su -c "/usr/local/kmkey/zope/bin/zopectl \$@" zope
EOF
chmod a+x /etc/init.d/kmkey
update-rc.d kmkey defaults 90 10
/etc/init.d/kmkey restart

9) Si queremos tener apache delante, entonces lo configuramos

cd /etc/apache2/mods-enabled
ln -s ../mods-available/proxy_balancer.load .
ln -s ../mods-available/proxy.conf .
ln -s ../mods-available/proxy.load .
ln -s ../mods-available/proxy_http.load .
ln -s ../mods-available/deflate.* .

cat > /etc/apache2/sites-available/kmkey <<EOF
ServerAdmin tu@tudominio.com
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/access.log combined
<proxy balancer://lb>
BalancerMember http://127.0.0.1:8080
ProxySet lbmethod=byrequests
ProxySet stickysession=STICKY_ROUTE
Order allow,deny
Allow from all
</proxy>

ProxyRequests Off
ProxyVia On
<LocationMatch "^[^/]">
Deny from all
</LocationMatch>

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
RewriteEngine On
RewriteRule ^/(.*) balancer://lb/VirtualHostBase/http//%{HTTP_HOST}:80/kmkey/VirtualHostRoot/\$1 [L,P]
EOF

cd /etc/apache2/sites-enabled
rm 000-default
ln -s ../sites-available/kmkey 000-default

10) Finalmente, si queremos poder obtener listados en formatos MS-Office o PDF, necesitaremos configurar OpenOffice y ZOORRA:

apt-get install python-uno openoffice.org-writer openoffice.org-calc
ln -s /usr/local/kmkey/zope/Products/ZOORRA/server /usr/local/zoorra
cd /usr/local/zoorra
Ajustar /usr/local/zoorra/zoorrad-config.xml
ln -s /usr/local/zoorra/zoorrad.sh /etc/init.d
update-rc.d zoorrad.sh defaults 95
/etc/init.d/zoorrad.sh start
su zope
cd /usr/local/kmkey/zope/Products/ZOORRA
cat > zoorra-config.xml
<oood-config><openoffice_python_path value="/usr/bin/python2.5"><python_uno_path value=""><pdf_conversion_method value="ps2pdf"><connection_string value="socket,host=localhost,port=2002"><conversion_timeout value="120">
exit
/etc/init.d/kmkey restart

Y esto es todo amigos, a disfrutar de vuestro KMKey, y no os olvideis de activar unas copias de seguridad de datos

La seguridad en KMKey Makhno

2009-10-16T17:00:00.009+02:00

Hemos puesto especial empeño en hacer hacer de KMKey Makhno un producto con el máximo de garantías en cuanto a seguridad. Para ello hemos llevado a cabo diversas mejoras, que junto con las ya existentes en versiones anteriores y las propias de la plataforma Zope, ofrecen el máximo de protección frente a posibles intrusiones. Pasamos a detallar a continuación el funcionamiento de los distintos componentes implicados:

1) Seguridad de los datos. Para garantizar que cada objeto es visible únicamente para aquellos usuarios que dispongan de los permisos pertinentes, KMKey confía en la probada robustez de Zope (el servidor de aplicaciones) y su immejorable sistema de permisos y control de accesos sobre ZODB, que permiten granular al máximo la definición de los accesos.

1.1) Errores de programación. Zope verifica que cada acceso a cada objeto esté siendo llevado a cabo por un usuario con permisos, y eso lo hace de forma independiente al código de la aplicación, de manera que un eventual error de programación se traduce en una alerta de seguridad y una negación de acceso, nunca en un acceso a datos restringidos.

1.2) Inyecciones SQL. Puesto que la base de datos usada es ZODB (orientada a objetos, aunque a la postre todos los datos acaben guardados en SQL si así se configura), todo el código de la aplicación está libre de ataques por inyección de SQL, que son uno de los mayores peligros en aplicaciones web clásicas

2) Seguridad en la autentificación. Uno de los puntos vulnerables de cualquier aplicación web o cliente/servidor es aquel en que el usuario se autentifica, es decir, proporciona su usuario y su password, y éste viaja a través de la red. Este proceso es susceptible de ser interceptado por terceros (por ejemplo mediante el uso de sniffers), cosa que les permitiría conocer el usuario y la clave. En este sentido, KMKey proporciona dos niveles de seguridad:

2.1) Conexión no encriptada, autentificación mediante MD5. Para los casos en los que el servidor web no disponga de un certificado de seguridad que permita conexiones seguras HTTPS (posibilidad sólo disponible para servidores dedicados, y de elevado coste si el certificado se firma por una autoridad certificadora), KMKey evita enviar la clave plana a través de la web. En lugar de eso, la propia página de entrada encripta el password con el algoritmo unidireccional MD5. Ello implica que aunque esta clave encriptada fuera interceptada, sería imposible obtener la clave original (puesto que MD5 es un algoritmo de hash, de una sola dirección). Dado que las claves también son almacenadas encriptadas mediante el mismo algoritmo, ello da la posibilidad de autentifcar al usuario de una forma mucho más segura y asegura que ningún "robo" de datos acabará con la obtención de las claves de usuario.

2.2) Conexión encriptada con certificado de servidor. En caso de que el servidor KMKey sea dedicado, existe la posibilidad de instalar un certificado de servidor que permita conexiones seguras HTTPS. En este supuesto, la autentificación se lleva a cabo sobre un canal seguro, y es virtualmente imposible interceptar los datos con los medios actuales. Como inconvenientes a esta opción está la alerta de seguridad que la mayoría de navegadores dan si el certificado de seguridad no se encuentra firmado por una autoridad certificadora, y el elevado coste de obtener esta firma.

3) Seguridad de la sesión. Una vez el usuario ha sido autentificado, para mantener la sesión mientras se usa la aplicación, KMKey utiliza una cookie de sesión. Sabiendo que este sistema puede también ser vulnerable a ataques mediante sniffers, se ha implementado un modelos de sesiones que ofrezca las máximas garantías. Para ello se utiliza una cookie de sesión totalmente aleatoria, imposible de calcular, se hace caducar la sesión a los 20 minutos de inutilización, y se verifica en cada petición que la IP de origen coincide con la del usuario que ha abierto la sesión. De esta forma, aunque una cookie de una sesión en curso fuera "robada", el atacante sería rechazado por la verificación de IP's de origen. La única alternativa más segura que este sistema es el uso de certificados de cliente, pero son usados en muy pocas ocasiones por su complejidad de desplegado (generación de certificados para cada usuario e instalación en todos sus puestos de trabajo).

4) Seguridad de las comunicaciones. Todos los datos que circulan a través de internet sin una conexión segura HTTPS de las descritas anteriormete son susceptibles de ser interceptados y leídos por personas expertas en tráfico de redes. Por ello, si los datos contenidos en KMKey son de elevada confidencialidad, es recomendable el uso de alguna de las siguientes opciones:

4.1) Certificado de seguridad en servidor y conexión HTTPS requerida. Como se ha expuesto anteriormente, es una opción con algunos inconvenientes y reservada para servidores dedicados

4.2) VPN (Virtual Private Network). De forma que la conexión al servidor se realice siempre sobre canales de comunicación seguros, en este caso a más bajo nivel que el certicado HTTPS. A efectos prácticos, requiere que los usuarios se autentifiquen primeramente en la VPN y, una vez conectados a ésta, puedan acceder al servidor KMKey

4.3) Firewall de restricción de IP's. Una opción con menos garantías que las anteriores, pero de implementación mucho más sencilla, es restringir el acceso al servidor a determinados rangos de IP's (para ello debemos conocer previamente los rangos de IP's que pueden tener nuestros usuarios potenciales). Eso consigue evitar accesos de fuera de nuestras oficinas, por ejemplo, aunque también redunda en una limitación de la movilidad de los usuarios.

4.4) Acceso LAN. La opción más restrictiva consiste en limitar el acceso al servidor sólo a los usuarios de la red local, de forma que garantizamos que cualquier acceso proviene del interior de nuestras dependencias

5) Seguridad en el software base. Todo lo anterior puede no servir de nada si nuestro sofware de base, léase el sistema operativo o el servidor de aplicaciones, tiene errores graves de seguridad que permitan un acceso directo al servidor. Por ello recomendamos siempre instalar KMKey sobre servidores GNU/Linux con distribución Debian versión stable, usando apache 2 como servidor web y un firewall como iptables. Con una correcta configuración, son una muy buena protección contra ataques de intrusos.

Consejos prácticos: La seguridad es algo a tener muy en cuenta en la implementación de cualquier herramienta web, y tanto los servidores web como las aplicaciones deben ofrecer las máximas garantías. Ahora bien, debemos tener muy presente que el 90% de los ataques se realizan siempre sobre PC's de escritorio, que suelen ser infinitamente más vulnerables, y una vez conseguido el control del PC local, se actúa contra servidores que lo consideren "de confianza", o incluso se pueden encontrar documentos de usuarios y claves de acceso, o datos confidenciales en los escritorios de trabajo. Por ello, una buena política de cambio de passwords, o una correcta supervisión de los puestos de trabajo pueden ser tanto o más importantes que la seguridad del servidor.

ZOORRA sin servidor gráfico

2009-10-02T20:27:00.009+02:00

La actual implementación de ZOORRA requiere que en el servidor haya alguna sesión gráfica abierta. Esta restricción viene dada por OpenOffice, que aunque permitía un modo silencioso para ejecutar macros aún requería un entorno gráfico que a veces usaba para mostrar errores.

Una solución habitual para resolver este problema era la instalación de un servidor gráfico "falso", algo así como redireccionar la salida gráfica a /dev/null. Esa solución, práctica porque no requiere la instalación de un entorno gráfico en un servidor que no lo necesita, también tiene el inconveniente que un error en la ejecución de OpenOffice resulta en una pantalla gráfica esperando una confirmación que jamás podrá recibir y sin atender a las posteriores peticiones.

Las versiones más recientes de OpenOffice finalmente han ofrecido una solución definitiva a este problema largamente reivindicado, el modo "headless". En este modo de ejecución la aplicación ya no genera ningún mensaja gráfico y así deja de exigir la conexión a un servidor X.

En Debian esta funcionalidad viene dada por el paquete openoffice.org-headless que por defecto no se instala con la suite ofimática, así que lo instalaremos explícitamente:

# apt-get install openoffice.org-headless

Una vez instalado deberíamos probar que efectivamente funciona correctamente sin ningún servidor X en ejecución. Los gestores de escritorio de KDE y Gnome dan la posibilidad de dar "acceso de consola" en la pantalla de inicio de sesión, dentro de un menú. Una vez nos encontremos con la consola de texto a pantalla completa, iniciamos una sesión normalmente y ejecutamos las siguientes órdenes:

$ openoffice -headless
$ ps x | grep headless

Si todo va bien, deberíamos ver el proceso aún en ejecución. En este estado, la ejecución de OpenOffice resulta inaccesible porque no hemos especificado aún ningún puerto de conexión (de eso ya se ocupará ZOORRA), así que lo terminaremos con la orden kill y el número de proceso que aparece a la izquierda:

(salida hipotética de la orden ps)
12345 tty1 Sl 0:00 /usr/lib/openoffice/program/...
67890 tty1 S+ 0:00 grep headless
$ kill 12345

Si no lo hacemos, las siguientes ejecuciones a OpenOffice parecerá que no harán nada porque, si ya existe una instancia en ejecución, la aplicación intenta aprovechar la misma. Esto también es importante para el usuario que ejecute ZOORRA, ya que no podrá usar OpenOffice en modo visual, así que es recomendable usar el mismo usuario del sistema con el que se ejecute el servidor Zope.

Finalmente, para que la instalación actual de ZOORRA se aproveche del modo headless de OpenOffice habrá que modificar el fichero /usr/local/zoorra/zoorra.py. Hay que ir con algo de cuidado pues es un fichero algo largo. En él buscaremos la cadena "-invisible" y la cambiaremos por "-headless" respetando las comillas.

En futuras versiones incluiremos como opción de configuración de ZOORRA la posibilidad de ejecución en modo "headless", de modo que no sea necesario modificar el fichero .py en ningún caso.

Avanzando hacia KMKey Makhno

2009-10-02T10:00:00.004+02:00

Seguimos avanzando a buen ritmo hacia la próxima versión de KMKey, que se llamará Makhno, y que tiene prevista su liberación en noviembre. Recordamos la lista de objetivos que propusimos:

1) Gestión de Equipo. Es sin duda la funcionalidad menos trabajada, por lo que va a ser la primera en abordarse. Además, en lo referente a permisos, requiere simplificación de la configuración de los usos más comunes

1.1) La asignación de perfiles a usuarios no puede ser más engorrosa, hay que rehacerla completamente, y de paso incorporar la asignación de perfiles a grupos enteros

1.2) Se deben poder asignar fácilmente a un expediente contactos ya existentes en la aplicación, independientemente de que se tengan o no permisos de gestión del equipo

1.3) En la vista de grupos relacionados sería conveniente poder desplegar, en árbol, los contactos asociados a cada grupo

1.4) En la vista de consulta de grupos se necesitas nuevos criterios de filtro, en especial uno por el tipo de grupo (de permisos, cliente, proveedor, etc)

1.5) En la vista de consulta de contactos también se requieren nuevos criterios de filtro, en especial uno por su condición de usuario / recurso / simple contacto

1.6) La definición de perfiles a usar, perfiles a bloquear en expedientes, perfiles a bloquear en el acceso al patrón, etc, debe ajustarse al tipo de patrón (de proyecto, de píldora, de contacto etc)
de forma que se simplifique especialmente el caso de definición de la seguridad en patrones de proyectos

1.7) Las recomendaciones de configuración de permisos de http://kmkey-es.blogspot.com/2009/05/configuracion-basica-de-permisos.html se han mostrado especialmente útiles cuando existen varios departamentos o líneas de negocio disjuntos. Deberíamos ajustar las configuraciones por defecto del programa para permitir realizarlas fácilmente desde la interfície del propio KMKey (ahora requieren uso del ZMI)

2) Usabilidad. Hacer más fácil ciertos usos del programa, en especial es vital la agilidad para filtrar lo que deseamos ver

2.1) Mejorar definición de filtros. Es muy engorroso definir nuevos filtros y usarlos.

2.2) Filtro por defecto y último filtro. Recordar para cada usuario el último filtro usado, y poder definir en cada instalación qué filtro se quiere aplicar por defecto

2.3) Filtros rápidos. El objetivo es que introduciendo una palabra en el propio navtree, sin necesidad de cambiar de pantalla, obtengamos un filtro de expedientes rápido

3) Nuevas vistas para los datos ya existentes.

3.1) En Control Gantt Real versus Gantt Previsto

3.2) En Control comparación entre esfuerzo real y horas planificadas

3.3) En Planificación / Recursos tener una vista con los recursos en el eje Y para visualizar más facilmente su ocupación detallada

3.4) Pantalla de tres ejes para economia, con las tareas en eje Y, el calendario en el eje X, y el total económico en el cruce, y pudiendo ver el detalle haciendo click en cada punto

4) Cerrar el ciclo. Se trata de vincular de alguna forma la información de los ejes. O sea, que la planificación temporal se vincule con la planificación de esfuerzo, y ésta a su vez con la
planificación económica en horas valoradas. Estas vinculaciones deben ser opcionales, y en todo caso dejar a criterio de configuración / usuario la propagación de cambios

Además de todo eso, va a haber importantes mejoras de rendimiento, sobretodo en lo que a grabación de datos se refiere, y alguna que otra mejora de usabilidad adicional. También vamos a liberar la versión adaptada a KMKey del ZSQLCatalog, que permite usar un catálogo basado en postgresql, y que es muy recomendable para instalaciones con gran volumen de datos.

Pepararse, que llega la revolución de KMKey Makhno (quede claro que no es un coñac)

Previsiones económicas. Ciclo Oferta/Presupuesto >> Factura

2009-09-30T18:54:00.004+02:00

Con KMKey podemos llevar a cabo ofertas/presupuestos y así mismo emitir y registrar las facturas que se necesiten.
Para ello debemos utilizar las prestaciones que se encuentran en el TAB "PLANIFICAR" opción "Añadir Previsión" y generar una nueva.
Debemos tener seleccionado el nombre del proyecto en el árbol de navegación.
Seleccionar el TAB PLANIFICAR y a continuación seleccionar la opción: "Añadir Previsión".
Se identifica esta "Previsión" con un nombre y se deben rellenar algunos campos más.
A continuación podemos ir rellenando "item" por "item" los conceptos de los que consta dicha "oferta".
Para poder imputar correctamente los "items" deberá haber una correspondencia con los "Conceptos Contables" definidos en la aplicación.
Una vez rellenada la última línia de elementos, guardamos la previsión.
Nos aparecen una serie de botones con opciones como: "Modificar", para modificar cualquier entrada o dato recogido; "Copiar", para dejar esta previsión como estaba e ir añadiendo elementos en la copia, y más concretamente nos fijamos en el botón: "Generar Doc."
Elegimos esta opción.
Para que funcione correctamente se debe haber vinculado previamente al patrón deseado una "plantilla" de este documento, que formalmente será una "oferta" o un "presupuesto".
Nombramos el documento, elegimos la plantilla y generamos el documento.

Una vez generado este documento (Oferta/Presupuesto) será muy sencillo enviarlo al cliente mediante correo electrónico, opción, "Añadir e-mail".

En caso que el cliente acepte este presupuesto/oferta debemos indicarlo a KMKey.
Para ello seleccionamos el proyecto en el árbol de navegación.
Volvemos a seleccionar el TAB "PLANIFICAR" y su opción "Previsiones", seleccionamos la previsión que nos sirvió para emitir el "Presupuesto/Oferta" y seleccionamos el botón: "Generar Factura".
Seleccionamos la tarea donde queremos almacenar la acción.
KMKey automáticamente realiza la imputación de una "pill" del tipo "Venta/Ingreso" en dicha tarea.

Seleccionamos esta "pill" y observamos la opción "Emitir Factura".
Una vez seleccionada, KMKey nos deja elegir la fecha de emisión de la misma, restringiendo la posibilidad de emitir una factura con fecha "anterior" a la última realizada.
Seleccionamos la Fecha y se genera la Factura. Observaremos el botón "Generar Doc."
Seleccionamos dicha opción y debemos elegir un nombre para la misma, así como la plantilla de "Factura" asociada al patrón.
La factura correlativa, correctamente numerada y valorada queda incorporada a nuestro proyecto.

Ejemplos del ciclo Previsión >> Oferta/Presupuesto >> Factura.
Ver video:

Posibilidades multiempresa de KMKey

2009-09-28T12:18:00.000+02:00

En KMKey la unidad de trabajo es el proyecto (o expediente). En cada proyecto se definen los participantes con sus perfiles correspondientes, determinando qué pueden o no hacer en cada uno de ellos. A partir de ahí, cada usuario ve únicamente aquellos proyectos en que ha sido asignado. Además de eso, existe una información común, visible por defecto a todos los usuarios, que es la agenda de contactos y grupos / empresas, con los datos de contacto, teléfonos, e-mails, etc. Finalmente, existen los datos visibles únicamente a los administradores, como la configuración de patrones de trabajo.

A partir de ahí, ¿ qué posibilidades existen para la implantación de KMKey en un grupo empresarial, donde existe un grupo raiz que se comunica con distintas empresas ? Bien, existen 3 enfoques posibles, cada uno con sus ventajas e inconvenientes:

KMKey básico. Se trata simplemente de aceptar el funcionamiento básico descrito anteriormente.

Ventajas: No tiene coste adicional.

Inconvenientes: Las distintas empresas del grupo comparten su información de contactos, y los administradores lo son de todo el sistema, tanto a nivel de usuarios y permisos como de patrones de trabajo, no hay posibilidad de tener un administrador para cada empresa.
Control de grupos por permisos. Se basa en configurar el acceso a los contactos y empresas de forma que cada empresa vea únicamente sus contactos. Se puede llegar a conseguir que los usuarios del grupo vean los contactos de todas las empresas si así se desea.

Ventajas: Permite segmentar la agenda de contactos sin necesidad de programación.

Inconvenientes: Requiere una configuración de permisos laboriosa, y no resuelve el problema de los administradores descrito en el punto anterior.
KMKey jerárquico. Consiste en estructurar el KMKey en un árbol de contenedores, de forma que los usuarios del grupo estén un nivel por encima de los usuarios de cada una de las empresas

Ventajas: La agenda de contactos queda segmentada sin necesidad de configuración. Puede haber administradores por empresa, que puedan dar de alta usuarios y ajustar patrones de trabajo sólo en su empresa. Así mismo, puede haber administradores del grupo que tengan acceso a administrar todo el conjunto.

Inconvenientes: Requiere un desarrollo específico para ajustar el funcionamiento estandard

Permisos de acceso a opciones de menú

2009-09-18T09:47:00.002+02:00

Con cierta frecuencia se da el caso de que los permisos predefinidos para acceder a una opción de menú de KMKey no se ajusten a las necesidades del cliente. Por ejemplo, la opción de gestionar previsiones económicas está protegida por el mismo permiso que la opción de editar la planificación de un proyecto, porque en la mayoría de casos la misma persona planifica el proyecto y define su previsión económica. Pero cuando esto no sea así, también temenos la opción de cambiarlo mediante configuración.

Para ello debemos entrar en el ZMI de nuestro site (url/manage), ir a el objeto portal_actions, y buscar la opción de menú que deseamos cambiar. Siguiendo el ejemplo anterior, sería la que se llama "Economics Plan". Imaginemos que queremos restringir está opción a directores comerciales, dirección, financieros y responsables de área. Tendríamos que editar al "Condition Expression" y añadir una expresión que nos diga si el usuario actual tiene alguno de esos perfiles en el contexto en el que estamos. Eso se puede expresar de la siguiente forma:

and member.getUser() and len([role for role in member.getUser().getRolesInContext(unit) if role in ['dir-comercial', 'direccion', 'financiero', 'resp-area']])

O sea, el usuario está autentificado, y alguno de sus perfiles en el contexto actual coincide con los permitidos.

Finalmente, y no por ello menos importante, debemos marcar la opción de "Block import ?", cosa que nos garantiza que nuestra expresión personalizada no será substituida por futuras actualizaciones del programa.

Demos KMKey disponibles. Condiciones de uso

2009-09-01T09:57:00.006+02:00

Demos generales para probar funcionamiento y usabilidad
Earcon SL pone a disposición de quien lo desee acceso al software de KMKey en sus tres modalidades (Project, Quality y Help desk) con el fin de poder simular su uso y conocer la herramienta.
Para ello se proporciona un url (dirección web) y algunos usuarios con funcionalidades limitadas. La demo contiene algunos ejemplos con los que trabajar y la posibilidad de generar expedientes nuevos, introducir y consultar información etc..
Estas demos están siendo utilizadas por varios usuarios al mismo tiempo. La información introducida puede ser alterada por otro usuario o podemos encotrar temas no introducidos por nosotros. A pesar de que una misma instalación de KMKey puede contener las tres funcionalidades (Project, Quality y Help desk) se proveen "url's" de demo diferentes para facilitar la comprensión de los procesos relativos a cada caso.
Este tipo de demos tienen el siguiente aspecto:

http://project.kmkey.com/empresa/
http://quality.kmkey.com/empresa/
http://helpdesk.kmkey.com/empresa/

Donde "Empresa" se sustituye por un nombre único cuando se facilita la demo

Demos de uso exclusivo:
Una vez comprobado el uso mediante una demo general, el usuario interesado puede solicitar una demo para uso exclusivo. Aunque el contenido es el mismo que en el caso anterior, se restringe el acceso solamente a la persona que lo solicita. En este caso toda la información contenida solo es vista, introducida o revisada por el interesado al que se concede la demo. También se dan privilegios de administrador para que pueda acceder a la parte de configuración.
Este tipo de demos tienen el siguiente aspecto:

http://demoX.kmkey.com/empresa/
Donde X es un número del 1 al 5 dependiendo del servidor donde sea alojada y "Empresa" se sustituye por un nombre único cuando se le facilita la demo

Condiciones de uso:
-El objetivo de las demos es que el solicitante pueda probar KMKey simulando casos reales de uso. En ningún momento está pensado para llevar casos reales.
-Toda la información que se introduzca no tienen ninguna garantía de confidencialidad o de salvaguarda y será limpiada periódicamente. Deben utilizarse ejemplos ficticios.
-El periodo de uso de la demostración es de un máximo de 30 dias. Podrá ser ampliado en caso de petición expresa.
-KMKey no se hace responsable de los datos introducidos, ya que se supone que son irrelevantes.

Recursos y Esfuerzo. Planificación, Gestión y Control.

2009-08-26T19:00:00.007+02:00

Planificación

En KMKey, la cantidad de esfuerzo prevista para una tarea se puede dejar fijada en la programación del patrón con el que se ejecute el proyecto.
La instrucción "Planned hours" en el código XML del patrón, es uno de los elementos que pueden programarse para cada tarea del proyecto. De esta manera ya no es necesario tener que realizar esa previsión antes de cada proyecto y la cantidad de esfuerzo previsto queda fijada para cada tarea del proyecto.

Es decir, antes de iniciarse los trabajos de la tarea, puede existir una "previsión" del esfuerzo que será necesario para llevarla a cabo. Una vez creado el proyecto, siempre que necesitemos modificar dicha cantidad de esfuerzo, lo podremos realizar mediante el TAB PLANIFICAR > Editar Planificación, o bien, seleccionar la tarea y en el mismo TAB usar la opción "Modificar".

Una vez iniciada la tarea, esas horas de esfuerzo previsto se deberían distribuir para los recursos y duración empleadas en su desarrollo. Este procedimiento consiste en "asignar" partes de ese esfuerzo previsto (horas) a uno o varios recursos, hasta completar el total de horas previstas en el patrón para dicha tarea. En KMKey, está operación se efectua a través del TAB PLANIFICAR > Recursos

La asignación de recursos se puede efectuar para:

día a día,
para todos los días de una semana,
o bien, de forma periódica, para un determinado período de tiempo.

En cada tarea, la suma de las horas de esfuerzo asignadas a uno o varios recursos deberían ser la misma que las horas totales previstas y, a partir de ahi, registrar las desviaciones respecto a las imputaciones que realice cada recurso personalmente.

Gestión

Una vez efectuadas las asignaciones de esfuerzo, los distintos recursos deberán realizar las imputaciones de horas dedicadas al desarrollo de cada tarea, a medida que estas se vayan produciendo.

Este procedimiento se lleva a cabo mediante el TAB GESTIÓN > AÑADIR HORAS y con él, cada recurso puede imputar a una tarea en concreto el esfuerzo desempeñado.
KMKey permite realizar imputaciones de esfuerzo, incluso en aquellas tareas, en las que por cualquier motivo, no se hayan efectuado "asignaciones" en concreto.

Es decir, es posible que un recurso que haya empleado cierta cantidad de esfuerzo en el desarrollo de una tarea, pueda realizar una imputación de esfuerzo a la misma, aunque no exista una asignación en concreto.

Control

KMKey proporciona distintas visualizaciones en el TAB CONTROL especificamente diseñadas para tener a la vista los datos de esfuerzo, y poder discriminarlos por recurso, período, tarea y proyecto o grupo de los mismos.

El uso de los filtros de proyecto (navtree) y de las opciones de visualización propias a cada opción permitirá la supervisión del esfuerzo empleado y el registro de las desviaciones, positivas o negativas, sobre la planificación inicial efectuada.

Distintas visualizaciones como son ESFUERZO, ECONOMÍA y SEMÁFOROS, permitirán obtener informaciones pormenorizadas sobre la distribución del esfuerzo y sus desviaciones.
Así mismo, en el TAB CONTROL, encontramos la opción de "Informes".

En este apartado encontraremos aquellos informes generables que el usuario de KMKey haya querido definir para obtener resúmenes y listados con todo tipo de detalles sobre la actividad desarrollada en cada tipo de proyecto o conjunto de los mismos.

Ejemplos de Planificación y Asignación de Esfuerzo a Recursos.
Ver video:

Vínculos e Imágenes

2009-07-27T18:44:00.009+02:00

INSERTAR VINCULOS

En KMKey siempre que introducimos un documento o una nota, nos aparece una barra de controles de edición, situada en la parte inferior del campo “Descripción”.

Para Insertar un Vínculo, seleccionaremos, escribiremos , o copiaremos el texto que queramos hacer de él un vínculo. A continuación seleccionamos el icono :

Y nos aparece una pantalla como la siguiente:

TIPO DE VÍNCULO

El tipo de vínculo puede ser una URL, una referencia a la misma página o un e-mail. Estas dos ultimas opciones no se utilizan al tener KMKey utilidades propias para esos servicios.

Así mismo podríamos elegir el protocolo entre: http, https, ftp, news, u otros...

DESTINO

En la pestaña “Destino” podemos elegir si queremos que nos abra el vínculo en una ventana nueva y sus parámetros:

Podremos seleccionar: Ventana emergente, Nueva ventana, Ventana Primaria, Misma Ventana, Ventana Padre, etc...

INSERTAR IMÁGENES

Para insertar una imagen en un documento o nota en primer lugar tendremos que “subir” la foto como un “documento” (Añadir Documento) y situarla en la tarea que deseamos. Podemos tener una tarea que sean: Fotos.

Una vez subida la foto, la seleccionamos y copiamos el “camino” o descriptor que aparece en la linea del navegador. Lo pegamos en el bloc de notas. A continuación seleccionamos el icono :

Nos aparecerá la siguiente pantalla:

En el campo URL, pegamos el “camino” o descriptor de ruta de la imagen que habíamos subido.

Podemos hacer que la foto se acomode a unas medidas o fijar otras.

Si queremos hacer de la imagen un vínculo seleccionamos la pestaña “Vinculo” y nos aparece la siguiente pantalla de datos:

Rellenamos el campo URL, con la misma que ya teníamos y seleccionamos el tipo de destino que queremos (Ventana nueva, emergente, etc..).

Software libre. GNU/Linux. La filosofía detrás de KMKey

2009-07-24T12:00:00.004+02:00

KMKey como gestor del conocimiento tiene una dilatada historia. Su primera versión estuvo concebida a finales de los 90 del siglo pasado siguiendo los cauces habituales por la época del software privativo. Es decir, no se entregaban las fuentes al cliente, se cuotaba por usuarios, el desarrollo no estaba abierto a terceros etc..
En resumen, lo habitual en la época y la manera "tradicional" de entender el negocio TIC.
Hace mas de seis años nos planteamos como empresa la posibilidad de dar un cambio radical en las reglas de juego y trabajar con software libre. El cambio, no solo era debido a las herramientas que utilizamos para desarrollar KMKey, sino a una nueva filosofía en la manera de entender el negocio, el trabajo y por ende la vida misma.
Antes de decidirnos, bebimos en las fuentes de esta filosofía y tras hacer nuestros sus objetivos y valores las aplicamos en cada una de las areas del proyecto KMKey.
Para aquellos que quieran profundizar en estas fuentes, que mejor que hacerlo bebiendo directamente de ellas:

GNU Project:
http://www.gnu.org/
Conferencia de Richard Stallman en el IES Puig i Castellar:
Ver video:
La pastilla roja: libro de referencia en el software libre en hispania.
http://www.lapastillaroja.net/

Añadir Contactos y Usuarios. Organización en grupos.

2009-07-23T18:40:00.004+02:00

CONTACTOS
En KMKey podremos mantener la gestión de nuestros contactos mediante el uso de la opción:

TAB EQUIPO > Añadir Contacto.

Los datos que se recogen en ese momento pueden definirse y/o adaptarse a las necesidades de cada organización y uso de KMKey.
En general incluirán de los campos más habituales para su definición. Como son:
Nombre y apellidos, sus direcciones y datos más habituales de contacto, teléfonos, direcciones e-mail, y otras.

GRUPOS
Análogamente a la definición de contactos, en KMKey podremos definir cuantos grupos se necesiten para diferenciarlas de otros mediante el uso de la opción:

TAB EQUIPO > Añadir Grupo.

En la definición de estos grupos podremos incluir:

Clientes,
Proveedores.
Departamentos.
Empresas (en los casos de uso en grupos multiempresa)
Colaboradores Externos.
Auditores.
Jefes de Departamento.
Comités.
Grupos de trabajo, etc.

Así como tambien algunos grupos especiales como los grupos de recursos o de permisos, propios de KMKey.

Por supuesto para la definición de cada uno de esos grupos el usuario podrá escoger los campos que necesite según la actividad de cada uno. Una vez creados se tratará ir nutriendo de integrantes (contactos o usuarios) en su composición.

USUARIOS
En la misma pantalla de definición de datos de contacto, a partir de un punto de la misma empiezan lo que son propiamente la definición de datos de usuario.

Básicamente un contacto se convertirá en un usuario desde el momento en el que el administrador del sistema le otorgue un "nombre de usuario", un "password" y unos permisos mínimos.

Así pues podremos tener contactos que no son usuarios, pero todos los usuarios deberán ser contactos.

Una vez que damos de alta a un contaco como usuario deberemos rellenar (si así lo disponemos) otros datos que se corresponden a su posible asignación como recurso o no.

Estos datos especiales pueden incluir, entre otros:

Coste económico por hora (Vinculado a los conceptos contables definidos).
Firmas propias personalizadas de e-mail.
Tipo de notificaciones que recibirá de KMKey (Internas, e-mail, SMS).
Idioma del Interface de KMKey (Disponible Castellano, Catalán, Inglés y Euskera)
Su pertenencia o no a grupos y/o a grupos de permisos ya definidos.
Su rol básico (Miembro, Manager)

Una vez definido como usuario también podremos realizar asignaciones de roles o perfiles personalizadas a un proyecto o expediente concreto, en función de los patrones en uso.

O asignar grupos enteros a expedientes en concreto, facilitando así la labor de su gestión de accesos y permisos, mediante el uso de la opción:

TAB EQUIPO > Gestionar Contactos o Gestionar Grupos.

Hay que señalar que el alcance de los permisos y perfiles puede abarcar desde:

el acceso general a la aplicación,
el acceso a patrones y expedientes generados con el mismo en concreto, o
el acceso a expedientes, agrupaciones o tareas de un proyecto o expediente en particular.

Gestión de Nombres de Contactos/Usuarios y uso del campo: Iniciales.

2009-07-23T12:49:00.006+02:00

Cuando damos de alta un contacto que a su vez se convertirá en un usuario (nombre de usuario + password), rellenamos los campos pertenecientes a su nombre y apellidos.

Si este usuario a su vez es susceptible de incorporarse a un grupo de recursos, podemos tener algunos problemas de visualización en aquellos casos donde hayamos definido al contacto con su nombre y apellidos completos.

Ejemplos como José Ramon, en el campo "nombre"; y Gonzalez de la Fresneda en el campo "apellido", provocará que en algunas representaciones o en algunas columnas de ciertas pantallas en KMKey, su nombre aparezca incompleto, o truncado, produciendo un cierto desorden en la información mostrada.

Para evitar largas descripciones en las listas de recursos y en otras visualizaciones podemos rellenar a nuestra voluntad, el campo INICIALES, en la pantalla de datos del contacto.
TAB EQUIPO > Añadir o Gestionar Contactos

En iniciales podemos incorporar "estrictamente" las inciales, en el ejemplo: JRGdF, pero cuando las listas de recursos sólo muestran acrónimos o sólo iniciales, se convierten en algo dificil de recordar y de aplicar correctamente.

Sin embargo nada nos impide introducir un corto descriptor del mismo usuario como José Ramon, o JR Gonzalez, o Ramón Gonzalez o J. Fresneda (quizás le conocen más por el 2º apellido), etc.

Alta de expedientes y filtros.

2009-07-22T19:06:00.003+02:00

Alta de expedientes/proyectos y uso de filtros de proyecto

Para dar de alta un nuevo expediente o proyecto en KMKey es tan sencillo como elegir el patrón de la lista que se muestra al inicio de la aplicación.

La cantidad de patrones a los que tiene acceso cada usuario puede variar en función de los permisos que se le hayan concedido.

Una vez seleccionado aparecerá una pantalla de recogida de datos estructurada en tantos campos como el usuario necesite para "Definir" ese proyecto o expediente de los otros que ya gestiona.

Algunos de los campos (también seleccionados por el usuario) tendrán caracter de obligatorios y deberán rellenarse, con algún carácter o con una máscara y formato determinados.

Existe la posibilidad de editar o modificar a posteriori algunos de esos datos si no se conocen en el momento de rellenarlos, mediante el uso de la acción "Modificar" del TAB Definición.

Si no se indica otro inicio, KMKey tomará como fecha de inicio la fecha y hora actuales del sistema.

A partir de esa fecha y en función de la duración de las tareas que lo componen ya programadas o definidas en el patrón, se obtendrá la fecha prevista de final del proyecto.

En algunos casos (patrones) se podría programar los calculos de duracion de las tareas de forma inversa. Es decir, fijando una fecha de final prevista como objetivo, con independencia de la fecha de inicio y KMKey se encargaría del resto.

Cuando se termina de rellenar todos los campos pulsamos la tecla "Intro" o sobre el botón "Siguiente" y el nuevo proyecto o expediente aparece en la lista del "navtree".

Algunos de los patrones, ya sea por su complejidad, o por su adecuación al paso del tiempo, no puede incorporar toda la información que necesita para la "Definición" del proyecto en el momento de su creación.

Normalmente eso se suele solucionar disponiendo de diferentes pantallas (o "sublayouts") de recogida de datos que se adaptarán a las necesidades del usuario y al desarrollo en el tiempo de la actividad/proyecto/expediente, etc...

FILTROS DE PROYECTO
Es importante utilizar los filtros de Proyecto para tener a la vista sólo aquellos con los que queremos trabajar. En caso necesario podríamos crear filtros para ver un sólo proyecto a la vez.

En principio existirán tantos filtros ya dispuestos como patrones hayan.

En la edición de filtros existe todo un apartado para la selección de tareas, por lo que es conveniente tener filtros preparados (cada usuario gestiona los suyos) para situaciones como:

(Mostrar) Las tareas "activas" en las que el usuario es responsable, de todos los proyectos del tipo "OFERTA" o cualquier otros de los existentes.

Estos filtros se pueden ajustar tanto como se quiera, incorporando selectores de fechas y la posibilidad de incluir o exluir las de cierto rango.

Con ello se consigue tener una pantalla ordenada, y la información coherentemente accesible.

Configuración avanzada de índices postgresql

2009-07-22T09:10:00.004+02:00

Cuando creamos una tabla en postgresql es habitual crear índices por los campos que creemos van a usarse más para búsquedas. Normalmente, lo hacemos con un simple:

CREATE INDEX nombre_indice ON tabla(campo);

Bien, eso puede bastar en ciertos casos, pero si campo es un tipo texto y queremos hacer búsquedas usando LIKE, nos encontramos con sorpresas:

EXPLAIN ANALYZE SELECT * FROM tabla WHERE campo LIKE '%valor%';

Nos dirá que está ejecutando un SCAN de toda la tabla ! Nuestro índice no se está usando para búsquedas tipo LIKE. Para que lo use, necesitamos crear el índice de forma ligeramente distinta:

CREATE INDEX nombre_indice ON tabla(campo text_pattern_ops); (si campo es tipo TEXT)
CREATE INDEX nombre_indice ON tabla(campo varchar_pattern_ops); (si campo es tipo VARCHAR)

Si repetimos el EXPLAIN ANALYZE veremos que ahora SI se usa el índice

Otro caso típico que nos encontramos es con la normalización de los datos. O sea, como trabajar acentos, eñes, mínusculas y mayúsculas para que el usuario encuentre lo que busca, para que una búsqueda 'proyect' encuentre cosas como 'Caja PROYECTOR', 'Proyectó 1' o 'Proyecté una peli'.

Para ello se pueden guardar los datos tal como vienen, y crear un índice normalizado, usando una función PL/PGSQL de tipo inmutable. Por ejemplo:

CREATE OR REPLACE FUNCTION str_normalize (value TEXT) RETURNS text AS $$
BEGIN
RETURN lower(translate(value, 'áàéèíìóòúùäëïöüÁÀÉÈÍÌÓÒÚÙÄËÏÖÜñÑçÇ"?¿¡[]`{},:;=&%$#|!\ºª<>', 'aaeeiioouuaeiouAAEEIIOOUUAEIOUnNcC '));
END;
$$ LANGUAGE plpgsql;

CREATE INDEX nombre_indice ON tabla(str_normalize(campo) text_pattern_ops);

Ahora podemos comprobar que podemos hacer búsquedas normalizadas de lo más optimizado:

EXPLAIN ANALYZE SELECT * FROM tabla WHERE str_normalize(campo) LIKE str_normalize('%valor%');

Pequeña ayudita para informes y listados

2009-07-03T09:57:00.002+02:00

con esta dirección : http://My_KMKey/..../workspaces/kmkey/dump_fields_of_pattern?type_name=kmkey_accion-correctiva

donde type_name es el nombre del portal_type asociado a un patrón, se os volcarà un archivo csv con la tabla de todos los campos del patrón, donde se indica el sublayout, la etiqueta y el nombre del campo con su correspondiente para hacer el output en el informe, de este estilo :

"Analisis ";"Analisis de Causas (breves descripción de estas)";""
"Analisis ";"Fecha Prevista de Implantación";""
"Analisis ";"Implementada por:";""
"Descripcion";"Coordinada Por";""
"Descripcion";"Detectada Por";""
"Descripcion";"Gestión";""

abriendo el csv con calc (o excel en su defecto...) podréis hacer fàcilmente un copy&paste de la etiqueta y el campo para realizar informes

el skin se puede customizar y mejorar (por ejemplo, detectar el tipo de campo y utilizar el tag adecuadao (date, float, etc...), pero de momento nos facilita mucho el tener todos los campos disponibles

Estructura de información de soporte para KMKey. Help. Manual.

2009-07-02T19:23:00.002+02:00

Tras un debate interno, mas complejo de lo que pudiera parecer, hemos decidido dar la siguiente forma a las herramientas de soporte ( lo que vendria a substituir al tradicional Manual)

-Pàgina de índice con los temas de formación. En cada apartado, subapartado etc.. los links (permalinks) necesarios para ampliar. Estos links dirigen a lugares donde está la información desarrollada en diferentes formatos (principalmente videos, entradas de blog y documentos).

-Pagina de videos en www.kmkey.com. Se procederá a remodelar la estructura y ordenar los videos

-Entradas en el blog: http://kmkey-es.blogspot.com/ ya hay algunos disponibles. Los usuarios interesados se pueden hacer seguidores y recibir información de novedades. También se pueden formular preguntas e insertar comentarios.

-Lista de correo. Enfocada principalmente a temas técnicos y de desarrollo.
Kmkey-spanish@lists.forge.osor.eu

De esta forma creemos que la dispersión de la información que hay en la actualidad quedará solventada. Dispondremos de dos maneras principales de acceder:
-Busquedas en google.com del tópico. Por ejemplo: como indexar campo en KMKey que te lleva directamente a la entrada del blog
-Consultar el indice y buscar el tópico que nos interesa.

Como indexar un campo

2009-06-22T13:34:00.004+02:00

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.

Encodings al editar usando ZMI

2009-06-22T10:45:00.002+02:00

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

Configuración opciones KMKey

2009-06-17T11:53:00.002+02:00

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

Documentos en el sistema de ficheros

2009-06-17T09:48:00.003+02:00

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.

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

2009-06-11T18:45:00.003+02:00

Plantillas Generables asociadas a un patrón

2009-06-10T13:33:00.008+02:00

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

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

2009-06-09T17:31:00.005+02:00

"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".

Usando OpenOffice para hacer listados (I)

2009-06-09T11:54:00.012+02:00

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.

Activando el sistema de e-mails

2009-06-09T10:50:00.004+02:00

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

Liberado KMKey 3 versión "Durruti"

2009-06-03T17:55:00.003+02:00

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 ?

Como Instalarse KMKey Durruti

2009-06-03T14:13:00.011+02:00

Pasar schemas a SQL

2009-05-28T17:01:00.004+02:00

Como sabrán los administradores más avanzados, todos los datos de KMKey se estructuran en types, que se componen de schemas de campos para su definición + layouts de widgets para su representación (se puede ver todo eso entrando en el Zope Management Interface, o ZMI, entrando en http://url_site/manage)

El hecho de tener ZODB por debajo nos va de maravilla para tener esa flexibilidad de datos que caracteriza a KMKey, pudiendo definir patrones de trabajo con sus campos, etc. Pero en ocasiones, una vez un patrón está definido, configurado y en funcionamiento, tener los datos en SQL nos iría mejor para su explotación. Bien, pues también tenemos solución para eso: se pueden configurar los schemas para que graben sus datos en postgresql

Para ello se tiene que instalar el producto ZPsycopgDA en Zope. En Debian lo más fácil es hacer un "apt-get install python-psycopg && apt-get source python-psycopg", y cogerse el directorio ZPsycopgDA que habrá dentro del fuente, así cuadran las versiones. Una vez puesto esto en el Products de nuestro zope y reiniciado éste, se crea una conexión Psycopg a la BBDD en el site, llamémosla 'db'.

Luego te vas a un portal_schemas, por ejemplo kmkey_work, pestaña "SQL", le indicas el nombre de la conexión 'db', y le das al botoncillo que dice "Migrate To SQL". Ya tienes tus imputaciones de horas en SQL, y a partir de ahí pista libre ... repetir para cada uno de los schemas que se quiera

Exportación / Importación de patrones

2009-05-22T14:16:00.004+02:00

En la nueva versión de KMKey hemos incluido capacidades para exportar de forma completa patrones de trabajo, y para poder importarlos después desde otra instancia, todo ello desde el TAB Admin. El formato de intercambio es un simple fichero .tgz que contiene toda una serie de ficheros XML, e incluye información relativa al patrón, sus campos, su layout, sus contadores, sus vocabularios asociados, incluso los grupos de permisos necesarios para utilizarlo.

Con ello esperamos:

1) Facilitar la separación de entornos de desarrollo, pruebas y de producción, puediendo traspasar los patrones de una instancia a otra de forma sencilla, y no afectando así las configuraciones a los entornos de producción hasta que esten validadas

2) Fomentar el intercambio de patrones de trabajo entre los miembros de la comunidad KMKey. Porque, si uno dispone de un patrón de gestión comercial que le funciona, ¿ porqué no compartirlo y dejar de reinventar la rueda ? Ese es el espíritu del sofware libre que puede ayudarnos a mejorar mucho a muchas pequeñas empresas, en lugar de mejorar sólo un poco cada una. Intentaremos ubicar un repositorio de patrones de trabajo en esta misma página o en alguna vinculada

Darle cancha a postgresql

2009-05-21T12:30:00.004+02:00

Como últimamente todas las instalaciones de KMKey van totalmente sobre postgresql gracias a relstorage, es aconsejable darle más máquina a la BBDD de la que viene por defecto al instalar el paquete de postgresql.

El problema es que al intentar hacerlo nos encontramos con que da un error de máximo tamaño de buffers. La receta para solucionarlo está perfectamente explicada, aquí: http://www.postgresql-es.org/node/229 aunque lo principal, aparte de ajustar el postgresql.conf, es esto

1) Editar el fichero /etc/sysctl.conf, y añadir la linea:
kernel.shmmax = 2147483648 (para 2 GB de RAM)
268435456 (para 256 MB de RAM)
536870912 (para 512 MB de RAM)

2) Para instalar los cambios tenemos que ejecutar el comando
sysctl -p /etc/sysctl.conf

Respecto a los ajustes del postgresql.conf, para un servidor dedicado a KMKey con 2GB de RAM disponibles, podemos ajustar el shmmax a 512 MB y establecer los siguientes parámetros, a nivel orientativo:

shared_buffers = 32768
temp_buffers = 16384
work_mem = 32768
maintenance_work_mem = 16384
max_stack_depth = 2048

max_fsm_pages = 200000
max_fsm_relations = 10000

effective_cache_size = 8000

Extender el uso de patrones

2009-05-21T10:55:00.002+02:00

Aunque hasta ahora el uso de patrones se ha limitado primoridalmente a patrones de trabajo (o sea, de proyectos / expedientes), ya hace tiempo que detectamos que este modelo es muy útil por su potencia y flexibilidad, así que poco a poco lo hemos ido incorporando a otras partes de la aplicación, creando patrones de contactos, de empresas, de gastos o de ventas. En la nueva versión de KMKey vamos un pasó más allá, y vamos a abrir la posibilidad de personalizar, mediante patrones, casi todo tipo de contenido.

Se ha habilidado copiar patrones de todo tipo para poder peersonalizarlos. Así por ejemplo, podemos duplicar el patrón de gasto y crear una píldora kilometrage, en la que luego ajustemos campos y valores por defecto.

También se ha abierto la posibilidad de bloquear perfiles en la creación de dichos objetos, algo que hasta ahora sólo se aplicaba a proyectos. De esta forma, se puede configurar que las píldoras de gastos sólo sean visibles a su Propietario y al responsable del proyecto, o crear un nuevo tipo de contactos de uso exclusivo de la Dirección, por citar algunos casos

Apuesta por el Teletrabajo

2009-05-19T19:41:00.001+02:00

Hará unos cinco años que teletrabajo a tiempo completo. Fundamentalmente me dedico a desarrollar e implantar software libre y, como además el software es en entorno web, nos dijimos ¿ porqué no hacerlo a distancia ? Pasado este tiempo, y en pleno debate del cambio de modelo productivo, me gustaría compartir algunas reflexiones sobre mi experiencia

1) ¿ Que sentindo tiene perder una o dos horas de tu vida cada dia iendo y viniendo, cuando puedes realizar tu trabajo a distancia? Eso es lo primero que uno aprecia cuando teletrabaja, el tiempo ganado a los trayectos. Eso si, para evitar empleados demasiado listos, las empresas tienen que disponer de algun sistema de control de los trabajos realizados (nosotros usamos KMKey, como no podía ser de otra manera).

2) Puedes mudarte a un lugar tranquilo. Pasado un tiempo, y viendo que la situación era estable, me mudé con mi familia a vivir a Menorca. Ahora que empieza el calorcillo, plantarse en una playa paradisíaca en 15 minutos no tiene precio (no pongo fotos para no dar demasiada envídia)

3) El sueldo importa, pero no es lo más importante. Mi sueldo está lejos del de muchos compañeros de promoción, pero a veces hay que saber renunciar a algo de dinero para ganar en calidad de vida. Mi rutina matutina es levantar a los niños, desayunar tranquilamente, llevarlos al colegio dando un paseo, tomarme un café con unos amigos, y aun me sobra tiempo para llegar paseando a mi “teleoficina” a las 9 de la mañana. Cuando recuerdo como era la rutina matutina en un gran ciudad y trabajando con corbata, no lo cambiaría por nada del mundo.

4) La conciliación de la vida familiar y laboral. En mi caso eso es especialmente importante, porque con 4 hijos y una esposa que también trabaja, poder combinarse los horarios y tener una solución cuando un niño se pone enfermo a las 7 de la mañana es algo que se valora, y mucho.

Bueno, esas son las cosas que más aprecido del teletrabajo yo personalmente. Otros compañeros tienen otras preferencias, y aprovechan para trabajar algunos meses desde Argentina mientras aprenden tango, o desde Brasil tumbados al sol, en lugar de cambiarse permanentemente de residencia. Cada loco con su tema, claro.

En fin, que cuando oigo hablar tanto de aumento de eficiencia y competitividad, de fomentar negocios basados en el conocimiento y las nuevas tecnologías, de conciliar vida familiar y laboral, no puedo evitar preguntarme porqué no se implanta de una vez el teletrabajo de forma extensiva en las empresas de servicios, eliminando todos esos absurdos trayectos estresantes, compensando a los empleados con otras ventajas que no sean más dinero, dispersando a la población ... saldríamos todos ganando, porque cuando uno está contento trabaja mejor, porque acepta incluso cobrar un poco menos, porque la empresa puede buscar al mejor para cada puesto viva donde viva, etc. etc. Dejemos de ver estas cosas como algo del futuro, son el presente inmediato.

Ah ¿ que donde trabajo ? En Earcon S.L., una empresa 2.0, como lo han definido algunos de nuestros propios clientes :-)

Configuración Básica de Permisos

2009-05-15T14:09:00.004+02:00

Configuración permisos KMKey

Por defecto KMKey viene con los siguientes grupos de permisos asociados a roles de CPS, y configurados como Perfiles de Aplicación:

- Lector Aplicación (WorkspaceReader)--> Ver Contenido (y Listar)
- Usuario Aplicación (WorkspaceMember)--> Ver, Crear y Modificar

- Responsable Aplicación (WorkspaceManager) -->Ver,Crear,Modificar,Gestionar equipo y Planificar

Estos permisos se pueden configurar desde la gestión de grupos, pero respetando la coherencia de cada uno de los grupos. Por ejemplo, por comodidad, podemos tener la tentación de dar permiso de escritura al 'Lector de Aplicación' , pero lo correcto es agregar los usuarios al grupo 'Usuario Aplicación'.

Por defecto, Lector Aplicación está asociado a authenticated (vía ZMI), a nivel de site, de tal forma que cualquier usuario que se logine , podrá entrar al KM (pero no podrá ver expedientes, ya que por defecto, en los patrones, se bloquea Lector y Usuario)
Opcionalmente, También podemos asociar authenticated a Usuario Aplicación si queremos que todo el mundo pueda crear expedientes.

Por otro lado tenemos los siguientes grupos de permisos asociados a roles, pero no activados como Perfil de Aplicación, si no que serán perfiles de Expediente (sólo actuarán a nivel de expediente)

- Lector Expediente (Reader) --> Ver Contenido
- Propietario (Owner) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar
- Responsable Expediente (Responsable) --> Ver,Crear,Modificar,Gestionar Equipo,Planificar

Por defecto, cuando se crea un objeto dentro de KM, se asigna automáticamente el usuario que lo crea como Owner (si no, una vez creado, no podría acceder a él)
Para dar acceso a un usuario dentro de un expediente, podemos agregarlo como 'Lector Expediente' y en este momento podrá verlo
Para dar permisos de Modificación u otros a un usuario dentro de un expediente, crearemos los nuevos perfiles de expediente necesitemos (Técnico, Secretaria, etc...) intentando unificar y utilizar el menor número de perfiles posibles

Con esta configuración mínima, ya podemos gestionar los siguientes casos:

- Todo usuario podrá entrar a la aplicación y ver expediente, contactos y grupos
- Todo el mundo que pertenezca a 'Usuario Aplicación' podrá crear cualquier tipo de expediente (ya pertenezca al grupo de forma implicita o vía asignación a authenticated)
- Todo el mundo verá únicamente los expedientes donde esté asignado (Como creador , lector u otro)

Esta configuración contempla la mayoría de casos que necesitaremos

Configuraciones avanzadas:

Como hemos comentado antes, creando nuevos perfiles de expediente determinaremos qué podrá hacer cada usuario dentro de cada expediente (Técnico podrá añadir, pero no planificar, Responsable Delegación podrá planificar, etc... )

En la configuración de patrones, tenemos las dos utilidades siguientes:

1- Qué perfiles pueden participar y qué perfiles se bloquean (Opción 'Modificar') en los expedientes creados a partir de este patrón
2- Qué perfiles pueden ver o no el propio patrón (Acción 'Bloquear Perfiles')

La opción 1 nos permite configurar, por ejemplo (viene por defecto en todo nuevo patrón) que 'Usuario Aplicación' y 'Lector Aplicación' NO puedan ver los expedientes creados con este patrón.

La opción 2 nos permite bloquear el propio patrón, o sea, podemos bloquear el 'Usuario Aplicación' para que NO pueda crear expedientes de determinado tipo

Estas configuraciones también son aplicables a los patrones de Píldoras, permitiendo seleccionar qué perfiles podrán o no crear ventas, horas, etc...

Ejemplos:

Caso: Queremos que TODO usuario loginado vea los expedientes de determinado tipo:
Configuración : Patrón --> Modificar --> Roles Bloqueados --> Desactivar 'Lector Aplicación' (Esto lo podemos hacer también a nivel de un expediente, en gestionar contactos, desactivando el perfil bloqueado)

Caso : Queremos que únicamente el 'Responsable Aplicación' pueda crear expedientes con el patrón 'Oferta'
Configuración : Patrón --> Bloquear Perfiles --> Columna de perfiles bloqueados --> activarlos TODOS menos el de 'Responsable de Aplicación'. (Nota : Esta configuración tiene el 'problema' que, cuado añadamos un nuevo perfil de aplicación, deberemos revisar los patrones para bloquear este nuevo perfil, si es necesario, ya que no se hace de forma automática)

La definición de los permisos se puede llegar a complicar bastante, así que és muy recomendable definirla bien desde el principio.

El caso más 'problemático' sería la creación o cambios de configuración en los Perfiles de Aplicación una vez ya se hayan introducido expedientes, lo que requiere, por un lado, revisar la configuración de los patrones, y por otro, reindexar todos los expedientes para que se apliquen los nuevos cambios (sólo en caso de modificación de un perfil existente)

La recomendación es NO CREAR NINGÚN perfil de aplicación, utilizar únicamente los 3 que ya viene por defecto (Lector Aplicación, Usuario Aplicación y Responsable Aplicación) y gestionar los accesos a los patrones mediante los bloqueos de grupos de sistema, siguiendo la misma técnica q hemos comentado antes, ya que se puede aplicar a cualquier perfil, y solucionamos la problemática antes comentada

finalmente tendríamos el caso de de que queramos dar acceso a un grupo determinado a los expedientes de determinado patrón. Esto la haremos creando un campo del tipo 'KM Relation' en el schema, con un default value y un write expression string:docid_de_grupo, y asociado al role Reader, de tal forma q se asignará automáticamente al crear el expediente, una asoación entre el grupo y el perfil Reader, lo que dará acceso al expediente.

De esta forma se pueden ir añadiendo funcionalidades y cada uno sigue
viendo lo suyo, y solucionamos el problema que produce añadir un nuevo
perfil de aplicación con respecto a los expedientes existentes de
otros departamentos.

Mejoras de velocidad (II)

2009-05-13T10:18:00.003+02:00

Siguiendo con el tema de las mejoras de velocidad del programa para volúmenes elevados de datos, hemos dado con un fallo heredado de Nuxeo CPS (gestor de contenidos sobre el que se basa KMKey). El fallo estaba relacionado con la gestión de árboles de navegación, y afectaba especialmente el navtree de proyectos y tareas.

Día y medio después de la puesta en funcionamiento de la correción en entorno beta, podemos decir que ha sido un de los mayores avances en el rendimiento de KMKey. En conjunto, desde que se empezaron las mejoras en este sentido, el consumo de RAM se ha dividido por 5, el consumo de CPU ha pasado de un 100% frecuente a no superar el 40% prácticamente nunca, y la velocidad en uso de los usuarios ha mejora espectacularmente.

A falta de mejoras en puntos específicos del programa (no ya de carácter general), podemos asegurar que la nueva versión de KMKey 3 responderá bien en empresas grandes, independientemente del volumen de datos, usando simplemente un servidor de gama media, y teniendo la tranquilidad de disponer de una arquitectura totalmente escalable.

Cambiar formato de un campo contador

2009-05-13T09:55:00.003+02:00

Cuando a través de KMKey añadimos un campo a un patrón de trabajo del tipo "Contador", los expedientes creados a partir de ese patrón de trabajo tienen un formato por defecto (PM-00000), pero con frecuencia queremos que ese formato cambie en función del patrón.

Por ejemplo, si queremos que nuestras No Conformidades tengan contadores del tipo NC0000, tenemos que entrar al ZMI (http://url_kmkey/manage), e irnos al objeto portal_uid. Allí encontraremos diversos contadores, con el nombre idpatron_idcampo. Pinchamos en el que nos interesa, y nos vamos a la pestaña "Properties". En el campo "Generation Expression" ponemos el formato que deseamos, en este ejemplo "python:'NC%04i' % number"

Reconstruir un portal_repository

2009-05-12T14:13:00.004+02:00

Esta es una de las cosas en que nadie desea encontrarse: una corrupción de ZODB. De hecho es la primera que se ha producido desde que KMKey existe, y ha sido debida a una conjunción de uso de BLOGS en postgresql (cosa que no debería hacerse nunca, porque existe la alternativa de gestionarlos como ficheros locales) + errores de conexión a postgresql (que se encontraba en otra máquina y ha dado diversos problemas de conexión por DNS y máximo de conexiones permitidas). El hecho es que nos hemos encontrado con una corrupción de 11 objetos del portal_repository, que no había forma ni de borrar. Finalmente todo se ha solucionado recuperando copias de seguridad, exportando los objetos afectados del portal_repository no corrupto, y reconstruyendo el BTree. Después de eso, se han importado los objectos correspondientes el la BBDD de producción, y todo solucionado. La parte realmente dificil ha sido reconstruir el BTree, así que pego aquí el script para que quede para la posteridad:

repo = km.portal_repository
from BTrees.OOBTree import OOBTree
repo._tree_old = repo._tree
repo._tree = OOBTree()
i = 0
no_procesados = []
for mt in repo._mt_index.keys():
for id in repo._mt_index[mt]:
try:
ob = repo._tree_old[id]
repo._tree[id] = ob
except KeyError:
print "No se procesa %s" % id
no_procesados.append(id)

Formación KMKey HelpDesk

2009-05-11T23:27:00.006+02:00

KMKey HelpDesk

En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.

Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de incidencias, servicios de mantenimiento, sistemas de ayuda al usuario, servicios de atención al cliente, servicios de gestión de averías, o Tickets I*net, etc.

Conceptos principales:

Entorno colaborativo.
Los participantes en KMKey HelpDesk (permisos y accesos) pueden estar definidos desde el operador que recibe la incidencia, hasta el gerente, pasando por los técnicos o miembros de los departamentos involucrados en la solución de la incidencia.
Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
Interface gráfico para la "visualización" de la evolución de cada incidencia/averia/ticket/queja, etc..
Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de incidencias, de actividad de los técnicos, de estado de las incidencias por categoria, etc.

Las acciones propias a todos estos servicios se pueden sistematizar y automatizar como distintos patrones de KMKey HelpDesk.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.

Más que en Project y en Quality, los efectos que "causan" en KMKey HelpDesk:

la posibilidad de la sistematización de toda la secuencia de acciones en patrones de trabajo...
el hecho que estos patrones de trabajo puedan incluir un flujo de la información bien definido...
entre un número de participantes con
pocos roles intercambiables y perfiles de intervención, también, muy bién definidos

facilitan extraordinariamente las tareas de recogida de requerimientos y las labores de formación, en todo lo que respecta a las partes básicas de funcionamiento de la aplicación.

Prácticas de funcionamiento
Conceptos Previos:
Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.

Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
- quién lo inicia,
- a quién lo envia,
- a quién se notifica,
- qué decisiones se toman,
- cómo y cuando se supervisan,
- quiénes son sus responsables, etc.

Así en KMKey Help Desk tenemos a disposición un sólo patrón para la demostración.

Práctica 1

Iniciamos un patrón de Ticket I*net.
Utilizamos el usuario (eva).
Recogemos los datos.
Decidimos un Revisor de la Incidencia (raúl).

TAB DEFINICIÓN

Mostramos que se ha inciado un expediente en el NAVTREE y lo abrimos mostrando la tarea asociada.
Salimos del usuario eva.

Práctica 2

Entramos como raúl.
Mediante el sistema de Mensajes, mostramos como que da notificado de su afectación a ese expediente.
Mostramos que existen una serie de nuevos datos listos para ser recogidos a través de DEFINICIÓN > Modificar.
Raúl rellena la parte que le corresponde y la envia al receptor rafa.
Salimos del usuario raúl.

Práctica 3

Entramos con el usuario rafa.
Volvemos a mostrar como nuevos campos se añaden al TAB DEFINICIÓN.
Entramos en el expediente mediante el sistema de notificaciones que también habrá funcionado en este caso.
Rafa rellena la parte de información restante.

Prácica 4
TAB EQUIPO

Podemos asignar un usuario al expediente y darle permisos mediante un rol.
Explicar que el usuario podrá definir los roles que necesite.
Mostrar un grupo que sea de Técnicos.
Asignar un grupo de técnicos al expediente.

Práctica 5
TAB PLANIFICAR

Podemos mostrar la posibilidad de que en otros patrones (mostrar ejemplos de Project o Quality) se puede modificar la planificación de la tareas y/o sus responsables.
No hace falta insistir demasiado en ese aspecto, aunque si en el siguiente.
Mostrar como podemos realizar (para patrones en los cuales el flujo no este tan definido internamente como en el de Ticket I*net) asignaciones en fecha, (día y hora) para un técnico concreto del equipo añadido anteriormente.

TAB GESTIÓN

Introducción a la filosofía de los 4 ejes de desarrollo, aunque, en la mayoría de casos no se utilizen los 4 ejes.
Insistir en el eje conocimiento/información.

Práctica 6
Añadir Documento

Mostrar la posibilidad del gestor documental y/o gestor de versiones. Sin insistir.
Añadir un documento generado a través de plantilla. Resumen de Incidencia.

Práctica 7

Añadir Nota a uno o varios participantes.

Práctica 8

Enviar un e-mail desde el expediente.
Enviar un e-mail al expediente o tarea.

Práctica 9

Añadir una imputación de horas.
Hacerla coincidir con la asignación realizada anteriormente.
Mostrar el resultado en Historia.

Práctica 10

Añadir un gasto personal o una venta sucedidos durante la solución de la incidencia.

TAB CONTROL

Mostrar los recursos gráficos obtenidos con la pantala específica de HelpDesk.
Mostrar la pantalla de fechas.
Mostrar las posibiliadades de obtener Listados de Tickets, Tareas no finalizadas, Gastos, etc.

Cerrando el círculo

2009-05-11T16:02:00.008+02:00

Objetivo: modificar las planificaciones de economía y esfuerzo al desplazar la planificación temporal.

Problemática actual
Dentro de las evoluciones previstas para KMKey Project está la de guardar versiones de la planificación. Esto nos ha de permitir ir modificando las fechas previstas sin perder el historial y poder recuperar versiones anteriores para poder ver la evolución de la planificación.
En la actualidad estas modificaciones no tienen ningún efecto sobre las previsiones económicas y de esfuerzo que permanecen igual, aunque las fechas planificadas para la ejecución de la tarea cambien.

Evolución propuesta:
Ligar las previsiones de esfuerzo y económicas a la planificación temporal.

Modificaciones necesarias:

Esfuerzo:
Horas previstas por tarea.
Hasta ahora, cada tarea tiene unas horas previstas para completar su realización. Lo lógico es que para calcular el esfuerzo necesario, lo hagamos entre las fechas de inicio y fin previstas de la tarea. Si estas cambian en el tiempo. Los días de aplicación del esfuerzo también. La versión actual de KMKey así lo contempla
Recursos reservados.
Sin embargo, cuando reservamos un recursos en unas fechas determinadas, las horas de esfuerzo previstas pierden la relación con la planificación de la tarea. Si esta cambia, la reserva del recurso no se ve afectado. Esto es lo que seria lógico cambiar. Lo ideal es que proponga "las fechas previstas de realización de la tarea han cambiado. ¿Quiere aplicar el mismo cambio a los recursos reservados?". En caso afirmativo, ofrecer la pantalla de planificación de recursos para poder realizar la nueva asignación en el periodo previsto.

Economía:
Actualmente se puede escoger las fechas previstas para las entradas económicas, tanto si se trata de un día como de un periodo. También pueden asignarse a todo el proyecto o una fase o tarea. Pero sin relación entre ambos.
El cambio propuesto es sencillo. Por defecto, las líneas de entrada de conceptos económicos previstos, deberían tener las fechas de inicio y fin previstas en la planificación del momento. De nuevo, si estas cambian, hay que preguntar si se quieren actualizar las fechas previstas a las de la tarea.

Formación KMKey Quality

2009-05-11T13:25:00.004+02:00

En este punto se supone que se ha explicado la parte común del interface así como los procedimientos de funcionamiento operativo que son transversales a toda la aplicación.

Introducción:
La estructura propia de KMKey lo hace idóneo para su configuración como software para la gestión de sistemas de calidad de cualquier norma ISO y otras.

Conceptos principales:

Entorno colaborativo.
Los participantes en el SGC (permisos y accesos) pueden estar definidos desde el operario de planta, hasta el gerente, pasando por el propio Dpto. de Calidad y el resto de los mismos.
Los flujos de información y sus participantes pueden quedar definidas y automatizadas en el patrón.
Notificaciones automáticas (por e-mails e interna) a los participantes de cualquier acción.
Interface gráfico para la "visualización" de la evolución de cada expediente.
Registro de todas las actividades del sistema, listas para ser explotadas como listados de registros de calidad, listados de documentos, informes, resúmenes de actividad, de acciones abiertas, cerradas, en trámite, etc.

KMKey Quality incorpora un Gestor documental que contempla el Ciclo: Edición, Revisión, Aprobación y un sistema de gestión de versiones (revisiones) que lo hace idóneo para demostrar la trazabilidad, accesibilidad, actualización y validación de todos los documentos propios de la normativa:
tales como:

Procedimientos Documentados (Obligatorios o no).
Manual y Política de Calidad.
Objetivos e indicadores del sistema.
Organigramas.
Mapas de Procesos.
Instrucciones y hojas de trabajo
Formatos.

Las acciones propias a todo SGC (obligatorias por la norma o no) se pueden sistematizar y automatizar como distintos patrones de KMKey Quality.
La automatización puede extenderse a la división en distintas tareas de la acción, sus fechas y plazos de desarrollo, sus responsables, los documentos generables de registro asociados, etc.
asi como:
Todo tipo de registros (obligatorios por la norma o no).

Gestión completa de No Conformidades.
Acciones Correctivas/Preventivas.
Revisiones del Sistema.
Planes de Auditoría.
Planes de Mejora.
Planes y registro de Formaciones.
Seguimiento y Evaluación de Proveedores.
Gestión y Control de Indicadores.
y otros

Prácticas de funcionamiento
Conceptos Previos

Introducción a la "filosofía" de proyectos/expedientes en 5 pasos, que coinciden con los TABS: DEFINICIÓN, EQUIPO, PLANIFICACIÓN, GESTIÓN Y CONTROL.
Explicar (recordar) la vinculación entre patrones a la vista y filtros automáticos.
Recordar que no todos los usuarios del sistema tendrán las mismas posibilidades de "iniciar" Nuevos expedientes/acciones, o de intervenir en ellos.
Recordar que los campos de cualquier "Nuevo" son definibles según las necesidades del cliente.
En función del usuario que estemos utilizando aprovechar para entrar como "manager" y mostrar en el TAB: ADMIN la lista de patrones, su estructura XML y los campos de un patrón en concreto.
Recordar que en los patrones de las distintas acciones podemos dejar programado, TAMBIÉN, el flujo de trabajo del mismo:
- quien lo incia,
- a quien lo envia,
- a quién se notifica,
- que decisiones se toman,
- como y cuando se supervisan,
- quiénes son sus responsables,
- etc.

Práctica 1
Iniciamos (usuario santi) una NC de Proveedor para concentrar las explicaciones de patrón, campos, flujo de trabajo y equipo.

TAB DEFINICIÓN

Vemos los datos rellenados.
Hacemos observación que NO TODOS los datos de la NC se han rellenado en ese paso, pues puede que el que incia la NC no los conozca o no tenga porqué conocerlos.
Avismos que los campos para la captura de los datos que todavía faltan, irán apareciendo en función del usuario y paso en el que se encuentre la acción.

TAB EQUIPO

Vemos los participantes incorporados con perfiles de Creador y Receptor
Damos a entender que este flujo podría completarse todavía con un aprovador/revisor o enlazarlo con otra acción del sistema como podría ser una AC/AP.
Salimos del usuario santi y entramos como Albert, o el que hayamos elegido como receptor.

TAB DEFINICIÓN (2º participante)

Selecionamos el objeto en el NAVTREE y el TAB DEFINICIÓN > MODIFICAR.
Rellenamos parte de los datos en los nuevos campos que aparecen.
Mostramos como podemos iniciar en esa parte del flujo (o en cualquier otra que definiese el cliente) una AC/AP.
Realizamos la práctica de vincular una y otra.
Mostramos el nuevo expediente de AC/AP incorporado al NAVTREE.
Si no se tiene preparado, montar un filtro en el que se muestren la NC (de proveedor) y las AC/AP.
Mostrar como podemos pasar de una a la otra NC > AC/AP y de esta a la NC que la originó.
Mostrar como el flujo y los responsables/fechas/verificaciones/cierres se pueden adaptar a las necesidades de cada organización.
Mostrar como, además, con KMKey Quality tendremos la posibilidad de visualizar en cada momento el estado de cada "acción".
Mostrar como podemos dividir tanto la NC, como la AC/AP en tareas que aparecen en el NAVTREE.

En este punto hay que recordar que las explicaciones de Quality no deben hacer "demasiada" insistencia en las partes "fuertes" de KMProject que no se utilizan con el mismo "espiritu" en Quality.
Así, por ejemplo, la división de una acción en distintas tareas, con desarrollo espaciado y secuenciado en el tiempo, con responsables de cada acción queda más evidente si elegimos iniciar una patrón de Auditoría Interna, aunque sólo sea como ejemplo.
Eso es así, debido a que la mayoría de los otros patrones de Quality no dependen tanto de la división en tareas y su desarrollo "al modo" de un proyecto, como de un "flujo de trabajo y orden de intervenciónes" que sumado a unos roles bien definidos configuran toda la acción.

Práctica 2
Por tanto, iniciamos un patrón de Auditoría Interna, más como un ejemplo para LOS TABS EQUIPO y PLANIFICAR, que como otra cosa.

Mostramos mediante la apertura del nuevo expediente su división en tareas, con fechas y responsables.

TAB PLANIFICAR

Mostramos, mediante la elección de una escala de visualización apropiada, el histograma GANTT del desarrollo de las tareas.
Mostramos como mediante "Editar Planificación" o mediante "Modificar" podríamos variar a voluntad las fechas de incio y final de tarea y adaptarlas a nuestras necesidades.

TAB EQUIPO

Mostramos como podemos crear un supuesto equipo de Auditores, como Grupo de Recursos/Permisos.
Añadimos integrantes a este equipo.
Añadimos el equipo creado al expediente nuevo de Auditoria.
Volvemos al TAB PLANIFICAR.
Mostramos como podemos variar el responsable de las tareas.
Mostramos (PLANIFICAR-RECURSOS) y como en un momento dado podríamos llegar a planificar: qué auditor hace qué en una tarea y dia concreto.

Práctica 3

Realizamos una asignación y la mostramos en el TAB GESTIÓN > Historia.
Advertimos de la posibilidad de que ciertos patrones tengan como opción que las tareas se incien automáticamente con la inclusión de un item de información o que por el contrario se abarn manualmente.

TAB GESTIÓN
Aprovechando la anterior explicación y el expediente de Auditoria recien creado, pasamos al ámbito del TAB GESTIÓN

Mostramos los 4 tipos de elementos de información pertenecientes a los 4 ejes de desarrollo de todo proyecto/expediente. (INFORMACIÓN, TIEMPO, ECONOMÍA y ESFUERZO.
En este punto hay que advertir que permanecen a la vista los elementos temporales, económicos y de esfuerzo que aunque no sean demasiado "vitales" para los SGC, los mantemos a la vista como posibilidad. (Otros lientes nos los han solicitado)
Insistir en los elementos pertenecientes al eje conocimiento/información.
Volver a mencionar las prestaciones de KMKey en cuanto al mantenimiento de un sistema de gestión de documental, incorporando un ciclo (Edición, Revisión, Aprobación) totalmente nomativizado.

Práctica 4
Por tanto, iniciamos un ejercicio de "Añadir documento" y advertimos que lo someteremos por completo al ciclo mencionado.
Inciamos la práctica con el usuario santi, como editor.

Sube un documento, genera una versión y la envia a revisión.
Mostrar los cambios que se producen en la visión de Historia. (Documento -copia- Bloqueada, y copia en "Revisión".
Salir de santi y entrar como albert. Mencionar los cambios en la cantidad de patrones que puede o no iniciar y que en ese momento están a la vista.
Mostrar el sistema de mensajería y de como queda avisado (notificado) de la necesidad de intervenir en ese expediente con una tarea en concreto: revisar el documento.
Acceder al documento desde Mensajes.
Visualizar el documento y enviarlo a aprobación.
Comentar que el revisor NO DEBE editar el documento por si mismo y que si encuentra algo anormal debe "rechazar" la versión.
Explicar que entonces volvería (con notificación incluída al editor.
Salir de albert y entrar como joan.
Acceso al expediente mediante Mensajes (Notificaiones).
Aprobar el documento.
Mencionar la "consolidación" en una sóla copia de trabajo.
Mostrar (con un usuario con suficientes permisos) todo el login de actividad del documento y el sistema de gestión de versiones.

Práctica 5
Modificar un documento.
Con el fin de que este tipo de acciones que luego se convertirán en actividades frecuentes se repite la práctica anterior, pero ahora simulando que el documento ha sufrido una modificación (puede ser un logo, o un párrafo distinto)

Tener preparadas 2 versiones del documento. Mostrar las diferencias entre la que ya está incorporada y la que vamos a "subir".
Reemprender la práctica desde el momento en que el editor solicita generar una nueva versión.
Modificar ese borrador cargando el documento con el logo o el párrafo cambiado.
Enviarlo a Revisión.
Entrar como revisor
Revisarlo y enviarlo a aprobación.
Entrar como aprobador.
Aprobarlo y desde un usuario con permisos acceder mostrar el nuevo login de actividad y el cambio en el numeral de la versión/revisión.
Acceder a la versión anterior.

Práctica 6
Añadimos una nota.
Cualquier usuario redacta y envia una nota.

Mostrar el resultado en Historia.
Mostrar el filtro de información propia de la opción.

Práctica 7
Añadimos un e-mail.
Cualquier usuario (santi, albert, joan), aprovechando que ya hay documentos incorporados en el expediente de práctica:

Enviar un e-mail a otro participante o a otro contacto.
Enviar un e-mail a un expediente o a una tarea KMKey.

Práctica 8
Añadir un documento generado mediante plantilla.

Recordamos que ademas de conservar los registros en formato digital, con la información de los mismos podremos generar documentos mediante plantilla y que se pueden incorporar al expediente.
Mostrar una NC y generar un Informe/resumen de la misma.
Comentar las diferencias entre la información recogida en KMKey y la introducida mediante "Subir Dcocumento".
Comentar la posibilidad de generar el informe en distintos formatos.
Diferenciar este tipo de documentos de lo que son propiamente los Informes o Listados que obtenemos en el TAB CONTROL

TAB CONTROL

Mostrar visualizaciones de Fechas.
Informes. Extraer algún ejemplo de informe.

Mejoras de velocidad (I)

2009-05-08T18:35:00.000+02:00

A raiz del planteamiento de migración de instalaciones grandes de KMKey 2 hacia KMKey 3, se detectaron serios problemas de rendimiento de la versión 3 de KMKey cuando se trabaja con elevados volúmenes de datos.

Hemos estado trabajando intensamente para acotar y solucionar estos problemas, y los avances ya son notables, aunque quedan algunos puntos por resolver. Entre las actuaciones más destacadas, y que se verán incorporadas en la próxima versión estable de KMKey 3, se incluyen:

1) La adaptación e integración del ZSQLCatalog de ERP 5, desarrollado por Nexedi. Este catálogo permite reemplazar el catálogo standard de CMF por uno basado en SQL. Se ha tenido que adaptar para que soporte postgresql y para que se integre con AdvancedQuery. Finalmente se ha conseguido implantar en versión beta, y ya son pocos los efectos colaterales que quedan por solucionar. El cambio de rendimiento general es muy notable, y los efectos no desados pocos, teniendo en cuenta que se ha reemplazado parte del núcleo principal de la aplicación

2) Disminución en el consumo de RAM. Había ciertos puntos, como la gestión de documentos, la generación de informes, o las relaciones entre objetos, que elevaban desmesuradamente el consumo de RAM. Estos casos se han ido acotando y corrigiendo, y ahora la RAM disponible puede dedicarse a gestionar cachés de objetos o portlets, con la consiguiente mejora en velocidad

3) Cambio de campos calculados por campos pre grabados. Este punto todavía no se ha abordado, pero se perfila como el siguiente caballo de batalla para conseguir un rendimiento óptimo en instalaciones de elevado volumen de datos. Se trata de cambiar la gestión de campos calculados en ciertos objetos por campos pregrabados, en especial de esos objetos que son consulados constantemente, como tareas o proyectos, porque cuando el volumen de datos aumenta suponen un problema importante

Después de eso vendrán mejoras de rendimiento en pantallas y funcionalidades concretas, pero eso lo dejamos para un segundo capítulo

Introducción a KMKey PROJECT

2009-05-08T18:26:00.000+02:00

KMKey PROJECT
Introducción

Se supone que el hilo de la explicación/exposición, se reprende de distinta forma si explicamos Project, Quality o HelpDesk.
Creación de un expediente/proyecto nuevo.

TAB DEFINICIÓN

Rellenar campos. Campos obligatorios.
Mostrar el expediente/proyecto creado.
Desplegar las agrupaciones.
Uso de Modificar.
Ver Datos. Borrar.

TAB EQUIPO

Explicar diferencia entre contacto y usuario.
Alta de Contacto.
Mostrar lista de contactos.
Gestionar Contactos.
Explicar Perfiles de aplicación y roles de usuario.
Incorporar un usuario al nuevo proyecto.
Asignarle Rol.
Mostrar Grupos.
Explicar distinta naturaleza de Grupos: Clientes, Proveedores, Empresa, Departamento.
Grupo de Recursos. Grupo de Permisos.
Mostrar los distintos permisos y la posible combinatoria.
Explicar las diferencias entre permisos de aplicación, permisos de patrón y permisos de expediente.

TAB PLANIFICAR
Opciones (Acciones)
Añadir Tarea.

Seleccionar cualquier agrupación del proyecto creado y añadir una tarea.
Explicar las diferencias entre crear tareas o agrupaciones.
Buenas prácticas para encadenar Tareas nuevas correctamente numeradas y ordenadas.

Editar Planificación.

Seleccionar una agrupación del proyecto recien creado.
Mostrar como podemos modificar los datos que se han generado a partir del patrón en sus conceptos básicos:
Nombre de Tarea.
Orden. Concepto WBS.
Responsable.
Fecha de Inicio.
Fecha de Final.
Duración.
Esfuerzo.
Explicar la edición directa en esta pantalla.
Mover Tareas.
Desplazamientos positivos.
Desplazamientos Negativos.
Limitaciones.

Modificar.
Explicar la diferencia (ventajas e inconvenientes) entre editar/modificar las tareas generadas mediante esta opción o mediante “Editar Planificación”. Acceso a Calendario.

Visualizaciones:
Gantt.

Explicar el funcionamiento de las “opciones de visualización”.
Escala de visualización.
Fecha de Inicio.
Mostrar para el proyecto recien creado visiones de los histogramas con distintas escalas de visualización.

Fechas.

Mostrar la correspondencia de esta pantalla con los datos “patronables” del proyecto. Añadir a la explicación el concepto de: Estado (Activo, Inactivo, etc)

Recursos.

Comentar que esta es una de las pocas pantallas de la aplicación donde dentro de una “visualización” podemos interactuar con la aplicación de forma directa.
Diferenciar entre el esfuerzo planificado en la definición del patrón, con la Planificación de recursos y la asignación de horas a recursos por tarea.
Recordar la importancia de contar con Grupos de recursos y su adscripción a proyectos/expedientes (Equipo).
Mostrar las columnas resumen: Periodo / Tarea / Esfuerzo.
Explicar los recursos gráficos de alerta (rojo-Verde-Intermitencia) de las desviaciones registradas.
Mostrar la diferencia entre la Planificación con vistas por dias (semana) o por semanas (meses).
Comentar verbalmente la posibilidad de efectuar asignaciones periódicas.
Efectuar una asignación a Cristina (o Enric) en un día planificado (fondo azul).
Explicar las diferencias entre la asignación: “Lo antes posible” ó “Durante todo el periodo”.
Efectuar una asignación de 20 horas durante toda una semana.
Mostrar la distribución.
Mostrar los indicadores de sobreasignación de horas por recurso.

Previsiones.

Añadir Previsión.
Explicar brevemente los Conceptos Contables definibles.
Salir de usuario y entrar como manager para mostrarlos.
Explicar que son totalmente definibles por el usuario.
Explicar que podremos tener más de una previsión ecnonómica para poder realizar comparaciones.
Mostrar una Previsión ya efectuada.
Insitir en la posibilidad de diferenciar la previsión o en general para todo el proyecto o para tareas en concreto.
Editar Previsión.
Añadir una linea como ejemplo en la previsión mostrada.

TAB GESTIÓN
Opciones (Acciones)
Iniciar Tarea

Recordar la posibilidad de que por patrón, las tareas se inicien automáticamente con el añadido de cualquier píldora o bien, “manualmente”, mediante esta opción. Recordar que las tareas se tienen que abrir, en la fecha que se inician.

Reabrir Tarea

Explicar esta posibilidad.

Añadir
Introducir la filosofía de los 4 ejes de desarrollo de todo proyecto:

Eje Información
Eje Temporal
Eje Económico
Eje Esfuerzo.

Añadir Documento.

Ejemplo de subida de un documento.
Explicar la diferencia entre elementos de información que incorporamos con datos externos (documentos externos) y aquellos que podemos generar, con datos recogidos en KMKey, a través de plantillas.
Ejemplo de generación de un documento mediante plantilla (mostrar alguna ya efectuado).
Explicar el sistema de gestión documental y gestión de versiones incorporado.
Hacer un ejercicio de generación de versión. Modificación. Validación de versión.
Explicar los estados: bloqueado, borrador, en trabajo.
Mostrar el registro de versiones.

Añadir e-mail.

Mostrar la posibilidad de enviar e-mails directamente a los participantes incorporados como equipo al proyecto, y de la no necesidad de volver a tener que subir documentos ya incorporados a KMKey si queremos incorporarlos como adjuntos.
Mostrar también como enviar e-mails a tareas o proyectos de KMKey. Código de e-mail en DEFINICIÓN.

Añadir Nota.

Si no se ha comentado anteriormente insistir entre la vinculación de añadir una nota y notificar (o no) a varios participantes del proyecto.

Añadir Progreso.

Explicar el concepto de progreso. Su estimación porcentual y su valoración subjetiva para el gestor del proyecto.
Diferenciar entre tarea cerrada (completada y cerrada) o aquellas que pueden estar completadas pero aún no cerradas. (Progreso al 100%)

Añadir Compra.

Realizar un ejemplo.
Mostrar vinculación con conceptos contables.

Añadir Gasto Personal.

Realizar un ejemplo.

Añadir Venta.

Realizar un ejemplo.
Mostrar vinculación con conceptos contables.

Añadir Imputación de horas.

Si estamos con el usuario (enric) y anteriormente en la opción Recursos del TAB Planificar hemos realizado una asignación de esfuerzo a la usuario (cristina) para un dia concreto, es bueno salir de ese usuario, entrar como (cristina), entrar por Mensajes, o Agenda, localizar una asignación en concreto y realizar esa imputación de horas.
Mostrar el resultado final en la visualización Historia del TAB Gestión.
Mostrar el resultado en Agenda.

Visualizaciones
Historia.

Mostrar una tarea que contenga “pildoras” de todo tipo.
Mostrar el filtro de píldoras.
Efectuar alguna selección y devolver el filtro a su estado anterior.
Explicar el significado de los distintos colores utilizados.
Ejemplos de “sort” por columnas (ascendente/descendente).

Agenda.

Mostrar un día pasado, con el registro de varias actividades, o un día futuro, con la planificación de varias asignaciones.

Documentos.

Mostrar la pantalla y su utilidad.

Info Items.

Mostrar la pantalla y escoger algún documento, nota o e-mail registrado en la tarea.

Por categoría.

Comentar que las categorías son definibles por el usuario.

Mensajes.

Recordar el sistema de mensajería interna explicado en sesiones anteriores. Mostrar ejemplos del funcionamiento.

TAB CONTROL
Opciones (Acciones)
Listados

Mostrar ejemplos de Listados.

Visualizaciones
Fechas

Explicar los códigos de colores y alertas gráficas.

Gantt

Explicar las diferencias con la visualización que obtenemos en PLANIFICAR.

Esfuerzo

Explicar el funcionamiento del filtro de opciones de visualización. Mostrar ejemplos y alguna comparación Planificado vs. Real.

Economía

Explicar el funcionamiento del filtro de opciones de visualización. Mostrar ejemplos y alguna comparación planificado vs. Real.

Semáforos

Explicación de los códigos gráficos (Verde, Ámbar y Rojo) y de los tres apartados o visiones del proyecto desde el punto de vista de progreso, esfuerzo y economía.

Formación General en la Aplicación

2009-05-08T17:54:00.000+02:00

Introducción al Interface.

Loggin
Explicación de:

Usuario
Password

Comentarios breves sobre conceptos tales como:

Aplicación desarrollada en software libre. 100% web.
Usuarios ilimitados y distribuidos.
Multiproyecto, multiempresa, multidioma.
El nombre de usuario condicionado por los permisos otorgados dispondrá la aplicación para responder de una forma adaptativa.
Misma plataforma distintas funcionalidades y accesos.
Se avisa que en transcurso de la sesión podremos observar como, entrando a la misma url, con distintos usuarios, la aplicación responderá con más o menos funciones.

Primera Pantalla KMKey
Explicación de la división de la pantalla en tres áreas reconocibles.

Cabecera.
Navtree.
Body.

CABECERA
Parte izquierda

Nombre de Usuario y nº de Roles.
Comentario sobre concepto de “rol” y la posibilidad para el mismo usuario de intervenir con distintas funcionalidades en diferentes expedientes/proyectos (perfiles).

Parte Central (1)
Mensajes: (Nuevos Mensajes).

Comentario sobre el sistema de mensajería interno de KMKey y la posibilidad de que cualquier acción que realizemos no sólo quedará registrada, sino que además podremos notificar a una o varias de las personas de las que intervienen en el expediente/proyecto de la realización de la misma.
Comentario sobre la posibilidad que estás notificaciones se realicen, para según que acciones y en función del proyecto/expediente, de forma automatizada.
Acceso a la lista de mensajes recibidos. (Disponer de alguno que funcione o no esté desactualizado y mostrar su funcionamiento).
Comentario breve sobre los tres sistemas de “notificaciones de KM (e-mail, internas y sms).

Parte Central (2)
SALIR

Comentario sobre la buena práctica que representa “terminar” la sesión, al acabar nuestro trabajo con KMKey.
Verbalizar la ausencia de temor a perder cualquier tipo de dato.

Parte Derecha
Línea para introducir “BUSQUEDAS” indexadas.

Comentario sobre este sistema de búsqueda rápida de información.
Mostrar mediante ejemplo su funcionamiento y acceder a las piezas encontradas.

Indicador de Selección(Ojo)

Explicar que esta línea siempre nos describirá el objeto que tenemos seleccionado en el navtree.
Mostrar algún ejemplo abriendo un expediente/proyecto y seleccionar el raíz o cualquiera de sus tareas o agrupaciones. Sin profundizar en esos conceptos, sólo para ver como la línea cambia el descriptor.

Área de TABS

Explicación sobre la división de las funcionalidades de la aplicación mediante su estructuración en 5 + 1 TABS.
Si no hemos entrado como manager avisar que existe un sexto TAB (ADMIN).

Introducción a la “metodología” 5 pasos.
Explicación de la división de las funcionalidades de cada TAB en:

Opciones de visualización de la información (enmarcadas).
Acciones para interactuar con la aplicación.

Pasar brevemente por cada uno de los TABS y mostrar visiones y opciones.
Insistir en la importancia de la representación en pantalla de la información seleccionada, para preparar el concepto de Body.

Nuevo:

Breve introducción al concepto de “patrón de trabajo”.
Mostramos que con está acción INICIAMOS uno de esos patrones de trabajo. Cualquiera de los que estén a la vista. Sin profundizar en ese momento.

Filtros:

Explicación de la relación entre “patrones en uso” y filtros automáticos por tipo de “patrón”.
Mostrar ejemplos de selección sobre expedientes/proyectos ya creados, para preparar la introducción el concepto de “Navtree”.
Mostrar la ventana de edición del Filtro.
Explicar las funcionalidades y la importancia de acostrumbrarse a las selecciones mediante filtros ad-hoc, y el uso avanzado (potencial) del mismo.
Filtro doble; Filtro Proyecto + Filtro Tareas.
Usar un filtro que muestre un solo proyecto (como ejemplo mínimo).

NAVTREE
Después de haber seleccionado un solo proyecto, introducir el concepto “Seleccionar Todo” y propiamente el de NAVTREE.

Flechas de desplazamiento y ayudas para la navegación.
Símbolos “+”, “-” y “>”.
Introducción de la división de los proyectos/expedientes en Tareas y/o Agrupaciones de las mismas.
Volver a seleccionar tareas o agrupaciones o cabeceras de expediente/proyecto y mostrar las diferencias de color en el ámbito de lo que está seleccionado y lo que no.Recordar Indicador de Selección (Ojo)
Volver a utilizar algún filtro.

BODY

Introducción al concepto cartesiano.
Reafirmar la explicación con el concepto de fila y columna de una “hoja de cálculo”, siendo el contenido de la fusión (“celda”) equivalente al de BODY.
Repasar el cambio de contenido del BODY habiendo dejado seleccionado un sólo objeto y seleccionando primero diferentes TABS, y a continuación (sin cambiar de selección), diferentes opciones de un TAB.
Dejar fijada esa selección de opción y TAB, para pasar a seleccionar diferentes objetos y mostrar como la información contenida en el BODY varia en función del objeto, pero no en su naturaleza.

PATRONES
Conceptos Básicos
Definición de patrón

Introducción del concepto “patrón” como: “Conjunto de tareas, recursos, sus planificaciones, elementos de información, y flujos de circulación de la misma, susceptibles de ser repetidas, ante cualquier acción que emprendamos en el ámbito de la organización donde queramos aplicar KMKey”.
Mostrar ejemplos utilizando los diversos patrones de KMKey Quality o Project.

Conceptos

Nombre de Tarea.
Responsable.
Esfuerzo previsto.
Fecha de Inicio, Fecha de Final de tarea.
Campos.

Mostrar distintos campos de distintos patrones, necesarios para definir el mismo.
Enlazarlo con TAB DEFINICIÓN y mostrar un proyecto/expediente con estos datos rellenados.
Aprovechar la ocasión para demostrar que los campos de ese patrón pasarán a fromar parte de los criterios seleccionables para la generación de nuevos filtros de usuario.

TAB ADMIN
En este punto, sea cual sea el nivel o la plataforma que interese para la sesión, abandonamos el usuario en el que estemos y entramos en la misma “url” como manager.

Mostrar la aparición del nuevo TAB ADMIN.
Mostrar la lista de patrones.
Mostrar brevemente la estructura XML de la composición de un patrón.
Mostrar brevemente cómo se realiza la introducción de los conceptos principales: Nombre de tarea, orden de la secuencia (WBS), fecha de inicio prevista, fecha de fin prevista, duración, esfuerzo previsto y responsable.
Mostrar brevemente la composición y distinta naturaleza de los campos que componen la pantalla de DEFINICIÓN.
Extender la explicación de aquellas acciones (en general) que son susceptibles de ser “patroneadas” y poder así ganar tiempo en su generación.
Mostrar el ejemplo contrario (tareas que tenemos que acondicionar y crear ad-hoc) mediante el uso de un patrón del tipo “Configurable”.

Salir del usuario manager y volver a entrar como (santi, enric, eva).

En este punto si el propósito de la sesión sigue siendo una visión general, podemos generar un proyecto/expediente con el patrón configurable y seguir con él la explicación básica del funcionamiento de los TABS.

Si por el contrario la sesión se va a dedicar a Project, lanzamos un patrón “Contrato” en Project, si es en Quality, elegimos una “NC de Proveedor”, si es en HelpDesk un “Ticket” (Incidencia).

Mis proyectos bajo control. La solución: KMKey Project

2009-05-07T10:26:00.001+02:00

1)La necesidad:

Quedan atrás los momentos en que era suficiente una estructura de “carpetas electrónicas” y una hoja de cálculo para ordenar la información de nuestra empresa. Con la aparición de las redes y de la red de redes el trabajo en entorno colaborativo no solo es una posibilidad si no una necesidad. Si entendemos como “conocimiento” toda la información que nuestra empresa necesita, produce, transmite y almacena para ayudarnos a alcanzar los objetivos previstos, su gestión se convierte en una tarea primordial. Diversas soluciones van apareciendo en el mercado para dar satisfacción a esta necesidad. Nos inundan con siglas y jerga, algunas de ellas se hacen un lugar en el diccionario de los informáticos. ¿Quien no ha oído hablar de ERP, CMS, CRM o de las mas modernas BI, Cloud computing o knowledege management?.

Pero nosotros trabajamos con PROYECTOS y lo que realmente nos importa es: COMO VAN NUESTROS PROYECTOS. Nótese que hablamos en plural: PROYECTOS.

2)La realidad:

¿Cuales son nuestros PROYECTOS?¿La construcción de un edificio?¿Investigación en biología molecular?¿El diseño de un submarino?¿O simplemente, la solicitud de una subvención?

A simple vista se pueden intuir las enormes diferencias a la hora de abordarlos, aunque también podemos vislumbrar que tendrán trazos en común.

Tenemos una primera variable a ponderar: de que tipo de proyectos estamos hablando.

Si se terminará ahí la problemática sería relativamente sencillo dar con una solución que de satisfacción a las diferentes posibilidades. Pero las dificultades en el escenario no han hecho mas que empezar.

¿Lo vas a trabajar solo o en equipo?¿Están los miembros de tu equipo en el mismo lugar físico o distribuidos geográficamente?¿Pertenecen a la misma empresa o a varias?¿Todos utilizan el mismo idioma?¿Van a tener la misma relación con el proyecto o van a jugar diferentes roles?¿Y la frecuencia?¿Trabajaran siempre en el proyecto o muy de vez en cuando?¿Disponen todos de las mismas herramientas informáticas (SO, programarlo etc..)? ¿Nos relacionaremos con otros sistemas?

Nos a surgido otra variable, o para ser mas exactos: diferentes variables que podemos agrupar en una: el entorno y no me refiero al que mentaba Cruyff.

El tema se va volviendo mas complejo. ¿Y si además este entorno no es estable?¿Cambian las condiciones, los participantes, los lugares ..?

¿Con este escenario, seria cuerdo pensar que un solo programa puede dar la mejor respuesta a todas las necesidades?

La respuesta es NO.

Cada caso tiene su mejor respuesta.

3)La solución: KMKey

Conscientes de ello, desde el inicio del proyecto KMKey decidimos centrarnos en dar respuesta a un universo de empresas que pudieran necesitar un Software de Gestión de Proyectos que diera soluciones a necesidades reales. Cuando la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de los E.E.U.U., como parte del proyecto, Polaris creo el sistema PERT, seguro que le fue de mucha utilidad. Probablemente a una empresa que quiera gestionar una promoción de viviendas unifamiliares no le sirva para nada.

Mas allá de como trabajan los programas que pretenden convertirse en standards, definimos las características que debía ofrecer nuestra solución:

3.1)Características principales:

Libre

Tanto KMKey com el software base utilizado en su instalación siguen los preceptos del software libre (Open Source Software). Se distribuye bajo licencia GPL. En resumen, estamos hablando de una aplicación cuyas fuentes se entregan al cliente, no se cobra por licencia y se puede modificar el código siempre que no se revenda cobrando. Esto nos garantiza el total acceso al programa y nos da independencia del proveedor ya que en caso necesario podemos actuar modificando hasta la última linea del programa.
Adaptable

Exceptuando los principios básicos de usabilidad con los que funciona KMKey, la solución se puede adaptar a las necesidades del cliente mediante configuración. Los proyectos pueden seguir una metodología de trabajo pre-configurada en tantos Patrones de trabajo como sea necesario. Entendemos como Patrón de trabajo el procedimiento que utilizaremos para abordar un tipo de proyecto. Pero no solo la distribución de tareas, sino los perfiles que lo trabajaran con sus permisos, los conceptos contables a utilizar, los documentos que podremos generar desde el expediente, las notificaciones y avisos etc..
Es decir, una vez decidido como vamos a enfocar la gestión de un tipo de proyectos de terminados lo reflejamos en un patrón que utilizaremos cada vez que nos enfrentemos a un proyecto de este tipo.
Obviamente, una vez generado el expediente del proyecto si este no responde exactamente a como se ha diseñado el patrón, se pueden introducir cambios para adaptarlo a la realidad.
Integrable

Es muy probable que KMKey no sea el único programa o sistema que use la empresa. Posiblemente puede darse la necesidad de compartir datos con otras aplicaciones. KMKey se puede enlazar de diferentes formas para compartir la información y en la actualidad lo está realizando con ERPs, CRMs sistemas de autentificación, BBDD etc..

También es posible intercambiar información con otras soluciones de gestión de proyectos como MS Project.
Usuarios ilimitados

KMKey no tiene restricciones en cuanto al número de usuarios. Ni usuarios contratados, ni concurrentes, ni módulos, ni nada.. Sencillamente lo pueden utilizar tantas personas como les facilitemos un usuario. Las únicas restricciones vienen por la capacidad del servidor de dar respuesta a las peticiones, sean estas de pocos usuarios muy activos o de muchos que lo utilizan de vez en cuando.
Multiproyecto

La realidad nos indica que son pocas las empresas que acometen un solo proyecto. Lo normal es que tanto empresas como usuarios estén involucrados en muchos proyectos que deben ser gestionados al mismo tiempo. KMKey asume en sus funcionalidades esta premisa y está pensado para dar respuesta a la gestión y control de multitud de proyectos simultáneos.
Multiempresa

Multigrupo, sería la palabra correcta. Las personas se asocian en grupos. Estos pueden ser empresas, sedes, departamentos etc.. los componentes de uno de ellos pueden ver una serie de proyectos y los de otro grupo, otra serie totalmente diferente. La información está compartimentada según los permisos que se otorguen.
Multi idioma

Cada usuario puede escoger el idioma de trabajo en KMKey. También, configurando correctamente, se puede escoger el idioma de trabajo de un proyecto en concreto incluyendo documentos generados automáticamente e informes.
100% Web

KMKey está pensado desde el primer momento y la primera línea para ser una aplicación totalmente Web. Es decir, se puede utilizar desde cualquier punto del globo que tenga un acceso a Internet y un navegador (Firefox o Iexplorer). Esto nos permite trabajar de una misma forma independientemente de donde nos encontremos, tanto el director de proyecto com el administrador del sistema, el técnico o el comercial.

3.2)Ejes de trabajo:

La características anteriormente expuestas nos garantizan el adecuado entorno de trabajo. Por si solo no sería suficiente si la aplicación no estuviera correctamente estructurada y fuera intuitiva y de fácil uso. De las multiples teorías de gestión de proyectos escogemos y adaptamos varios conceptos para ordenar la información de una forma lógica y comprensible. Esto nos permite planificar, gestionar y controlar los proyectos en sus cuatro ejes principales: tiempo, esfuerzo, economía e información.

-Tiempo

El proyecto, subdividido en tareas y agrupaciones de tareas se puede planificar en el tiempo. Asignar fechas previstas de inicio y fin, duraciones, contingencias etc... Una vez en marcha el proyecto se introducirán las fechas reales en las que se realizan las tareas. La comparativa entre ambas nos darán idea de la marcha del proyecto, sus posibles retrasos etc.. Podremos visualizar el avance cronológico mediante gráficos Gantt, tablas de fechas, agendas..
-Esfuerzo

A cada tarea se puede asignar un esfuerzo previsto en horas/hombre. Los diferentes usuarios a medida que van trabajando, introducen las horas que han invertido en sus intervenciones. Estas horas, que pueden ser de diferentes tipos, nos sirven para valorar los recursos empleados en el proyecto y su coste asociado.
-Economía

KMKey permite definir unos conceptos contables donde estructurar la economía de los proyectos. Establecer unas previsiones según estas estructuras y una vez imputadas las entradas económicas reales establecer comparativas. También dispone de facilidades para la generación de ofertas, facturas, gastos personales etc.
-Información

Los tres primeros conceptos son los habituales en las teorías, nosotros añadimos uno nuevo: relacionar una base de datos del conocimiento al proyecto. Lo diseñamos mediante la facilidad de añadir “píldoras de información” en las tareas. Entendemos como píldoras unidades de información en cualquier formato: archivos, documentos, correos electrónicos, notas, mensajes .. La información que contienen es indexada de tal manera que se puede consultar con una búsqueda tipo “Google”.

3.3)Modelos:

¿Como podremos disponer de KMKey? Teniendo claro que su uso es siempre a través de un navegador, su instalación se puede realizar mediante tres vías principales.

-Juan Palomo

Si somos usuarios avezados en programador libre o nos gusta la informática “bricolaje” nos podemos arremangar las mangas de la camisa y visitar www.kmkey.org para hacer nuestra propia instalación. Apoyados por usuarios con mas experiencia en listas de correo, podremos paso a paso disponer de KMKey en el servidor que hayamos escogido a tal efecto.
-SaaS

El Software as a Service (software como servicio, alias ASP, alias Cloud Computing) se impone día a día como una solución válida en las empresas. Sobretodo en aquellas distribuidas, con usuarios móviles, colaboradores externos etc. De forma muy resumida, podemos definirla como: alquilamos un proveedor (típicamente un ISP) que se encargue de todo (espacio en disco, comunicaciones, seguridad, copias..) y nosotros pagamos una mensualidad y nos olvidamos del tema
-Home

Para aquellas empresas con gerentes mas “tradicionales”, la instalación se puede realizar en un servidor en las dependencias del cliente. Ya sea Linux o Windows, en este caso, aplicación y datos residen en la propia empresa. Su acceso externo a través de Internet puede ser activado a conveniencia según la configuración de los dispositivos de comunicación.

Hemos presentado, de forma my somera, una solución que puede ser útil a la mayoría de empresas que gestionan proyectos en un entorno colaborativo de trabajo. Es la combinación de todas las características presentadas lo que dan una ventaja competitiva frente a otras soluciones enfocadas de una forma mas sectorial o pensadas para un solo individuo o proyecto. El objetivo principal es dotar de una herramienta útil y eficaz. Dar la posibilidad de tener una rápida respuesta a mano cuando nos pregunten: ¿como van los proyectos?

Cambiar de enconding postgresql >= 8.3

2009-04-28T10:58:00.001+02:00

Las versiones de postgresql más nuevas vienen con encoding por defecto UTF-8, y además obligan a que todas las BBDD del cluster tengan el mismo encoding. Si nos interesa trabajar con LATIN9 (y en KMKey nos interesa), entonces tenemos que inicializar de nuevo el cluster. Como no es algo que se encuentre a la primera en un man, dejo aquí un pequeño recetario de como hacerlo

Con usuario root, añadimos el locale:

En Ubuntu:

localedef -i es_ES -f ISO-8859-15 es_ES@euro
locale-gen es_ES@euro

En Debian:

dpkg-reconfigure locales
/etc/init.d/postgresql stop

Con usuario postgresql:

su postgres
cd /var/lib/postgresql/8.3
mv main main_old
/usr/lib/postgresql/8.3/bin/initdb /var/lib/postgresql/8.3/main/ --locale=es_ES@euro --lc-ctype=es_ES@euro
cp main_old/postmaster.opts main/
/usr/lib/postgresql/8.3/bin/pg_resetxlog main
cp main_old/*crt main
cp main_old/*key main

Después de esto ya podemos iniciar postgresql de nuevo, y crear nuestas BBDD con LATIN9

XML para definir objetos en patrones

2009-02-17T10:57:00.004+01:00

Estructura básica de un XML de tareas de un patrón de proyectos:

<?xml version="1.0"
encoding="iso-8859-1" ?>

<default_portal_type tag="task"
portal_type="KMKey Task" />

</task>

</objects>

Atributos más usados del TAG task:

task_id: ID interno de la tarea, sirve básicamente para filtrar documentos generables sólo desde determinadas tareas

wbs: Es el orden WBS de las tareas (x.y.z). Determina su orden por defecto en el navtree

Title: Es el nombre de la tarea

Description: Puede contener una descripción más larga de la tarea, como una explicación de lo debe hacerse en ella

planned_start: Es la fecha prevista de inicio. Lo habitual es que sea calculada en función de la fecha de la tarea padre (parent) o de la fecha del proyecto (root). Asi, lo normal es planned_start=”root['planned_start']+24” o planned_start=”root['planned_end']-150”

planned_end: Igual que la anterior pero con la fecha de fin prevista

planned_hours: Puede contener un valor entero que corresponderá al esfuerzo previsto, es decir, al número de horas que se prevé dedicar para realizar la tarea

responsible: Es el responsable de la tarea. Puede definirse un usuario concreto, en formato responsible=”user:nombreusuario” o bien a un perfil, en formato responsible=”role:tecnico”. En este segundo caso, se designará como responsable de la tarea a la persona que tome el perfil “tecnico” en el proyecto

workflows: Lista de ID's de patrones a los que se puede enlazar desde esta tarea (tal y como aparecen en la pantalla de Admin / Patrones), separados por #@. Cuando el proyecto esté creado, el workflow se podrá ejecutar desde la pestaña Planificación / Flujo de Trabajo. Existe la opción, además de enlazar con otro patrón de trabajo, de incluir nuevas tareas del propio patrón. En ese caso, debe indicarse del modo task999, siendo 999 el task_id de tarea incluible. Finalmente, tanbién se puede decidir incluir tareas de otro patrón, pero sin cambiar el tipo de datos del proyecto actual. Eso es muy útil si se quiere mantener la estructura de campos actual, pero incluir tareas y/o perfiles de otros patrones. La sintaxis en ese caso sería tasks(id_patron)

conditional: Se usa para tareas que no se crean inicialmente con el proyecto, pero que pueden ser incluidas desde otras tareas, mediante la opción del workflow. Es un atributo opcional, y puede tomar los valores "1" o "0"

Otras opciones avanzadas usables en los patrones:

<default_value attribute="responsible" value="user:akiwit"/>
Este tag nos permite definir valores por defecto a nivel de expediente. Esto es útil si no nos conviene
definir valores por defecto en los campos de schema comunes (kmkey_project por ejemplo)

<access usernames="akiwit,akiwit" roles="Owner,Reader"/>
<access groups="41718292,4343413,134321" roles="Owner,Reader"/>
Nos permite definir accesos de usuarios por defecto, a nivel de proyecto.
La nomenclatura es usernames="user1,user2,user3..." roles="role_para_user1,role_para_user2,role_para_user3"

<groups ids="41718292,4343413,134321"/> o <contacts ids="x,x,x,x"/>
Nos permite asignar grupos y personas seleccionadas

<objects_to_copy ids="914865118#@1321223613"/>
ids es la lista de getDocids de los objetos que queremos copiar dentro del nuevo expediente.
Útil para copiar documentos o previsiones, incluso una tarea de algún expediente modelo
(se copia el objeto entero con todo su contenido)

Bloquear perfiles según patrón

2008-08-12T10:56:00.000+02:00

El funcionamiento por defecto de la seguridad en proyectos de KMKey consiste en tener al menos los siguientes perfiles a nivel de aplicación:

WorkspaceReader: asignado a todo el mundo con usuario (Authenticated)
WorkspaceMember: asignado a aquellos usuarios con capacidad de creación de proyectos o contactos
WorkspaceManager: asignado únicamente al administrador

Por defecto, al crear un nuevo proyecto, se bloquean los roles WorkspaceReader y WorkspaceMember, de forma que sólo WorkspaceManager + los usuarios asignados localmente al proyecto tienen acceso al mismo.

Como este esquema de perfiles de aplicación se amplía con frecuencia, existía en KMKey una propiedad del portal que permitía definir qué perfiles deben bloquearse cada vez que se cree un proyecto. El problema se daba cuando ciertos usuarios debían ver todos los proyectos de un tipo, pero no todos los de otro tipo. Para solucionar este caso, se ha trasladado al patrón de trabajo la configuración de qué perfiles deben ser bloqueados cada vez que se cree un proyecto basado en ese patrón, dando así respuesta a todos los casos planteados.

Incluir links a objetos en un patrón de trabajo

2008-07-11T10:55:00.000+02:00

Desde la versión 08.07.01 KMKey incorpora la posibilidad de incluir en la definición de los patrones de trabajo enlaces a otros objetos existentes. Ello se traduce en que cada vez que se crea un proyecto basado en ese patrón de trabajo, se crean también enlaces a esos objetos.

El caso concreto que fomentó este desarrollo era el de un cliente que tenía toda una serie de documentación de referencia y quería que dicha documentación fuera incluida automáticamente en ciertas tareas de cada proyecto, pero en forma de enlace, es decir, que en los proyectos no hubiera un duplicado del documento, sinó un apunte al documento original.

Para configurar esta funcionalidad, basta con incluir las sentencias correspondientes en el XML de creación de objetos del patrón de trabajo:

<default_portal_type tag="proxy"
portal_type="CPS Proxy Document" />

Como se observa, la sentencia proxy debe incluir el id del nuevo objeto (puede ser cualquiera mientres no colisione), el docid del objecto orígen, el idioma (siempre "es"), y la revisión a la que se apunta (puede ser 1, 2, 3 ... en función de la versión del documento original a la que se quiera apuntar

Bloquear partes de un upgrade

2008-06-20T10:55:00.000+02:00

De vez en cuando es necesario configurar de forma distinta, para un cliente en concreto, partes genéricas de la aplicación. Por ejemplo, en clientes donde no se use la gestión de recursos, puede ser necesario deshabilitar el action correspondiente en el portal_actions. Pero ese cambio desaparecería al realizarse el próximo import del step "Actions Provideers". Para evitarlo se ha incluido, en la versión 08.06.01, un nuevo atributo "block_import", que permite marcar qué acciones deseamos que se importen de nuevo y cuales deseamos mantener sin cambios.

El mismo concepto se ha aplicado a los portal_layouts. Cuando queremos bloquear las actualizaciones de un layout concret, podemos añadir al mismo una Property "block_import", de tipo Boolean, con valor True

Gestionar Traducciones en KMKey

2008-06-16T10:42:00.000+02:00

KMKey está desarrollado sobre CPS y Zope 2.9.4, con lo que gestiona las traducciones por dos vías distintas: la incorporada por CPS, usando Localizer al estilo Zope 2, y la incorporada por Five al estilo Zope 3. Es importante tener claro qué partes del programa usan cada uno de los tipos de traducción:

En general, todo lo que forma parte del código python o TAL se traduce con el sistema de Zope 3, mediante un extractor capaz de localizar las cadenas e incorporarlas en el directorio Producto/locales/idioma/LC_MESSAGES.
Las cadenas propias de la configuración via ZMI, como nombres de TABs o Actions, de menús, de campos, etc, se traducen mediante el antiguo sistema de Zope 2. En este caso se carece de extractor, y las cadenas deben ir introduciéndose manualmente en el i18n/default.pot

Para extraer las cadenas a traducir necesitaremos una instancia de Zope 3, perferentemente superior o igual a 3.4.0. Por ejemplo:

wget http://www.zope.org/Products/Zope3/3.4.0c1/Zope-3.4.0c1.tgz

tar xzf Zope-3.4.0c1.tgz

cd Zope-3.4.0c1

./configure –prefix=/usr/local/zope340c1

make

make install

/usr/local/zope340c1/bin/mkzopeinstance -d /usr/local/z3instance

Ahora ya podemos realizar la extracción de cadenas de KMKey y traducirlas. Por ejemplo:

cd Products/KMKeyDefault

/usr/local/z3instance/bin/i18nextract -p . -o locales -d kmkeydefault

/usr/local/z3instance/bin/i18nmergeall -l locales

cd locales/es/LC_MESSAGES/

poedit kmkeydefault.po

Para ver en funcionamiento las nuevas traducciones, recordemos siempre que debemos regenerar los ficheros .mo:

python2.4 ../KMKeyCore/utils/generate_mo_files.py

Para incluir traducciones de Zope 2, deberemos editar manualmente el i18n/default.pot, y añadir las nuevas entradas, sin traducción. Después debemos mezclar con cada uno de los idiomas y traducir.

msgmerge -o es.po -s es.po default.pot

poedit es.po

Para que este tipo de traducciones sean visibles desde la aplicación, es necesario realizar el import del step Localizer desde el ZMI portal_setup. pestaña imports