lunes, 13 de diciembre de 2010

Vídeos en Inglés

0 comentarios
 
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
Leer más...
martes, 5 de octubre de 2010

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

0 comentarios
 

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.

Leer más...
martes, 29 de junio de 2010

Enlazar datos de KMKey desde aplicaciones externas

1 comentarios
 
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
Leer más...
lunes, 14 de junio de 2010

Patrones de trabajo avanzados

0 comentarios
 

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


<task otros_atributos blocked_roles="role1,role2,roleN" />
<task otros_atributos non_blocked_roles="role1,role2,roleN" />

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


<access usernames="username1,username2" roles="role1,role2"/>

<access groups="41718292,4343413" roles="role1,role2"/>

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 atributos_de_la_tarea>

<access usernames="username1,username2" roles="role1,role2"/>

<access groups="41718292,4343413" roles="role1,role2"/>

</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" ?>

<objects xmlns:tal="http://xml.zope.org/namespaces/tal">

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

<task Title="Propuesta de Producto" planned_end="reference_date+120"
planned_start="reference_date+0" portal_type="kmkey_patron_tarea"
responsible="role:director_tecnologico" task_id="51" wbs="1"/>

<task Title="Diseño Preliminar" planned_end="reference_date+221" planned_start="reference_date+80" responsible="role:jefe_diseno" task_id="52" wbs="2"/>

</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" ?>

<objects xmlns:tal="http://xml.zope.org/namespaces/tal" tal:define="project python:here['getKMProject'](here)">

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


<task task_id="1" Title="Proyecto + Geotécnico + Control de Materiales" responsible="role:tecnico-de-obra-oct" planned_hours="56" planned_start="parent['planned_start']-15"planned_end="parent['planned_start']-9" tal:condition="python:'Estabilidad' in project['categories']" />

</objects>


Leer más...
viernes, 11 de junio de 2010

Subir el IVA en KMKey

0 comentarios
 
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)
Leer más...
jueves, 10 de junio de 2010

Ordenar menús y filtros

0 comentarios
 
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)
Leer más...
jueves, 13 de mayo de 2010

Sistema de backups con xdelta

2 comentarios
 
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 ?
Leer más...
miércoles, 5 de mayo de 2010

Widgets para mapas en KMKey

0 comentarios
 
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 ?
Leer más...
jueves, 29 de abril de 2010

Soporte para IMAP y servidores con SSL

0 comentarios
 
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.
Leer más...
viernes, 26 de marzo de 2010

Single Sign On (SSO) con KMKey

6 comentarios
 
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
Leer más...
martes, 23 de marzo de 2010

KMKey y el proceso de cuestionarios EFQM

0 comentarios
 
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.
Leer más...
viernes, 5 de marzo de 2010

Implantación de KMKey subvencionada

0 comentarios
 
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
Leer más...
miércoles, 3 de marzo de 2010

Alcanzar objetivos con KMKey

0 comentarios
 
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.
Leer más...
jueves, 28 de enero de 2010

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

0 comentarios
 
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
Leer más...
martes, 26 de enero de 2010

Gestión de Recursos. Pasado, presente y futuro

1 comentarios
 

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.


Leer más...
martes, 19 de enero de 2010

Ruta hacia KMKey Zapata. Mas revolución!!

5 comentarios
 
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!!!"
Leer más...
lunes, 18 de enero de 2010

Vocabularios / Select Box dinámicos

0 comentarios
 
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 '#'
Leer más...
viernes, 8 de enero de 2010

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

0 comentarios
 
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
Leer más...
jueves, 7 de enero de 2010

Activar módulos en KMKey

2 comentarios
 
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
Leer más...