Cambios locales en una instalación de Catalis

Definición: En general, todo aquello que se modifica o añade a Catalis para adaptarlo al uso local, y que debería ser preservado cada vez que se produzca una actualización de la aplicación.

Podemos organizar estos datos en las siguientes categorías:

• Opciones de configuración (settings). Pueden vivir en uno o más archivos (.ini, .conf, etc). ¿También en una base SQLite?

• Datos que sólo existen en forma local (aparte de los dummy que incluyamos en la distribución)
  • Bases MARC (bibliográficas, autoridad, existencias, todas ellas en ISIS), más sus metadatos (en SQL)
  • Usuarios, instituciones (en SQL)
  • Archivos “subidos” por los usuarios (carpeta upload). Se trata de archivos asociados a registros: imágenes (e.g. cubiertas de libros), pdf (e.g. resúmenes de tesis), etc.
  • Logs: del servidor y de la aplicación. Archivos de texto. Ver http://code.google.com/p/django-logging/

• Versiones locales de datos de uso general
  • Campos MARC de uso local, p. ej. los campos 9xx
  • Plantillas para registros MARC
  • Formatos de visualización, especialmente para listados de registros
  • Búsquedas preconfiguradas (e.g. para listados que deben generarse en forma periódica, DSI)
  • Reglas de indización locales (FST, STW, tablas).
  • Tipos de búsqueda.
  • Tipos de ordenación de listados.
  • Criterios para definir “tipos de documentos”
  • Modificaciones a registros importados
  • etc.

• Otros
  • Documentación (p.ej., políticas de catalogación locales) y mensajes de ayuda locales
  • Traducciones locales, de cualquier aspecto de la aplicación. Archivos .js/.po ?
  • Hojas de estilo locales (archivos .css + imágenes)
  • Código JavaScript (e.g. clases locales, archivos .js)
  • Código Python/Django (archivos .py)
  • Templates de Django
  • etc.

Se me ocurre que para cada uno de estos elementos “localizables” deberíamos especificar algunos parámetros, entre ellos: en qué tipo de archivo/formato se almacenará, mediante qué interfaz se podrá editar, y qué nivel de permisos deberá tener un usuario para que pueda editarlo.

A excepción del primer grupo de datos, tenemos que considerar estos dos aspectos:

1. el mecanismo para editar los datos
2. el mecanismo para preservar los datos luego de una actualización de la aplicación