Hierarchical expiration policies for individual items

Question

I am looking for a custom policy implementation for an item to expire in a custom list (and not in a document library).

This policy should be editable on an element by element basis and calculate the expiration date based on user rules, such as: number of hits, expiration time, or any aggregation of these two rules above. Due to this granularity, I cannot use the default expiration policy model (or implement a custom one), as well as the default check in my expiration policy.

Since the items are arranged in folders and subfolders, I would like to apply policies hierarchically (similar to the OOTB permission model).

My solution would be to create custom content types for folders and items to include a column that will contain serialized rules, while access to this “rule” will be manually synchronized from code. The user form Infopath will be used to edit the attached rules for each entry in the list (whether it is a folder or an item), and this data will be used by a special page of the application to provide access to the item or not (based on an additional field element, it also does the actual work for each item). Although I’m not quite sure that the above solution will be approved (company policy may forbid me to edit the Global.asax file for the synchronization file for the synchronization scheme), I wonder if anyone can come up with a better architecture for this requirement?

Answer 1

Ok, I'll do it. First, I would forget about InfoPath and go to the custom ASPX page to configure policies. The entire project must be packaged in a WSP solution with the following ingredients:

• Aspx configuration configuration in _layouts folder. This page should allow users to create and edit policies for lists, folders, and items. The page can in turn serialize and store the rules in a bag of properties on the list items. For list-level rules, use the SPWeb property package. In addition, create a hidden list in which all the rules are stored in the XML files associated with the list, folder, or item.

• Site Collection A feature that adds Custom Actions to its own list for adding and editing policies. You can add a custom action, such as "Edit Policy" in the ECB's menu of folders and items. For list-level policies, you add a similar action to the list action menu.

• SharePoint Timer Job for policy enforcement. Use the farm level function to set the timer job in the function receiver when activated.

No matter what, I think, you will face a lot of development efforts.