Question: I would like to create a service to toggle policies on and off by QName from an external system. Primarily, I want to disable the auditable policies which prevents my external system from pushing in content and setting the modified/created dates. I am aware of the [BehaviourFilter](http://dev.alfresco.com/resource/AlfrescoOne/5.0/PublicAPI/org/alfresco/repo/policy/BehaviourFilter.html), but those changes are restricted to the current transaction. **I would prefer to have some control over turning the policy on and off without restarting the system.**

How do I prevent a policy from firing for an unspecified amount of time, beyond a single transaction?

Answer: 
Alfresco's auditable policies are so often subject for irritations and the needed work arounds are unnecessary waste of time. I'd like to discuss a solution which is more work but which may avoid the trouble in future with more flexibility since Alfresco combined two things which shouldn't be combined:

* modified and created date
* audit modified and created date

The first one is exposed to the file protocols and should be writable from the client. There are so many use cases where we need to set the dates (moving files from and to alfresco, native apps which brake if date is changed by server)

The second one is for the admins and compliance guys only and should be exposed as independant properties thru the service api and Web UI - not thru the file protocols.

Since Alfresco combines both use cases in only one database column / one property we will always have trouble. Either the file protocol use cases doesn't work or we can't trust the audit attributes. 

My suggestion would be to separate this by introducing 2 new properties in the model:

* createdDate, modifiedDate (there are only the audit times persisted at the moment)

and map these properties to the file protocol's dates. 
A policy would manage the update on these properties if not set by the client (all except file protocols?)

My intention would be to put this in a community module / patch.

Any feedback to this approach? Maybe someone to sponsor this?
It's good that you're aware about the BehaviourFilter, but you're probably missing the point why you shouldn't be totally disable the policy for a time-period and then re-enabling it. If by chance the external system sends a signal to disable the policy and parallel a user is using Alfresco and uploading, that means that it isn't triggered any more.

Hence you really should use the **BehaviourFilter** within your writing transaction from the external system.

How:
Create custom webscript which disables the BehaviourFilter for the QNAME/Node and re-enables it again. If you look at Alfresco's RecordsManagement code it uses the same principle.