Il existe certaines situations où les utilisateurs souhaitent conserver des fichiers uploadés dans Discourse qui ne sont pas strictement associés aux modèles et propriétés existants de Discourse prenant en charge les uploads, c’est-à-dire des « uploads orphelins » autorisés (« whitelisted »).
Par exemple, certaines personnes souhaitent utiliser le plugin Custom Wizard pour uploader du contenu associé à un sujet (et non pas spécifiquement à un message).
Le problème est que le job clean_up_uploads supprime tous les uploads orphelins. Ses exceptions se limitent aux URL figurant dans des paramètres de site spécifiques.
Vous pouvez bien sûr désactiver clean_up_uploads ou augmenter la valeur de clean_orphan_uploads_grace_period_hours, ce qui est parfois ce que je suis contraint de faire. Mais ce n’est pas idéal.
Il existe peut-être une autre méthode pour « autoriser » (« whitelist ») des uploads orphelins via un plugin que je n’aurais pas vue, mais sinon, il serait excellent d’ajouter un mécanisme permettant de le faire au processus de nettoyage des uploads.
Je serais ravi de préparer une PR dans ce sens, mais je me demande si d’autres considèrent cela comme un problème.
Pour les éléments révisables, @eviltrout a introduit un mécanisme général permettant de lier des objets arbitraires à un élément révisable.
Passer à un système similaire pour les téléchargements serait comme déplacer plusieurs montagnes. Ce serait une montagne agréable à déplacer, car le système actuel est assez fragile.
La solution de contournement la plus simple pour l’instant consiste à créer un paramètre de site masqué avec un type de données pour :upload. Ensuite, ajoutez-le dans la table des paramètres du site.
Oui, c’est ce que je pensais. Je n’aimais pas trop cette solution car il faudrait créer un paramètre différent pour chaque fichier téléchargé, ce qui ressemble à un abus de la table site_settings.
En tant que solution temporaire, avant que la montagne ne soit déplacée, seriez-vous opposé à ce que je soumette une PR pour ajouter une exception supplémentaire à la grande requête “exceptions” qui utilise plugin_store_row avec un plugin_name comme whitelisted_orphan_upload_id ?
Cette requête est déjà TRÈS lente, je crains qu’un autre join ici ne la rende très pénible.
Je ne suis pas sûr, mais peut-être devrions-nous commencer par préparer la nouvelle table dans le noyau pour UploadRefrence(object_id, object_type, upload_id) et faire le join dessus, au moins c’est peu coûteux, puis nous pourrons y déplacer les éléments. Il y a pas mal de mouvements faciles, seuls les uploads de posts seraient délicats..euh.
Je pense que c’est un travail que je préférerais que l’équipe ici prenne en charge, c’est très fastidieux.
Parlez-vous de l’héritage par table unique (single table inheritance) de Rails ? https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.html. C’est une solution très adaptée pour les éléments révisables, car ils partagent tous une logique de base, tout en ayant des champs supplémentaires.
Dans ce cas précis, il semble que le problème vienne du fait que nous utilisons des identifiants de téléchargement partout, sans supprimer les fichiers téléchargés lorsqu’ils sont effacés ?
Est-il risqué de supprimer un téléchargement si un utilisateur le retire de son profil, au cas où le même hachage SHA1 serait utilisé ailleurs dans l’application ? Si c’est le cas, je pense que la suggestion de @sam concernant une table UploadReference est une bonne solution.
Si les téléchargements ne sont jamais partagés de cette manière, je pense qu’une meilleure solution consisterait à les supprimer lorsque ces champs sont mis à NULL.
C’est exactement pour cela que nous avons besoin de la table UploadReference
Je pense en réalité que c’est une excellente tâche pour en apprendre davantage sur le fonctionnement interne de Discourse. Cela pourrait être une bonne tâche pour @cvx, en commençant début octobre. Nous ferons de la programmation en binôme pour démarrer et bien diviser le travail en plusieurs petites tâches.
Je suis très intéressé par une table UploadReference. Nous sommes dans une situation où nous avons de nombreux fichiers téléchargés dans des plugins qui sont considérés comme des fichiers orphelins. Notre solution consiste simplement à désactiver clean_up_uploads. J’ai vérifié l’autre jour et nous avons maintenant 10 Go de fichiers orphelins qui devraient être supprimés manuellement via un script capable également de déterminer si l’un d’eux est référencé dans nos plugins. Une solution comme celle discutée ici nous serait très utile.
D’ailleurs, sur ce sujet. Dans certains cas, nous référençons certains fichiers uploadés uniquement avec des balises HTML img. Cela semble interrompre la cuisson de ces publications, et d’autres éléments comme les hyperliens ne sont pas cuits non plus. Je constate que les fichiers uploadés sont généralement référencés sous la forme upload://.png. Ma question est : où peut-on trouver cette chaîne ? Elle n’est pas stockée dans l’objet Upload, du moins à ce que je puisse voir.
@angus
Nous avons récemment fusionné cette PR qui ajoute une table upload_references pour répondre aux préoccupations soulevées dans le message initial.
