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