Tareas #1876

Errores #1860: Corrección de varios errores

Identificador de material inventariable

Añadido por Marc Bria hace alrededor de 13 años. Actualizado hace más de 12 años.

Estado:Cerrada Fecha de inicio:14/12/2011
Prioridad:Urgente Fecha fin:28/03/2012
Asignado a:Luis Alonzo Fulchi % Realizado:

100%
Categoría:-
Versión prevista:- Tiempo estimado:6.00 horas

Descripción

El material inventariable usa por nombre un código de 13 caracteres que se extrae del Catálogo.

Se automatiza la creación del ID (Título de nodo) mediante el módulo "autotitle" y "token".

Autotitle permite construir el título de un nodo de forma automática y si se dispone de token, se pueden emplear estos para la creación del título.

El parche al módulo "token" para extraer sinónimo y/o la descripción (y de ese modo construir el ID con los códigos en vez de los literales...) es obsoleto y supuestamente incorporado a la versión estable, pero no resuelve el problema.

Se opta por un Title automático y oculto (sintaxis MAT-nid) y se crea un cck "computed_field" con php para incluir el código que solicita la facultad.
(o programar el autotitle con php).

Peticiones relacionadas

relacionada con Inventario - Tareas #2141: Elementos sin clasificar Cerrada 09/02/2012 28/03/2012
relacionada con Inventario - Errores #2701: Nombre no se construye correctamente Cerrada 27/03/2012 27/03/2012
relacionada con Inventario - Tareas #2725: Llamar a Marc por identificador Cerrada 28/03/2012 29/03/2012

Histórico

#1
Actualizado por Marc Bria hace alrededor de 13 años

  • % Realizado cambiado 0 por 50
  • Tiempo estimado establecido a 2.00

Tras revisar opciones, la solución más limpia consiste en usar PHP en el autotítulo del nodo.

El código resultante es tan simple como:

 1<?php
 2        $termSyn=array();
 3        $vid=5; //Taxonomía con el Catálogo
 4
 5        $getTerms = $node->taxonomy[5]; //Términos en jerarquizados (orden inverso).
 6
 7        foreach($getTerms as $tid) {
 8            $syn = taxonomy_get_synonyms($tid);  //ver: Drupal Api [1]
 9            $termSyn[] = $syn[0];
10        }
11
12        $termSynRev = array_reverse($termSyn);
13
14        //return (var_export ($termSynRev, true));
15        return implode('-' , $termSynRev);
16?>

Se detectan dos problemas imprevistos:

  1. La taxonomía del catálogo no se almacena: Probablemente debido a una mala configuración del módulo taxonomy_manager.
  2. El código incluye 4 dígitos finales para cada objeto: Supongamos que existen dos "cargadores de pilas". El primero tendría código 0001 y el segundo 0002. Cabe esperar que el sistema incluya estos últimos dígitos automáticamente, por lo que habrá que revisar el código para que lance una consulta la base de datos y añada el número que corresponda.

Sigo con el tema esta noche para que mañana Fio por fin pueda ponerse a introducir datos y hacer una prueba real del sistema.

[1]: http://api.drupal.org/api/drupal/modules--taxonomy--taxonomy.module/function/taxonomy_get_synonyms/6

#2
Actualizado por Marc Bria hace alrededor de 13 años

  • Fecha fin establecido a 22/12/2011
  • Estado cambiado En curso por Resuelta
  • % Realizado cambiado 50 por 100
  • Tiempo estimado cambiado 2.00 por 6.00

El problema 1 es resultando de un bug endémico de content_taxonomy cuando se combina con hierarchical_select (HS): Cuando se almacena el "lineage" (o sea, toda la jerarquía de términos y no sólo el término hoja) y se actualiza un nodo, HS no es capaz de cargar el término hoja y hay que volver a introducir la taxonomía.

El desarrollador de HS dice que no va a corregir más bugs en relación con content_taxonomy así que se cambia de aproximación:
  1. No se almacena el "lineage" (sólo el tid de la última hoja)
  2. Se obtienen los términos padre mediante la función http://api.drupal.org/api/drupal/modules--taxonomy--taxonomy.module/function/taxonomy_get_parents_all/6
Sobre el problema 2, tras pensar en ello se llega a la conclusión de que es complicado gestionar el "número de secuencia" de forma automática, así que se opta por:
  1. Crear un campo específico con el número de secuencia
  2. Mostrar el número de elementos mientras se escoge el término del catálogo.
  3. Proponer un valor en ese campo.

El código resultante para el auto título es:

 1<?php
 2        $termDesc=array();    //Almacena los términos asociados (Description).
 3
 4        $tid=$node->field_catalogo[0]['value'];      // El identificador del término.
 5        $getTerms = taxonomy_get_parents_all($tid);  // Sus padres.
 6
 7        foreach($getTerms as $term) {
 8            $termDesc[] = $term->description;
 9        }
10
11        $termDescRev = array_reverse($termDesc);
12
13        $count = '[field_sequence-formatted]';
14        $codigo = implode('-' , $termDescRev).'-'.sprintf("%04d",$count);
15
16        //DEBUG: return (var_export ($termDescRev, true));
17
18        return $codigo;
19?>

Con todo ello, la tarea se da por finalizada y YA ES POSIBLE UTILIZAR LA APLICACIÓN para introducir los primeros datos reales (prueba piloto).

Se limpia completamente la BD para el piloto.

Se espera feedback.

#3
Actualizado por Luis Alonzo Fulchi hace casi 14 años

  • Estado cambiado Resuelta por Cerrada

Ale, te animás a revisar esto?

Ya estaría funcional el inventario. Quizás el lunes se pueda empezar a cargar. Cierro la tarea. Cualquier cosa abrimos nuevas.

#4
Actualizado por Alejandro Maiche hace casi 14 años

ok. solo falta qwue fiorella introduzca datos y lo pruebe...
yo ya mande el texto pa el home!

#5
Actualizado por Luis Alonzo Fulchi hace casi 14 años

No encuentro el texto que decís, ni acá: #1871, ni en portada.

#6
Actualizado por Marc Bria hace casi 13 años

El código de secuencia es complicado de gestionar pues al crear un nodo, todavía no se sabe que término del catálogo se le va a vincular, por lo tanto no se puede deducir la secuencia... y al editar el nodo, este código no debe variar.

Por ello, para el piloto, se opta por dejar el código secuencia en manos del "funcionario" y activar los contadores de términos para dar indicadores que permitan incluir el número correlativo.

Dicho de otro modo, parece que lo natural es que sea un código que añade manualmente el "funcionario" a su gusto y antojo (validando que sea entre 0 y 9999).

#7
Actualizado por Luis Alonzo Fulchi hace casi 13 años

  • Estado cambiado Cerrada por Comentarios

No entiendo. Entonces el código no se autogenera, sino que es el funcionario que agrega un código? y si repite le avisa? y cómo sabe cuál fue el último? Quizás estoy un poco mareado con esto.

#8
Actualizado por Marc Bria hace casi 13 años

Es para marearse, pues con el tema hemos dado ya 3 vueltas. :-)
Pero me atrevería a decir que con lo que tenemos ahora ya está resuelto.

Vamos por partes:

El código se auto genera en base al catálogo (lo he probado bastante y funciona bien) y un número correlativo (número secuencia de artículo).

De los 13 dígitos los últimos 4 son es una secuencia (imagina que se compran 2 impresoras idénticas... pues serían xxx-0001 y xxx-0002). El tema es que el sistema no puede saber el número de secuencia, así que pone 1 y espera a que el funcionario corrija (en base al número que indica el selector del catálogo que si que avisa del número de elementos existentes).

Si quieres un día hacemos un skype y te explico compartiendo pantalla. sip?

En resumen: El catálogo está resuelto, pero dedicar tiempo a un automatismo (ajax, javascript...) para el código de secuencia me parece excesivo.

En cualquier caso, si se considera imprescindible le echo un ojo.

Lo que si que podría estar bien es detectar códigos idénticos, por si el funcionario se despista con la secuencia.

#9
Actualizado por Marc Bria hace casi 13 años

La tarea está finalizada, pero faltan comentarios y tomar una decisión sobre el catálogo para cerrar del todo.

Duda Importante: ¿Qué hacemos con los objetos que no tienen los 3 elementos (FAMILIA-SUBFAMILIA-ELEMENTO-Secuencia)? El código que se genera es "parcial" y queda... raro. Pe: INF-MON--0001

(Pondría un ejemplo real, pero ahora mismo desde la UAB no se ve la web)

Propongo que se complete la taxonomía para que SIEMPRE se tengan 4 elementos y forzar a que se escoja una "hoja".

#10
Actualizado por Luis Alonzo Fulchi hace casi 13 años

  • Asignado a cambiado Marc Bria por Alejandro Maiche

Propongo lo decida Ale, ya que no veo que haya feedback de otro lado de la institución

#11
Actualizado por Luis Alonzo Fulchi hace más de 12 años

  • Asignado a cambiado Alejandro Maiche por Marc Bria
  • % Realizado cambiado 100 por 80

Ale, ya que no moviste esta tarea, la voy a mover un poco yo y se la paso a Marc con una pregunta.

Además apareció otro problema #2701 que me impulsa a proponer lo siguiente:
  • que la URL se construya a partir de un ID único, numérico y secuencual de 1 hasta n

#12
Actualizado por Marc Bria hace más de 12 años

Respondo aquí a este hilo, pero también al #2701 pues ambos están estrechamente relacionados.

Como dijo el amigo "Jack", vayamos por partes :-)
Un poco más de info antes de tomar la decisión:

  1. Los objetos tienen 2 urls: La dirección que le asigna el sistema (pe: http://inventario.psico.edu.uy/es/node/220) y el alias que le asignamos (pe: http://inventario.psico.edu.uy/es/material/inf-ins-0001-1)
  2. Se asignó un alias para permitir acceder a un objeto directamente con el código del mismo (http://inventario.psico.edu.uy/es/material/<código-objeto>) pudiendo prescindir así del QR en los casos en los que el código estuviese dañado, no se dispusiera de lector, etc.
  3. Los códigos QR "apuntan" a la URL del sistema (pe: node/220) en vez de apuntar al alias (pe: material/inf-ins-0001-1).
Así pues:
  • No modificaría los alias que incluyen el código pues ofrecen una funcionalidad extra.
  • Si se han generados alias incorrectos (al no disponer de la descripción de la taxonomía), corregiría la taxonomía (ver Taxonomy Manager) y luego regeneraría todos los alias de material del sistema. Este cambio en los alias no supondrá un problema para su correcto funcionamiento de la aplicación, ya que los códigos QR no usan estos alias.
  • Insisto: en el sistema no puede inventarse un funcionamiento para un caso que NO debería existir (en base a la codificación definida TODOS los objetos HAN DE tener FAMILIA-SUBFAMILIA-ELEMENTO, así pues, cualquier elemento del catálogo debe tener siempre estos 3 niveles o es imposible para el sistema o para un ser humano definir un código coherente con lo establecido).

¿Cómo lo ven?

#13
Actualizado por Luis Alonzo Fulchi hace más de 12 años

  • % Realizado cambiado 80 por 90

Muy bien ! Excelente Marc, así que parece que el confundido era yo entonces.

Solucionaremos lo de las hojas y las clasificaciones.

#14
Actualizado por Luis Alonzo Fulchi hace más de 12 años

  • Asignado a cambiado Marc Bria por Luis Alonzo Fulchi

Me paso la tarea de implementar la obligatoriedad de las hojas.

#15
Actualizado por Luis Alonzo Fulchi hace más de 12 años

  • Fecha fin cambiado 22/12/2011 por 28/03/2012
  • Estado cambiado Comentarios por Cerrada
  • % Realizado cambiado 90 por 100

Obligué a que se elija el último nivel. Habrá que crear siempre 3 niveles.

Exportar a: Atom PDF