The Normalizer signatures are the only ones that are a little weird in this aspect. Some of the Normalizer signatures are protection for the sensor itself. So even if the Deny action were to be removed, the sensor may still drop the packet in order to protect its own database. Generally these deal with packets overflowing the sensor's own buffers for things like total number of fragments, number of fragments in a single datagram, number of sequences in a TCP stream that are out of order.

For signatures that are NOT in the Normalizer, yes the Event Action Filter works fine for the removal of Deny actions.

Understand, however, that Cisco does not in general send out new Enabled/Unretired signatures with default Deny Actions.

Some signature DO ship with default Deny actions, BUT these signatures are often Disabled by default, or even when Enabled the subsystem to which they belong is Disabled by default.

These signatures are generally policy type signatures.

There are 2 main policy engines AIC HTTP, and AIC FTP (AIC stands for Application Inspection and Containment)

You will see several signatures with the Default Deny action in these engines, and the signatures may even be Enabled.

BUT even if they are Enabled by default, the underlying policy engine itself is Disabled by default, and you woudl have to specifically go in and Enable the policy engine.

If you have not enabled the Policy engines, then these signatures can be ignored.

With that said, I am not quite sure I am understanding what you are trying to do.

If you create a filter to always remove Deny actions regardless of IP, then your Inline sensor will offer no protection.

Without the Inline deny actions you are just better off running in Promiscuous mode.

If it is just a few specific addresses you don't want Deny actions for, then that on the other hand would be an acceptable and good use of the filter for prevent Deny actions for specific IP addresses.