ECM / GED : work on base tree ?

[rycks]

Feature Request

I would like to be able to have a trashbin and a file versioning solution into dolibarr ECM/GED.

Forget dolibarr objects, i'm really only on GED/ECM part, only thinking about file life cycle.

• File created
• File modifications
• File deleted

For the moment we only have a documents directory where we store files.

One of the main free software project who works on files (nextcloud) have good ideas (i think) : one main directory to store files, one directory to store trash files and an other directory where all file versions are stored. trashed files are suffixed with .d+timestamp and versions files are suffixed with .v+timestamp

Admin sys can choose to put main directory on a fast file system and trash / versions on a slow (cheep) one.

Use case

Here is what we have on nextcloud:

├── files
│       └── projets
│           └── mydoc.md
├── files_trashbin
│   └── files
│       └── otherfile.md.d1666805941
└── files_versions
        └── projets
            ├── mydoc.md.v1666805931
            ├── mydoc.md.v1668361351
            ├── mydoc.md.v1678984851
            ├── mydoc.md.v1678985045
            ├── mydoc.md.v1678985199
            └── mydoc.md.v1678985387

Suggested implementation

Are you ok to add two root files tree:

• documents_versions
• documents_trashbin

If you says "ok" i could try to do the job and make a PR for that.

Suggested steps

in htdocs/conf/conf.php

$dolibarr_main_data_root='/var/www/dolibarr/documents';
$dolibarr_main_data_trash='/var/www/dolibarr/documents_trashbin';
$dolibarr_main_data_versions='/var/www/dolibarr/documents_versions';

Then we could update methods delete from ecmfiles.class.php to move file into same path but in $dolibarr_main_data_trash base dir.

And add some methods to ecmfiles.class.php like "archive" for example then dolibarr developpers could make an archive of a file when they need / want / wish.

And some others files to navigate into files history like we can have on a GED/ECM system.

[eldy]

What do you think of this

/documents/.trashbin /documents/.versions

Having other directory out of /documents has big impact on existing security code. We don't need $dolibarr_main_data_trash or $dolibarr_main_data_version. Allowing custom name introduces also more difficulties. We are still able to move this directory on an external support/drive by a symbolic link for example or a filesystem mount. Name should be fixed so we can easily implement. In the past we allow custom name for the /custom dir. We revert this due to the bad gain/cost and everybody seems happy with the same dir name /custom. i think we should do the same here. The same for everybody. Adding the "." means this directory is hidden by default. So we can explain "to have a paranoiac full backup, just copy all /documents". For a "usefull minimal backup, just do not include hidden directories".

[rycks]

Ok, let me try with that ... i would prefer to have trash & versions folder at the same position sans main document directory to be "full native storage compatible with nextcloud" but that's not so important and your point of view makes sense.

[hregis]

@rycks @eldy yes and it's more simple for Multicompany compatibiliy

/documents/.trashbin /documents/.versions

/documents/2/.trashbin /documents/2/.versions

etc...

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).

[rycks]

And here is the proof of concept module "archives pdf", i don't have time to make a review that week ... but it's here

https://inligit.fr/cap-rel/dolibarr/plugin-archivespdf

[eldy]

So lets summarize what we have to match nextcloud standard according to first posts of this issue:

1) First, for archive file names, an extension .vTimestamp is added on old files. Example:

myfile.ext.v1715037066

I see no trouble of doing this now for the cases that need it because there is not yet existing use cases in dolibarr that makes versionning of files.

2) Files are also stored in a similar tree than original, but into a different subdirectory. On dolibarr, it could be, in a future, documents/versions. Whatever is the directory name,current code is not ready for this, because path are hard coded with things like

conf->module->multidir_output[entity] with fallback on conf->module->dir_output[entity]

to define path to store files on disk. So, to prepare code to be able to evolve to another dir (whatever is choice in future), we must first replace all conf->module->dir_output into getMultidirOutput() function. This function was introduced to have a centralized function to get dir for storing files. This function will allow to switch easily one day. For the moment the ticket can remain open until replacement of conf->module->... with getMultidirOutput() is finished. Replaced has started in v19 but is only complete at 2%. This is a good topic for a "first-issue". Newbies are welcom on this task.

[eldy]

The method manageFileBackups() has been added by into files.lib.php to allow to archive files the same way nextcloud do.