martes, 18 de noviembre de 2014

Sprint Klau General

0 comentarios
 
Este sprint lo hemos centrado principalmente en realizar mejoras de usabilidad en kmkey y en mejorar el rendimiento de algunas operaciones a nivel interno, aunque como viene siendo habitual en los últimos sprints también hemos añadido algunas nuevas funcionalidades.

Dentro de las mejoras de usabilidad destacan 2 novedades relacionadas ambas con el modo de añadir expedientes nuevos. Por un lado hemos modificado el action para añadir un nuevo expediente de modo que se muestre aunque haya seleccionado un expediente, este cambio nos permite no tener que eliminar los filtros o selección del objeto con el que estamos trabajando para añadir un nuevo expediente de mismo tipo al contenedor. En la misma línea, hemos añadido la posibilidad de añadir un nuevo expediente de cualquier tipo de los que pueda el usuario sin necesidad de navegar hasta el tab correspondiente, esta acción se encuentra junto al filtro rápido.

Otro de los cambios significativos es que ha desaparecido el tab de primer nivel RRHH que se ha cambiado por RECURSOS, y ello es debido a que se ha introducido una nueva opción que permite añadir los recursos materiales de los que dispone la empresa para que se pueda realizar su inventario y gestión, este seguimiento puede realizarse a través del TAB Infraestructura. Igualmente dentro del nuevo TAB RECURSOS, hemos separado la estructura de cargos de tal modo que por un lado se refleje la estructura real de la empresa y por otro la estructura interna de KMKey, simplificando por tanto la organización de la estructura de la empresa.

Las funcionalidades que aparecen como novedad en este sprint destaca la opción de añadir registros, que nos permite definir los resultados de recogida de datos mediante una plantilla que se define en la propia aplicación. Por ejemplo: la temperatura de una nevera, el ph del cloro, la inspección visual de un alimento o quién ha limpiado los lavabos y cuando. Para ello el usuario se construye la plantilla a través de una tabla con diversos campos lo que permite ir introduciendo la información que puede ser: numerica, texto, fecha etc..

Para concluir, un avance del próximo sprint en el que vamos a centrarnos en mejorar los objetivos, los indicadores y los riesgos, es decir la parte de la aplicación relacionada con Seguimiento, centrándonos en mejorar la usuabilidad y aplicar las sugerencias que nos habéis hecho llegar.

Como simpre esperamos vuestros comentarios. Gracias por confiar en KMKey,

El equipo de desarrollo de KMKey.
Leer más...
viernes, 11 de julio de 2014

Cambios del sprint Klau Mejora

0 comentarios
 
En este sprint hemos abordado algunos cambios principalmente en el comportamiento de las No Conformidades aunque no son los únicos que hemos realizado, a continuación os detallo los cambios más significativos.

1. Las No Conformidades Reales no necesitan tareas para continuar el flujo, es decir, que aunque no tengan tareas asociadas podrán ser revisadas, verificadas y cerradas.

2. En las No Conformidades Potenciales, el campo necesita acciones obligatoriamente será sí. Esto es así para evitar que una No Confomidad potencial se quede sin posibilidad de continuar su flujo. Recordemos que se gestionan desde las Acciones Preventivas que tiene asociadas.

3. Se ha incluído la posibilidad de reflejar que la no Conformidad se ha detectado por una persona externa a la organización y el nombre de la persona que la ha detectado.

4. Las No Conformidades potenciales, fuerzan a que se requieran acciones complemetarias, y ay no permiten la selección de un Revisor. Recordemos que este tipo de No Conformidades se cierran desde las Acciones Preventivas vinculadas y que no reuqieren Revisión ni verificación.

5. En las acciones Correctivas y Preventivas se ha añadido un campo para informar si la acción fue eficaz o no.

6. Los usuarios que pueden intervenir en el flujo de las No Conformidades, las Acciones Preventivas y las Acciones Correctivas se gestionan a través de sus respectivos grupos.

7. En los Documentos los usuarios con rol de Revisor o Aprobador, no pueden realizar más que la revisión o la aprobación del documento, es decir, no pueden ni añadir contenidos ni modificar las carpetas. Únicamente pueden hacerlo los usuarios con rol de Editor o los propietarios, que habitualmente serán los responsables de calidad o los técnicos de calidad.

Esperamos que los cambios sean de vuestro interés y como siempre, esperamos que nos ayudéis a mejorar aportándonos vuestras opiniones y sugerencias.

Saludos,

El equipo de desarrollo de KMKey

Leer más...
jueves, 26 de junio de 2014

Permisos específicos en una carpeta

0 comentarios
 
Partimos del supuesto en el que tenemos una estructura de carpetas de documentos y queremos que un usuario pueda actuar como editor en uno de los subniveles, pero que no pueda ver los contenidos ni de otros subniveles ni de ninguna otra carpeta.

Por ejemplo, supongamos la siguiente estructura

  • Prueba permisos
    • Nivel 1
      • Nivel 2.1
        • Nivel 3.2.1 ISO
        • Nivel 3.2.2 NO ISO
      • Nivel 2.2 ISO
      • Nivel 2.3 No ISO

Queremos que Laura pueda actuar como 'Editor' en la carpeta 'Nivel 3.2.1 ISO', para ello damos permisos 'Editor' a Laura en la carpeta. Automáticamente se otorgan permisos en las carpetas superiores para que Laura pueda acceder a las subcarpetas, pero que no pueda ver los contenidos. El permiso que se otorga es 'Acceso al proyecto'.

Pero qué ocurre si queremos que Laura vuelva a la situación anterior, es decir, que no pueda actuar como 'Editor' en la carpeta "Nivel 3.2.1 ISO". Lo que tenemos que hacer en este caso es quitar a Laura el permiso de "Editor" en la carpeta y dejará de verla al igual que sus contenidos. Sin embargo, los permisos de "Acceso al proyecto" en el resto de niveles se mantienen, y ello es así porque no se puede saber si esos permisos fueron concedidos por ser nombrada "Editor" en esa carpeta o en algún otro subnivel de la estructura, o por alguna otra razón, por lo que si queremos que deje de ver completamente la estructura, debemos retirar el permiso de "Acceso al proyecto" en el resto de carpetas superiores. También podemos quitar el permiso únicamente en la carpeta raiz, en nuestro ejemplo "Nivel 1", de este modo al no ver esa carpeta tampoco verá los distintos subniveles. Esta última solución no es la recomendada, porque se podría acceder a la estructura, nunca a los contenidos, pero puede servir en aquellos casos en los que la estructura es muy grande y no merece la pena recorrerse todos los niveles para retirar el permiso.

Espero que os sea de utilidad.
Leer más...
miércoles, 19 de marzo de 2014

Aproximación a HSE desde Colombia

1 comentarios
 
video

De todos es sabido que con la configuración KMKey Quality Basic correctamente personalizada se puede gestionar las normas ISO 9001, ISO 14001 y OHSAS 18001. También las diferentes nomenclaturas, especificidades, adaptaciones por sector o país. En este caso el Asesor especializado Jorge Davila de Colombia, nos comparte este video donde ha hecho una primera adaptación para  H.S.E.Q (Salud, Seguridad, Medio Ambiente, Calidad) según su enfoque.
Interesante adaptación. Jorge nos ha comentado que sigue experimentando y nos hará llegar nuevas posibilidades.
Gracias Jorge
Leer más...
viernes, 28 de febrero de 2014

Generar documentos automáticamente al crear expediente

0 comentarios
 
Hemos agregado un nuevo tag al procesamiento del XML en la creación de proyectos

Como ya sabéis, en la configuración de un patrón, podemos definir toda una estructura XML indicando qué objetos crear (tareas, ofertas, etc) permisos, accesos, objetos a copiar etc (http://kmkey-es.blogspot.com.es/2010/06/patrones-de-trabajo-avanzados.html)

Hemos agregado un nuevo tag 'generate' que nos permite generar directamente documentos a partir de las plantillas hechas en OO

De este modo, por ejemplo, al introducir todos los datos de un expediente en el momento de la creación, podemos hacer que genere automáticamente toda una serie de plantillas ya rellenadas con estos datos

La sintaxis del tag es muy simple:

acces docid="xxx" output_name="mi-documento.doc" output_format="doc"

donde docid es el getDocid de la plantilla a generar.

Como la generación de plantillas en otros puntos de KMKey, los formatos disponibles son doc, xls y pdf, y aquí podéis mirar los tags disponibles para crear estas plantillas : http://kmkey-es.blogspot.com.es/2009/06/plantillas-generables-asociadas-un.html

Leer más...
martes, 21 de enero de 2014

Listado Previsiones-Ofertas en KMKey Project

0 comentarios
 
Sorprendentemente hasta ahora nadie había echado en falta un listado de ofertas-previsiones en KMKey Project

Ahora, desde la pestaña Control --> Informes tenemos disponible el listado que nos ofrece un otput de todas las previsiones entradas, con el detalle de las líneas.

Leer más...
martes, 14 de enero de 2014

Versión inicial en Control de documentación

0 comentarios
 
Para establecer la versión inicial en la documentación controlada simplemente debemos actualizar los valores por defecto de los campos 'effective_revision' i 'initial_revision' a la versión que necesitamos, que generalmente es o 0 o 1

Leer más...
viernes, 11 de octubre de 2013

Informe de permisos por objetos

0 comentarios
 
A veces nos encontramos con la nesidad de analizar detalladamente todos los permisos establecidos en cada objeto

Para facilitarlo podemos ejecutar este script por zopectl debug, y obtener un archivo en formato csv con todos los perfiles por objeto:

site = app.kmkey
from AccessControl.SecurityManagement import newSecurityManager
from Testing.makerequest import makerequest
user = site.acl_users.getUser('manager').__of__(site.acl_users)
newSecurityManager({}, user)
app = makerequest(app)
site = app.kmkey
from Acquisition import aq_base, aq_acquire
context = site.workspaces.kmkey
cat = site.portal_catalog
km = site.workspaces.kmkey
db=site.db
catalog = km.portal_catalog

#Filtrar los objetos que nos  interese
brains = cat(path='/kmkey/workspaces/kmkey/etccc...', meta_type='KM Task',sort_on='relative_path')
len(brains)
obs=[]
i=0
for brain in brains:
  i=i+1
  obs.append(brain.getObject())
  if not i%10:
      i
      site._p_jar.sync()
      site._p_jar.cacheGC()

f=open('/tmp/informe.csv','w')
for ob in obs:
   dm = ob.getContent().getDataModel()
   txt =""""%s";"%s";"%s";"""%(len(ob.getPhysicalPath()),dm['Title'],dm['wbs'])
   roles = ob.get_local_roles()
   #Adaptar para incluir los permisos por grupo
   #groles = ob.get_local_group_roles()
   for item in roles:
       txt = txt + """"%s";"%s";"""%(item[0],' / '.join(item[1]))
   print txt
   f.write(txt+'\n')
f.close()
Leer más...
martes, 8 de octubre de 2013

Copias de seguridad en KMKey

0 comentarios
 
Mantener copias de seguridad es algo importante no sólo en entornos profesionales como servidores en los que esté instalado KMKey sino también una práctica muy prudente a título doméstico, pero a la que habitualmente damos poca prioridad, puesto que mientras no son necesarias resultan una carga algo molesta... pero si un día resultan necesarias y no disponemos de ellas, lamentaremos no haberlas realizado.

Antes de hablar de cómo realizarlas, es preciso indicar qué debe ser resguardado. En KMKey hay dos ubicaciones en las que se almacenan los datos de usuario: por un lado está la base de datos Postgres, en la que hay todos los patrones, expedientes, píldoras y demás, mientras que los documentos se almacenan en un diretorio física, por defecto bajo /var/zope/storages pero podría variar según la instalación.

En la instalación por defecto de KMKey hay un simple script auxiliar (KMKeyCore/utils/rsbackup.sh) que realiza una copia completa en cada ejecución de ambas ubicaciones, realizando un bolcado completo de la base de datos y un archivo contenedor de todos los documentos. Se recomienda encarecidamente su uso.

Sin embargo, con la popularización del KMKey Quality hemos detectado en algunas de las instalaciones que gestionamos un aumento muy significativo del volumen de documentos, debido a la propia vida de los ciclos documentales, lo que a su vez ha repercutido en un crecimiento muy significativo del volumen de las copias de seguridad. Si mantenemos varias copias de seguridad simultáneamente, algo por su parte recomendable, las necesidades de espacio aumentan exponencialmente, lo cual puede resultar inconveniente tanto por el coste de almacenamiento como el de transmisión externa. Además nos hemos percatado que en la mayoría de los casos la proporción de documentos modificados en relación al total de los existentes es reducida, siendo la operación más habitual la de inclusión de nuevo material.

Es por ello que para estos casos sugerimos una aproximación distinta a la estrategia de copias completas cada vez, usando para ello copias incrementales: en ellas realizamos una primera copia completa y seguidamente sólo registramos las diferencias. De este modo nos evitamos almacenar múltiples copias de documentos completamente idénticos.

Para ello usaremos una característica del comando `tar': --listed-incremental. Con ella crearemos dos ficheros: el almacén de documentación similar al habitual más un fichero índice que registra el estado de los ficheros archivados. Mientras usemos este fichero índice especial, las posteriores copias de seguridad incluirán únicamente las diferencias respecto la anterior. La contrapartida importante a tener en cuenta es que para restaurar una copia hasta el estado de una fecha en particular, serán necesarias todos los archivos desde la primera completa hasta la última parcial, incluyendo todas las intermedias.

Pongamos ejemplos: un proceso de copia de seguridad habitual consiste en:

$ tar --create --gzip --file /mnt/backup/kmkey_files.tar.gz /var/zope/storages/kmkey/files
$ tar -czf /mnt/backup/kmkey_files.tar.gz /var/zope/storages/kmkey/files

(los dos comandos son idénticos)

Para convertirlo a un proceso incremental, basta con añadir la opción --listed-incremental (o su versión abreviada, -g) y la ruta al fichero de índice:

$ tar --create --gzip --file /mnt/backup/kmkey_files.tar.gz --listed-incremental /mnt/backup/kmkey_files.tar.incr /var/zope/storages/kmkey/files
$ tar -czf /mnt/backup/kmkey_files.tar.gz -g /mnt/backup/kmkey_files.tar.incr /var/zope/storages/kmkey/files


Si el fichero /mnt/backup/kmkey_files.tar.incr no existe, se creará mientras se realiza una copia completa, mientras que si existe de una ejecución anterior, lo actualizará y el tar que creará contendrá únicamente las diferencias desde la última ejecución. Debemos también tener la precaución de dar un nombre adecuado a cada fichero tar y sobretodo que sean distintos para evitar sobreescribir una copia anterior.


Para la restauración, simplemente sustituiremos --create por --extract (o -c por -x en su forma abreviada), ejecutándolo sobre cada fichero .tar por orden, empezando por la copia completa. Esto además nos permite ir avanzando copia por copia en caso que deseemos restaurar en un punto intermedio: mientras respetemos el orden, podemos detenernos en cualquier momento que la copia será fiel al instante en que se creó la última incremental que hayamos extraído.


Es recomendable generar de vez en cuando una copia completa para reducir el número de incrementales que hay que mantener controlados. Una posibilidad puede ser generar una completa durante el fin de semana, asumiendo una menor carga del servidor ese día, y diarias incrementales. Bastará con eliminar o renombrar el fichero de índice, al que le hemos puesto la extensión .incr, justo antes de lanzar el proceso que deba realizar la copia para que la realize completa en lugar de incremental.

Por lo que se refiere a la base de datos, realizar una copia incremental es algo más complejo si hay que analizar las diferencias entre volcados. Es por ello que, en caso de considerarse necesarias, remitimos al lector a la documentación oficial de Postgres.

En una próxima versión de KMKey modificaremos el script para que sea compatible con el método incremental de copia de seguridad de documentos.
Leer más...
lunes, 7 de octubre de 2013

Ventajas del enfoque a procesos

1 comentarios
 
Respondemos la pregunta de Oliver: Buenas noches, He estado haciendo una investigación acerca de la herramienta de KMKey Quality, y he visto que se le da seguimiento a los procesos de la cadena de valor de una organización. Quisiera saber su punto de vista de este aspecto de la herramienta, ¿Cuales son los aspectos más relevantes de la herramienta, en el aporte a la gestión de la calidad de la cadena de valor? ¿Qué ofrece diferente con respecto a otras herramientas en la misma área? Agradecería mucho la respuesta a este correo. Muchas gracias,

Hola Oliver: El aspecto mas relevante de KMKey Quality es que permite automatizar en un entorno colaborativo de trabajo vía Internet el Sistema de Gestión de Calidad de una empresa u organización. El diseño de éste es responsabilidad del departamento de Calidad. KMKey principalmente facilta el trabajo diario para mantenerlo. El hecho que esté enfocado a procesos, permite aislar y localizar la información relativa a cada uno de ellos de forma sencilla, facilitando así la gestión. Este mapa, obviamente, es configurable de forma automática y cada empresa puede disponer del suyo propio. A partir del mapa podemos filtrar el proceso con el que queremos trabajar. Espero que la respuesta satisfazca tus expectativas. Salut Joan


Leer más...