Stratégies d'expiration hiérarchiques sur des éléments individuels

Question

Je cherche à mettre en œuvre une stratégie personnalisée pour l'expiration des éléments sur une liste personnalisée (et non une bibliothèque de documents). Cette politique doit être modifiable élément par élément et calculer la date d'expiration en fonction de règles définies par l'utilisateur telles que: nombre d'accès, durée d'expiration ou toute agrégation des deux règles ci-dessus. En raison de cette granularité, je ne peux pas utiliser le modèle de stratégie d'expiration par défaut (ou implémenter un modèle personnalisé), ni l'audit par défaut dans ma stratégie d'expiration. Comme les éléments sont organisés en dossiers et sous-dossiers, je voudrais appliquer les politiques de manière hiérarchique (similaire au modèle d'autorisation OOTB). Ma solution serait de créer des types de contenu personnalisés pour les dossiers et les éléments afin d'inclure une colonne qui contiendra les règles sérialisées, tandis que l'accès à ce champ "règles" serait synchronisé manuellement à partir du code. Un formulaire Infopath personnalisé serait utilisé pour éditer les règles attachées pour chaque entrée de la liste (qu'il s'agisse d'un dossier ou d'un élément) et ces données seraient utilisées par une page d'application personnalisée pour accorder l'accès à l'élément (basé sur un élément supplémentaire). champs, il fait aussi le travail réel pour chaque élément). Bien que je ne sois pas vraiment sûr que la solution ci-dessus serait approuvée (la politique de l'entreprise peut m'interdire d'éditer le fichier Global.asax pour le schéma de synchronisation), je me demande si quelqu'un pourrait avoir une meilleure architecture pour cette exigence?

Answer 1

Ok, je vais essayer. Tout d'abord, j'oublierais InfoPath et opterais pour une page ASPX personnalisée pour la configuration des politiques. L'ensemble du projet devrait être emballé dans un WSP solution avec les ingrédients suivants:

1. configuration politique ASPX page dans le dossier _layouts. Cette page doit permettre aux utilisateurs de créer et de modifier des stratégies pour les listes, les dossiers et les éléments. La page pourrait à son tour sérialiser et stocker des règles dans le sac de propriétés sur les éléments de la liste. Pour les règles de niveau liste, utilisez le sac de propriétés SPWeb. Vous pouvez également créer une liste masquée dans laquelle toutes les règles sont stockées dans des fichiers XML associés à une liste, un dossier ou un élément.

2. Collection de sites Feature qui ajoute Custom Actions à votre liste personnalisée pour l'ajout et la modification de stratégies. Vous pouvez ajouter une action personnalisée telle que «Modifier la stratégie» au menu ECB sur les dossiers et les éléments. Pour les stratégies de niveau liste, vous ajoutez une action similaire au menu des actions de liste.

3. SharePoint Timer Job pour appliquer les stratégies. Utilisez une fonctionnalité au niveau de la batterie pour installer le travail du minuteur dans un récepteur d'entités à l'activation.

Quoi qu'il en soit, je pense que vous devrez faire face à de nombreux efforts de développement.