DocDB

Documentación del módulo DocDB

Objetivo

Dolibarr ofrece una GED (gestión electrónica de documentos) integrada.
Estos documentos son descargados por los usuarios en el sistema de archivos del servidor. Algunos documentos son generados, como por ejemplo las facturas, las cuales también se almacenan en la GED.
Además, los datos de gestión están localizados en una base de datos. Aquí se encuentran todos los datos de los formularios: números de factura, nombres de clientes, montos, descripciones, etc.
El módulo docDB permite almacenar los documentos en la base de datos en lugar de utilizar el sistema de archivos del servidor.

Principio de funcionamiento

Dolibarr está codificado en lenguaje PHP. Este lenguaje proporciona al programador una variedad de funciones que le permiten conocer y actuar sobre el entorno del programa. Por ejemplo, la función echo muestra un texto en la pantalla del navegador, strpos devuelve la posición de una cadena de caracteres dentro de otra, y sort ordena una matriz de valores. Estas funciones son muy numerosas y abarcan casi todos los problemas a los que se enfrentan los desarrolladores.
El código PHP de una aplicación se encuentra en archivos, amenudo llamados scripts, que son utilizados por el servidor web en el momento exacto en que el usuario realiza una solicitud en su navegador. Sin entrar en demasiados detalles, el usuario hace clic o utiliza el teclado, el navegador envía una solicitud, el servidor analiza los scripts correspondientes y devuelve los resultados producidos por la ejecución de estos scripts.

En cuanto a los documentos GED, Dolibarr utiliza funciones dedicadas a la gestión de archivos. Algunas de estas funciones son opendir, readdir o readfile, que leen directorios o archivos en el disco del servidor, y también exif_read_data, imagejpeg o getimagesize, que trabajan con imágenes. Hay muchas otras funciones, y hasta el momento en que escribo estas líneas he contado 99.
Este sistema funciona bien, pero tiene varias limitaciones, entre ellas las de los sistemas de archivos utilizados para el almacenamiento. Estos sistemas no ofrecen la flexibilidad y potencia de las bases de datos para la conservación y acceso de documentos.
Por ejemplo, no es fácil implementar la replicación de un servidor a otro. La replicación permite mantener en tiempo real dos conjuntos de datos exactamente idénticos, lo cual es una ventaja importante para la seguridad y facilita las copias de seguridad periódicas. No utilizarla en la actualidad implica funcionar en un modo cada vez más obsoleto, que consiste en tolerar la pérdida de una cierta cantidad de datos en caso de un accidente en un servidor.
Tampoco es muy sencillo desplegar y mantener dos sistemas de gestión de datos diferentes. Hablamos de los documentos en el sistema de archivos por un lado, y de los datos de gestión en la base de datos por otro. Un error, un incidente o una operación desafortunada y no necesariamente consciente en uno de los dos sistemas puede provocar la falta de sincronización de los datos. Una vez más, esto funciona, pero no fue fácil de desarrollar y no sería fácil de actualizar.
Por último, los juegos de caracteres no se tratan de la misma manera en ambos sistemas, lo que implica problemas y limitaciones en los nombres de los documentos.

Entonces, ¿por qué se codificó Dolibarr de esta manera? La respuesta podría atribuirse lógicamente a los desarrolladores originales, pero se puede suponer que en ese momento las bases de datos no gestionaban muy bien grandes volúmenes unitarios de datos. Estos se almacenan en lo que se llaman "blob", que no aparecieron muy temprano en la historia de las bases de datos, mientras que, por el contrario, los archivos grandes fueron un problema que se resolvió desde el principio en el diseño de los sistemas de archivos.

Esta idea es la que dio origen a docDB: el tratamiento de "blob" está bien desarrollado hoy en día, por lo que es ventajoso utilizarlo en Dolibarr.

No se ha considerado reescribir toda una parte importante de Dolibarr. En primer lugar, esto no dejaría elección a los técnicos encargados de la implementación. Además, tiene sentido probar docDB durante un período de tiempo lo suficientemente largo. Por último, porque sería mucho trabajo.
La solución implementada simplemente modifica las funciones PHP que se ocupan de la gestión de documentos y las reemplaza por funciones que producen resultados equivalentes a los programas, pero que en realidad hacen algo diferente. Por ejemplo, opendir se reemplaza por opendir_Bypass. Mientras que opendir abre un directorio en el disco, opendir_Bypass abre y lee una tabla de la base de datos. Esto se llama un emulador. Las funciones originales son emuladas por las funciones de emulación. Producen los mismos resultados, pero con un método subyacente totalmente diferente, y lo mismo se aplica a todas las funciones relacionadas con los documentos. Una terminología más moderna podría hablar de programación orientada a aspectos.
En términos concretos, una vez activado docDB, el directorio de documentos se vuelve casi completamente inútil. Solo contiene el registro de eventos de Dolibarr y el famoso install.lock, así como el subdirectorio api necesario para algunas operaciones. En cualquier caso, ya no almacena nada y los documentos pueden eliminarse. Ahora se almacenan en dos tablas (llx_doc_data y llx_doc_directory) y, por lo tanto, están naturalmente asociados a cualquier operación de producción relacionada con la base de datos.

Se activa docDB mediante dos scripts (docDBmigrateScripts.py y docDBmigrateFiles.py) que se utilizan una vez cada uno. El primero modifica el código de los scripts de Dolibarr y el segundo copia el directorio de documentos en la base de datos. Estas dos operaciones son reversibles, lo que permite probar y revertir si es necesario.
Los detalles del procedimiento se explican en el documento de instalación install-es_ES.html suministrado con el módulo. La operación es bastante sencilla y rápida para aquellos que tienen un mínimo de experiencia en la línea de comandos.

Limitaciones

En el estado actual, docDB impone algunas limitaciones, afortunadamente pocas.

La principal es que solo funciona con MySQL, es decir, MariaDB. Sería posible adaptarlo para PostgreSQL, pero estoy esperando que un usuario exprese esa necesidad. La implementación no es sencilla porque el principio de manejo de blobs en PostgreSQL es diferente al utilizado en MySQL/MariaDB. En resumen, no se puede almacenar blobs en cualquier tabla, se requiere un manejo diferente.

Además, existe un caso en el que el rendimiento es bastante pobre. Esto ocurre solo en Windows cuando el servidor está sobrecargado. Si la memoria está llena y el sistema comienza a paginar, la gestión de los documentos se vuelve muy lenta. En la práctica, esto no tiene mucha importancia, ya que todo el sistema se vuelve lento y, de todos modos, se requiere una acción correctiva para utilizar Dolibarr en condiciones aceptables. Me encontré con este caso durante las pruebas, ya que los servidores estaban instalados en máquinas virtuales con poca memoria. Cabe destacar que esto no ocurre en Linux.

En cuanto a las limitaciones menores, los directorios vacíos no se vuelven a crear después de una reversión de migración. Si migras a docDB y luego, después de eliminar los documentos en el disco, utilizas la opción --reverse para recrear los mismos documentos, solo se generarán los directorios que no estén vacíos. En realidad, esto no es importante, ya que Dolibarr puede crear un directorio cuando lo necesita, y esto no afectará su funcionamiento.

Y eso es todo. Todas las funciones de Dolibarr son accesibles de manera transparente, que es el objetivo buscado.

Diferencias

Sin embargo, existe una ligera diferencia de funcionamiento: cuando se solicita eliminar un directorio en el GED, Dolibarr solicita confirmación advirtiendo si hay documentos en ese directorio y señalando que serán destruidos. Pero si se confirma, la eliminación falla y luego se deben eliminar los contenidos uno por uno.
Si docDB está activado, la eliminación de toda la estructura de carpetas funciona después de la confirmación, por supuesto.

Ventajas y Desventajas

El hecho de activar docDB significa que solo tendrás que gestionar la parte técnica para aprovechar tu ERP favorito.
Cada vez que surge la cuestión de los datos, el técnico a cargo de la operación se ocupa de la base de datos y nada más. Personalmente, encuentro esto muy útil. Sucede durante la implementación y gestión de copias de seguridad y restauraciones. También ocurre al considerar aspectos de seguridad.
Esto reduce significativamente el tiempo dedicado y también el riesgo de error.

Además, se vuelve posible aprovechar al máximo algunas capacidades de la base de datos. Piensa, por ejemplo, en la replicación, que permite mantener simultáneamente varias copias idénticas de una misma base de datos. O en las copias de seguridad incrementales, que son más difíciles de realizar pero muy útiles para garantizar una seguridad máxima.

También está el aspecto transaccional. Cuando realizas una serie de consultas y actualizaciones en una base de datos SQL, estas se registran en lo que se llama una transacción. Esta transacción garantiza que todas esas consultas y actualizaciones se realicen de una vez o no se realicen en absoluto. En otras palabras, tu base de datos permanece coherente sin importar lo que suceda en caso de falla de un programa o hardware. En el caso estándar de Dolibarr, esto puede no ser completamente efectivo. Se pueden imaginar situaciones desagradables, como una copia de seguridad que no está completamente completa o un conjunto de datos que no está completamente sincronizado. En realidad, esto debería ocurrir muy raramente, pero la idea no es muy cómoda.

Finalmente, en lo que respecta al desarrollo de Dolibarr, se observa que es difícil programar operaciones masivas relacionadas con los documentos. No encajan en la lógica normal de programación de bases de datos, y cada vez se requiere una doble reflexión, lo que aumenta la cantidad de trabajo de programación y reduce inevitablemente la factibilidad de desarrollar nuevas funciones.

El interés del módulo docDB es permitir que los documentos se almacenen en la base de datos junto con el resto de los datos.
El manejo transaccional, la replicación, las copias de seguridad incrementales, todo esto se vuelve más fácil de lograr.

Sostenibilidad

Una vez que se activa DocDB, no es más que un solo script PHP. Utiliza funciones estándar que se encuentran en la documentación oficial de PHP. La licencia bajo la cual se distribuye permite hacer uso completo de él (ver más abajo: licencia).
Surge la pregunta sobre su evolución en caso de que aparezca una nueva función en Dolibarr que no esté gestionada en docDB.
No se puede descartar esta posibilidad, y en ese caso sería necesario extender docDB (consultar la guía de desarrollo a continuación: extender docDB). Yo me encargaría de ello, por supuesto, pero no soy eterno. Sin embargo, se puede afirmar con certeza que un software libre desarrollado por un solo programador desaparecido es más fácil de evolucionar que un software desarrollado por un equipo importante de una empresa que acaba de quebrar. Lo sabemos bien, nosotros, los usuarios de Dolibarr, y es una de las cosas que nos gusta de este software.
Además, los scripts de migración están escritos en el lenguaje Python (www.python.org), otro lenguaje de script ampliamente conocido y difundido, al menos tan importante como PHP. ¿Por qué se eligió Python? Simplemente por preferencia personal. Considero que es más práctico para realizar este tipo de operaciones. La cuestión de la evolución de Dolibarr está bastante desconectada del trabajo realizado por estos scripts, que no se utilizan en producción, sino solo cuando se realiza una migración, una operación que se planifica con antelación y nunca de manera inesperada y forzada. Además, también son accesibles y modificables de forma libre. Su funcionamiento es ciertamente más complejo que la parte en PHP, pero en general no es nada tan esotérico. Un gran número de programadores de diferentes orígenes sería capaz de mantener y modificar estos scripts.

Uso por parte de módulos de terceros

Si estás utilizando un módulo de Dolibarr que no está incluido en los módulos estándar, la primera consecuencia es que probablemente no ha sido probado con docDB, por lo que debes asegurarte de que todo funcione correctamente.
Aquí tienes un procedimiento posible que puedes seguir si te encuentras en esta situación:
- Instala un entorno de prueba. No se trata de probar directamente en producción. Si esa es tu idea, aprecio tu confianza, pero sinceramente, es mejor ser cauteloso... Este entorno se instala de manera habitual, incluyendo la migración de docDB, y debes asegurarte de inyectar tus datos en la base de datos, incluyendo los documentos.
- Instala tu módulo, preferiblemente en htdocs/custom.
- Utiliza el comando docDBmigrateScripts.py para migrar tu módulo. El comando solo verá las modificaciones a realizar en el módulo, ya que los scripts de Dolibarr ya habrán sido migrados. No dudes en utilizar la opción --dry-run en el primer intento para ver claramente lo que ocurrirá.
- Eso es todo lo que debes hacer.
Si tu módulo no gestiona documentos GED, es muy probable que no se vea afectado en absoluto. Y si gestiona directamente los documentos sin utilizar las funciones de Dolibarr, algunos de sus scripts serán modificados, pero es bastante improbable que encuentren un problema durante la ejecución.
No se puede garantizar nada, especialmente en informática. Si encuentras algún problema, no dudes en contactarme a través del formulario de contacto en el sitio www.apia-asso.fr.

Lista de módulos probados con Dolibarr

Los siguientes módulos han sido probados exitosamente. Si deseas que el tuyo aparezca en esta lista, utiliza el formulario de contacto en el sitio www.apia-asso.fr para enviarme su nombre, la versión probada, la fecha de prueba y tu nombre o alias para que los pueda incluir en la siguiente tabla.

Módulo Versión Fecha de prueba Nombre del probador
Scanner 17.0.0 15/05/2023 jmbc

Pruebas y mediciones realizadas

Las pruebas se llevaron a cabo con Dolibarr 17.0.0 el 15 de mayo de 2023.

Lista de operaciones incluidas en el protocolo:
- migración de docDB
- comparación de documentos iniciales/después de revertir
- agregar/eliminar logotipo
- caracteres acentuados en el nombre de un documento
- verificación de generación de facturas en PDF para clientes
- acceso a miniaturas de documentos
- acceso al documento completo
- almacenamiento de documentos de terceros
- recorte de documentos de terceros
- almacenamiento de documentos de proyectos
- espacio GED: creación de carpetas
- espacio GED: carga de archivos
- espacio GED: creación de subcarpetas
- espacio GED: eliminación de carpetas/subcarpetas
- espacio GED: renombrar carpetas/subcarpetas/carpetas con archivos
- espacio GED: renombrar archivo con acentos
- espacio GED: estructura de carpetas automática - desarrollo
- espacio GED: estructura de carpetas automática - vista previa
- espacio GED: estructura de carpetas automática - acceso a facturas de clientes
- espacio GED: estructura de carpetas automática - acceso a proyectos
- espacio GED: estructura de carpetas automática - acceso a terceros
- prueba adicional - creación de 10 clientes mediante API
- prueba adicional - creación de 100 facturas por cliente
- prueba adicional - descarga de 100 documentos por cliente
- acceso a documentos después de revertir

Condiciones de las pruebas

Cuatro máquinas virtuales, dos con docDB (Linux y Windows), dos con Dolibarr nativo sin docDB (Linux y Windows). Las pruebas se realizan simultáneamente en cada sistema.
Sistemas operativos utilizados: Linux Debian 11, Windows 10 Pro 1909
Base de datos: MariaDB 10.5.18 (Linux), MariaDB 11.1 x64 (Windows)
PHP: 7.4.33 (Linux y Windows)
Python: 3.9.2 (Linux), 3.11.3 (Windows)
Memoria RAM: 2GB (Linux), 4GB (Windows)

Comparación de rendimiento

No se observaron diferencias medibles entre los cuatro sistemas para cada una de las funciones probadas, excepto en la descarga de documentos con docDB, que lleva aproximadamente un diez por ciento más de tiempo de ejecución (once centésimas de segundo en lugar de diez).
Además, los sistemas Windows estaban saturados con la memoria disponible, lo que los hizo aproximadamente cinco a seis veces más lentos en la prueba de descarga masiva (generación de 1000 facturas, descarga de 1000 documentos con la API de Dolibarr). La diferencia fue más notable en la descarga bajo estas condiciones: aproximadamente cinco a siete segundos para generar una factura y descargar un documento con docDB, lo que representa aproximadamente el doble de tiempo que sin docDB.
La conclusión es que docDB es menos eficiente en un entorno de Windows saturado (esto no representa condiciones normales de operación).

Juegos de caracteres

El juego de caracteres probado es utf8, que parece ser el juego de caracteres estándar en Dolibarr.
No se realizaron pruebas para casos en los que la base de datos utiliza otro juego de caracteres (por ejemplo, iso-8859-1). Se desaconseja utilizar docDB sin realizar pruebas adicionales en estos casos.
Para conocer el juego de caracteres utilizado en la base de datos, se puede utilizar la consulta
select default_character_set_name from information_schema.schemata where schema_name = "nombre_base_dolibarr";
La respuesta debe ser utf8mb4 o utf8mb3.
Además, las tablas que contienen los datos binarios de los documentos utilizan un juego de caracteres y un ordenamiento diferente al utilizado de forma estándar en Dolibarr. La razón es que en los sistemas de archivos, los caracteres acentuados son diferentes de los caracteres equivalentes sin acento (É es diferente de E, à es diferente de a, etc.), mientras que en una consulta SQL se consideran equivalentes. Esto presenta un inconveniente para emular el comportamiento de los sistemas de archivos en una consulta SQL, por lo que docDB utiliza CHARSET=utf8 COLLATE=utf8_bin, lo que proporciona los resultados que necesita.

Referencia de comandos

Consulte la guía de instalación install-es_ES.html incluida con el módulo para obtener ejemplos de funcionamiento.

Comandos de migración

Estos comandos son útiles fuera de la operación normal, solo en casos de migración de las fuentes PHP y carga de documentos GED.

docDBmigrateScripts Linux: python3 docDBmigrateScripts.py --dolibarrDir=ruta_nombre [--reverse] [--dry-run]
Windows: py -X utf8 docDBmigrateScripts.py --dolibarrDir=ruta_nombre [--reverse] [--dry-run]

Modifica el contenido de los scripts en el directorio htdocs de Dolibarr para realizar el acceso a la base de datos.
Por ejemplo, una secuencia de instrucciones if (file_exists($file)) se transformará en if (file_exists_Bypass($file)). Este procesamiento se realiza en todos los scripts PHP, excepto aquellos que se copian desde la carpeta install/scriptFiles de docDB.
La opción --reverse restaura los scripts al estado original.
--dolibarrDir Ruta completa del directorio htdocs de Dolibarr.
Si Dolibarr está ubicado en /var/www/dolibarr, entonces --dolibarrDir= debe apuntar a /var/www/dolibarr/htdocs
--reverse Solicita restaurar los scripts PHP de Dolibarr a su estado original.
No se trata de una restauración a partir de archivos de respaldo, sino de una reversión de los scripts encontrados en el directorio.
--dry-run Solicita una prueba del procesamiento.
El algoritmo se sigue de manera exacta hasta el punto de modificación del elemento procesado, que finalmente no se lleva a cabo.
-X utf8 Windows. Indica a Python que el juego de caracteres utilizado en el script es utf8.

docDBmigrateFiles Linux: python3 docDBmigrateFiles.py --dolibarrDir=ruta_nombre [--reverse] [--dry-run]
Windows: py -X utf8 docDBmigrateFiles.py --dolibarrDir=ruta_nombre [--reverse] [--dry-run] [--phpdir=ruta_binarios_php]

Lee el contenido del directorio "documents" de Dolibarr y lo carga en la base de datos. La ruta del directorio se conoce a través de la variable $dolibarr_main_data_root en el archivo de configuración de Dolibarr (htdocs/conf/conf.php). Este archivo también proporciona los parámetros de acceso a la base de datos.
Si se indica un archivo como faltante, se debe corregir ya sea en la base de datos (tabla llx_ecm_files) o en la carpeta donde falta el archivo. Es preferible realizar la corrección para evitar problemas posteriores durante la operación. Por ejemplo, se puede utilizar una consulta SQL como delete from llx_ecm_files where filename like '%missing_file_name%'; para eliminar la referencia a un documento que ya no existe. En este caso, primero verifique la seguridad de la consulta utilizando una consulta de selección como select filepath,filename from llx_ecm_files where filename like '%missing_file_name%'; para listar cualquier documento no relacionado que pueda eliminarse incorrectamente.
--dolibarrDir Ruta completa del directorio htdocs de Dolibarr.
Si Dolibarr está ubicado en /var/www/dolibarr, entonces --dolibarrDir= debe apuntar a /var/www/dolibarr/htdocs
--reverse Solicita la carga de los documentos GED desde la base de datos al directorio de documentos de Dolibarr.
--dry-run Solicita una prueba del procesamiento.
El algoritmo se sigue de manera exacta hasta el punto de modificación del elemento procesado, que no tiene lugar.
-X utf8 Windows. Indica a Python que el juego de caracteres utilizado en el script es utf8.
--phpdir Windows. Indica la ruta de acceso al ejecutable de PHP.
Esta opción es necesaria si esta ruta de acceso no está en el PATH de Windows. El acceso a PHP se utiliza para obtener ciertas características de los archivos de imagen que son leídos en tiempo real por Dolibarr y que no se almacenan en la base de datos. Por el contrario, docDB almacena estos datos en la base de datos para servirlos a Dolibarr cuando los solicita.

Consultas SQL

Estas consultas son útiles para probar y estudiar el comportamiento de Dolibarr y docDB.
Dado que son solo consultas, no representan ningún riesgo de destrucción de datos.

Consulta SQL Ejemplo de resultado Explicación
select * from llx_doc_directory; 
| rowid | path_name    |
|     1 |              |
|     2 | /adherent    |
|     3 | /adherent/1  |
|     4 | /adherent/10 |
|     5 | /adherent/11 |
La tabla docDB llx_doc_directory contiene la lista de directorios que se supone contienen los documentos.
select rowid,path_name,filemtime,
octet_length(datablob) as filesize,
octet_length(exif_data) as exif_data,
octet_length(imagesize) as imagesize
from llx_doc_data order by rowid;		 
| rowid | path_name                | filemtime           | filesize | exif_data | imagesize |
|     1 | /adherent/1/Jean.pdf     | 2023-01-27 21:36:39 |   153092 |         4 |         4 |
|     2 | /adherent/10/Jeanne.pdf  | 2023-01-27 21:36:39 |    44421 |         4 |         4 |
|     3 | /adherent/11/Léo.pdf     | 2023-01-30 09:56:36 |    16135 |         4 |         4 |
|     4 | /adherent/14/Charlie.pdf | 2023-01-30 09:56:18 |    25034 |         4 |         4 |
|     5 | /adherent/2/Arthur.pdf   | 2023-01-27 21:36:39 |    44844 |         4 |         4 |
La tabla docDB llx_doc_data contiene los documentos. La columna datablob no es visible. En su lugar, filesize indica el tamaño del documento. exif_data e imagesize son cadenas codificadas que contienen características de las imágenes, si las hay (están vacías en el caso de archivos PDF).
select filepath,filename from llx_ecm_files; 
| filepath    | filename     |
| adherent/1  | Jean.pdf     |
| adherent/10 | Jeanne.pdf   | 
| adherent/11 | Léo.pdf      |
| adherent/14 | Charlie.pdf  |
| adherent/2  | Arthur.pdf   |
La tabla Dolibarr llx_ecm_files contiene la lista de documentos y las rutas de acceso que se supone que los acceden.
select label from llx_ecm_directories; 
| label             |
| Documents annuels |
La tabla Dolibarr llx_ecm_directories contiene la lista de algunos directorios, aquellos que son creados por los usuarios en el espacio GED.

Ampliar docDB

Hemos explicado (Principio de funcionamiento) que Dolibarr utiliza funciones PHP dedicadas a la gestión de archivos.
Sin embargo, Dolibarr no utiliza todas las funciones relacionadas y, como resultado, no fue necesario emular todas estas funciones.
Tomemos, por ejemplo, el caso en el que Dolibarr desea verificar la existencia del documento PDF correspondiente a la factura FA2304-0001. Para hacer esto, utiliza la función file_exists, transformada por docDB en file_exists_Bypass, la cual realiza la consulta select rowid from llx_doc_data where path_name='/facture/FA2304-0001/FA2304-0001.pdf'. Si la consulta tiene éxito, es decir, si el documento existe en la tabla llx_doc_data, docDB devuelve el valor true.
Ahora imaginemos que Dolibarr quiere utilizar la función filectime para conocer la fecha de creación de un archivo. Esto sucede de vez en cuando, pero nunca para un documento. La correspondiente función de docDB filectime_Bypass simplemente llama a PHP y devuelve el resultado obtenido por PHP a Dolibarr.
Si en una versión futura Dolibarr utiliza PHP para obtener la fecha de creación de un documento, sería necesario implementar correctamente filectime_Bypass. Esto implicaría verificar si el archivo en cuestión es un documento (if ($useByPass && doc_in_db($filename))) y utilizar la consulta SQL adecuada en ese caso. Las funciones de docDB son relativamente simples y su uso y extensión están al alcance de un programador PHP con experiencia razonable.
Si desea conocer la lista de funciones emuladas, se encuentra en el script docDBmigrateScripts.py en la variable KEYWORDS_FOUND_16.
Las funciones no implementadas se enumeran en filebypass.php después del comentario The following functions are not used in the Dolibarr documents context.

Solución de problemas

En caso de problema, active el módulo "Registros y trazas" de Dolibarr con el nivel LOG_DEBUG(7).
Luego encontrará líneas similares a 2023-05-12 15:00:02 DEBUG n.n.n.n DOC_DB ++ filesize /projet/PJ2303-0025/contrat_signé [370816]. En este ejemplo, la mención DOC_DB ++ indica la llamada a la función filesize para el documento /projet/PJ2303-0025/contrat_signé con un tamaño de 370816 devuelto como resultado.
Si la mención es DOC_DB --, significa que los datos devueltos son los proporcionados por PHP, sin ningún procesamiento especial realizado por docDB.

Al ejecutar el script docDBmigrateFiles.py en Windows, es posible que se produzca un error con el mensaje fieldnotfound error. Esto indica que debe especificar la ruta de PHP con la opción --phpdir.

En Windows, es posible que encuentre algunos problemas relacionados con el procesamiento de imágenes. Verifique que la opción de PHP exif_data esté activada. Para ello, puede seguir el procedimiento explicado en la guía de instalación.

Licencia

DocDB esta bajo licencia GPL. Consulte el archivo COPYING para obtener más detalles.