lunes, 28 de diciembre de 2009

Configurar Seleccionable / Autocomplete de Grupos / Empresas o Contactos

0 comentarios
 
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


Leer más...
miércoles, 23 de diciembre de 2009

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

0 comentarios
 
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()
Leer más...
lunes, 14 de diciembre de 2009

Cómo seguir la evolución de KMKey ?

0 comentarios
 
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 !!
Leer más...
jueves, 3 de diciembre de 2009

Liberado KMKey 3 versión Makhno

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

Quieres colaborar con KMKey ?

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

Como instalarse KMKey Makhno

51 comentarios
 
En primer lugar, dejar claro que KMKey requiere un servidor web con Zope 2.9.4, python 2.4 y sistema operativo GNU/Linux, preferentemente Debian. Aunque algunas partes pueden llegar a funcionar sobre Windows, no se soporta este sistema operativo 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 Joinup , Necesitais tener Linux y Zope2.9.4 A partir de ahí, descomprimir los fuentes en el directorio Products de Zope, y seguir las instrucciones de KMKeyCore/doc/INSTALL. El site que se necesita también lo podeis descargar del mismo sitio, viene preconfigurado con patrones de gestión de calidad, su usuario administrador es "adminkmkey", y su clave "demokm"

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

Espero que lo disfruteis


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
Leer más...
jueves, 12 de noviembre de 2009

Cómo distinguir el Software del Humo

0 comentarios
 
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.
Leer más...
miércoles, 4 de noviembre de 2009

Guía de Instalación de KMKey

27 comentarios
 
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://joinup.ec.europa.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
Leer más...
viernes, 16 de octubre de 2009

La seguridad en KMKey Makhno

0 comentarios
 
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.
Leer más...
viernes, 2 de octubre de 2009

ZOORRA sin servidor gráfico

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

Avanzando hacia KMKey Makhno

0 comentarios
 
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)
Leer más...
miércoles, 30 de septiembre de 2009

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

1 comentarios
 
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:
Leer más...
lunes, 28 de septiembre de 2009

Posibilidades multiempresa de KMKey

0 comentarios
 
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:

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

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

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

Leer más...
viernes, 18 de septiembre de 2009

Permisos de acceso a opciones de menú

0 comentarios
 
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.
Leer más...
martes, 1 de septiembre de 2009

Demos KMKey disponibles. Condiciones de uso

2 comentarios
 
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/ejemplo/
http://quality.kmkey.com/ejemplo/
http://helpdesk.kmkey.com/ejemplo/


Donde "Ejemplo" 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/ejemplo/
Donde X es un número del 1 al 5 dependiendo del servidor donde sea alojada y "Ejemplo" 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.
Leer más...
miércoles, 26 de agosto de 2009

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

1 comentarios
 
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:
Leer más...
lunes, 27 de julio de 2009

Vínculos e Imágenes

0 comentarios
 
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..).

Leer más...
viernes, 24 de julio de 2009

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

0 comentarios
 
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/
Leer más...
jueves, 23 de julio de 2009

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

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

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

0 comentarios
 
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.
Leer más...
miércoles, 22 de julio de 2009

Alta de expedientes y filtros.

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

Configuración avanzada de índices postgresql

3 comentarios
 
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%');
Leer más...
viernes, 3 de julio de 2009

Pequeña ayudita para informes y listados

0 comentarios
 
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
Leer más...
jueves, 2 de julio de 2009

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

0 comentarios
 
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.
Leer más...
lunes, 22 de junio de 2009

Como indexar un campo

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

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

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

Encodings al editar usando ZMI

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

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

Configuración opciones KMKey

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

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


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


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

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

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


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

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

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

Documentos en el sistema de ficheros

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

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

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

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

0 comentarios
 






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

Plantillas Generables asociadas a un patrón

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

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

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

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


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


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

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

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

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

Ejemplo de plantilla generable sobre un expediente :

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

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

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

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


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

Las instrucciones son bastante intuitivas:

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

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

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

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

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

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

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

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

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

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

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

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

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

LUPA

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

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

Usando OpenOffice para hacer listados (I)

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

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

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

Activando el sistema de e-mails

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

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

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

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