Add extra fields and indices to audit tables, based on configuration (see: #61)

[wouter-toppy]

An extend and finalized version of #61

Closes:

• Add another column for audit tables #15
• Is there a supported way to extend the audit entry to add new columns ? auditor-bundle#304
• Add extra fields and indices to audit tables, based on configuration #61

This pull request allows users to create extra columns in their audit tables. This is useful when You need to group audit events with an external parameter for easy retrieval later on.

Adds the options "extra_fields" and "extra_indices" to the Configuration object:

new Configuration([
    'table_prefix' => '',
    'table_suffix' => '_audit',
    'ignored_columns' => [],
    'entities' => [
       'App\Entity\Demo' => [
           'extra_fields' => ['extra_column'],
           'extra_indices' => ['extra_column'],
       ],
    ],
    'viewer' => true,
    'extra_fields' => [
        'extra_column' => [
            'type' => 'string',
            'options' => ['notnull' => true]
        ]
    ],
    'extra_indices' => ['extra_column' => null]
]);

Adds the ability to query the audit table on the configured extra_indices via filters, eg.

$query->addFilter(new SimpleFilter('extra_column', '123abc'));

The field is automaticly detected by using the Symfony Property Accessor

In this case, the App\Entity\Demo needs to have a property called extra_column, and the bundle will automaticly pick it up (doesn't need to be a doctrine property, just an object property) (see: src/Provider/Doctrine/Auditing/Transaction/AuditTrait.php:132)

class App\Entity\Demo
{
    private ?string $extraColumn = null;

    public function getExtraColumn(): ?string
    {
        return $this->extraColumn;
    }

    public function setExtraColumn(?string $extraColumn): void
    {
        $this->extraColumn = $extraColumn;
    }
}

[wouter-toppy]

[wouter-toppy]

[FluffyDiscord]

Any chance to merge this?

[yskolnick]

Is this being implemented? Is there another way to do this?

[manuakasam]

@DamienHarper i wouldn't understand how annoying continuous requests might be, but feedback would be greatly appreciated.
For large scale systems, additional fields would be insanely helpful (i.d. to flag an entry with a customerId that's used across all entities) to be able to "find all entries for customer FOO from all entities". As it stands now, we'd have to first query for potential IDs across all entities and then run the queries against the changelog table using those IDs, that's a lot of effort.

Seeing as this issue has ultimately been open for 4 years or so, I doubt it would make it into the system, though potentially having a final word, or outlook on the current issues, on this would be great.