Les dossiers système AEM réapparaissent après suppression

Certains dossiers dans AEM réapparaissent après suppression (souvent après un déploiement Cloud Manager, un redémarrage d’instance ou l’utilisation d’une fonctionnalité système), car ils sont générés par le système, requis par la fonctionnalité ou réintroduits par du code personnalisé à chaque déploiement. AEM dépend de ces chemins (créés par l’initialisation du référentiel, les fonctionnalités du produit, l’activation de Dynamic Media ou les tests fonctionnels de Cloud Manager), la suppression permanente n’est donc pas prise en charge. Le masquage des dossiers impossibles à supprimer avec les autorisations ACL et la suppression des dossiers véritablement personnalisés déployés par code du référentiel constituent la bonne manière de les tenir à l’écart de la vue des auteurs sans enfreindre les fonctionnalités du produit.

Description description

Environnements :

  • Adobe Experience Manager as a Cloud Service (AEMaaCS)
  • AEM Managed Services
  • AEM Assets et Dynamic Media
  • Pipelines Cloud Manager

Problème/Symptômes :

  • Les dossiers réapparaissent après suppression avec un horodatage « récemment créé ».
  • La suppression de projets ou de la mise en quarantaine réussit visuellement, mais le dossier réapparaît après un redémarrage ou le déploiement suivant.
  • Les /content/campaigns, /content/outbound-marketing et /content/test-site sont recréés lors de chaque exécution du pipeline.
  • Les dossiers Dynamic Media _CSS et _DMSAMPLE s’affichent dans les résultats de recherche et ne peuvent pas être supprimés.

Cause principale :

AEM comprend plusieurs chemins de dossier gérés par le système ou requis par des fonctionnalités, créés par l’initialisation du référentiel (repoinit), les fonctionnalités du produit, l’activation de Dynamic Media ou les tests fonctionnels Cloud Manager. Ces nœuds sont automatiquement recréés lors des déploiements ou de l’exécution. Comme le produit dépend de leur présence ou suppose leur existence à des fins de rétrocompatibilité, la suppression n’est pas prise en charge. Les dossiers personnalisés déployés dans le code se comportent de la même manière, car le package de code les réintroduit à chaque déploiement.

Comment confirmer

  1. Identifiez le type de dossier (dossier système, racine d’intégration, dossier système Dynamic Media, dossier de test Cloud Manager ou dossier déployé par code) en comparant le nom et le chemin du dossier à ces catégories.
  2. Si le dossier ne correspond à aucune catégorie connue, il est probablement déployé en code. Consultez le référentiel Git de Cloud Manager pour connaître le chemin d’accès afin de confirmer que le code le réintroduit.

Résolution resolution

Pour résoudre ce problème, procédez comme suit :

  1. Masquez les dossiers système non supprimables à l’aide des listes de contrôle d’accès. Accédez à Outils > Sécurité > Autorisations > Ajouter une entrée ACE, saisissez le chemin d’accès au dossier (tel que /content/dam/projects, /content/campaigns, /content/outbound-marketing ou /content/test-site), puis définissez le type d’autorisation sur Refuser (par exemple : jcr:read) pour les groupes d’utilisateurs appropriés. Connectez-vous en tant qu’utilisateur au groupe cible et confirmez que le dossier n’apparaît plus. S’il est toujours visible, vérifiez que l’entrée de contrôle d’accès a été créée sur le bon chemin et que les autorisations héritées n’accordent pas l’accès.
  2. Pour les dossiers déployés avec du code, supprimez le chemin d’accès de la base de code. Recherchez le chemin d’accès au dossier dans votre référentiel Git Cloud Manager, supprimez-le et effectuez un redéploiement via le pipeline. Réexécutez le pipeline et vérifiez /content/dam pour confirmer que le dossier ne revient pas. S’il réapparaît, demandez à votre équipe de développement de suivre d’autres modules qui créent le chemin d’accès.
  3. Laissez les dossiers système Dynamic Media (_CSS, _DMSAMPLE) en place. Ne les supprimez pas via CRXDE : ils sont nécessaires pour les fonctionnalités de la visionneuse Dynamic Media. S’ils encombrent les résultats de la recherche, ajustez les filtres de recherche ou les autorisations utilisateur afin que les utilisateurs ne les voient plus et confirmez que les aperçus Dynamic Media continuent de fonctionner.
  4. Laissez le /content/test-site en place, car les tests du pipeline Cloud Manager l’exigent. Ne la supprimez pas ; appliquez-lui une liste de contrôle d’accès pour la masquer aux auteurs. Confirmez que la prochaine exécution de Cloud Manager réussit toujours ses tests fonctionnels. Un dossier manquant provoque un 404 dans ces tests.

Validation

  1. Vérifiez que le dossier n’est plus visible par les groupes d’utilisateurs cibles, mais qu’il reste visible par les administrateurs.
  2. Confirmez que le prochain déploiement de Cloud Manager ne supprime ni ne remplace les autorisations ACE.
  3. Si le dossier a été déployé avec du code, vérifiez qu’il ne réapparaît plus après l’exécution d’un pipeline.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles