[4.1][New Operation] Audit - using owen-it/laravel-auditing instead of venturecraft/revisionable

[cerelli]

Bug report

Is it better to correct the error or find another package?

What I did:

I use:

        Relation::morphMap([
            'actions' => 'App\Models\Action',
        ]);

What I expected to happen:

What happened:

Class error to retrieve the history of revions

What I've already tried to fix it:

Backpack, Laravel, PHP, DB version:

3.4, 5.6, 7.1 MariaDB

[cerelli]

The solution ?
https://stackoverflow.com/questions/36043401/how-to-use-laravel-revisionable-with-morphmaps

[AbbyJanke]

Fix:

There is a PR for VentureCraft/revisionable from Jan 2017 however it looks like the package is not currently being maintained.
VentureCraft/revisionable#269

Options Due To Lack of Package Maintenance:

Few options we can do to make it work on backpack:

• instead of just requiring VentureCraft/revisionable we could make a form and pull the fix into our fork.
• replace with other package, i recommend Laravel Auditing
• create our own.

[cerelli]

The best thing would be to fork Laravel-Backpack / CRUD, remove VentureCraft / revisionable and implement Laravel Auditing, then do a pull request.
Quite right?

[lloy0076]

Changing the package to do revisions (however we do it) is likely to break something unless we happen to fork and maintain the original ourselves.

@cerelli Before doing that, I'd discuss with @tabacitu (or given the time frame if you already have done that, we'd be happy to look at a PR or a fork if there is one).

[cerelli]

This is my fork:
https://github.com/cerelli/revisionable

Configuration:
in composer.json

...
"require": {
.....
"venturecraft/revisionable": "dev-fix-map-morph as 1.28.0"
},
....
"repositories": [
{
"type": "vcs",
"url": "https://github.com/cerelli/revisionable"
}
]

[bluec]

I'm new to backpack but came to this issue because I already wondered if the lack of maintenance of venturecraft/revisionable could be a problem. I am interested to see how Backpack handles this going forward.

As per @AbbyJanke suggestion it seems owen-it/laravel-auditing is very mature and well maintained/documented so it could be an excellent replacement rather than relying on a self-maintainted fork of revisionable. I doubt I'm experienced enough yet to contribute such a change but I may have a play around with it.

[tabacitu]

Update: it seems like the patch has gone through for some time, so the issue is fixed.

Also:

• venturecraft/revisionable is no longer deprecated, just takes quite a while to merge fixes;
• now I see they've already added support for Laravel 6 (before it's out) so... I don't know; there might be hope;

We should probably create a different operation in Backpack 4.0 (Audit) that can be an alternative to Revisions. One that uses owen-it/laravel-auditing. That way:

• people can at least choose their dependency for projects that start with Backpack 4.0;
• we're ready to change providers if venturecraft/revisionable becomes deprecated or something;

I don't think the db structure is exactly the same between the two projects, so I doubt we can make an easy transition from one to the other...

[tabacitu]

Update: venturecraft/revisionable is NOT abandoned.

But its creator is looking for help with maintenance. Anybody here want to help a popular Laravel project (1.5 million downloads!!!)? If so, speak up here.

The plan stands - should probably create a new operation for owen-it/laravel-auditing - better safe. Let's leave this open until we do.

Cheers!

[PizzaTibe]

I sugest suporting https://altek.gitlab.io/accountant instead. The owen-it/laravel-auditing pakage has lots of issues andpull requests, wich is a sign of abandoned.

[ziming]

I have a new alternative suggestion for this.

In Laravel Nova, they have this action_events table where they record the changes to the models.

I wonder if it is better we do the same (i.e. same table name, same columns). This way it will be easy for people to switch between laravel nova and backpack and still have their revisions history working!

May want to talk to the laravel nova team 1st on this.

[bnxdev]

Or what about a generic revision module that perhaps has it's own config stack and allows you to use any of the favourite audit/logging backends?

Sure this is more work but I think it's clear from above everyone has a preference (and not always able to change).

But all these audit/logging packages do a simmilar thing, we'd just need to reference a different column or data type/parser.

I'm not committing to anything (sorry) but on my current project owen-it/laravel-auditing is used, at some point I will be integrating this into Backpack for us. Depending when this happens I shall make a start or help contribute to whatever the community can decide on this topic!

config/backpack/revision.php:

<?php

return [
    'default' => 'owen-it',
    'loggers' => [
        'owen-it' => [
            'parser' => SomeParserClassWeMakeThatConvertsDatabaseColumnsToAStandard::class,
            'driver' => 'database',
            'connection' => 'default,
        ],
        'altek' => [
            'parser' => ...::class,
            'driver' => 'database',
            'connection' => 'default,
        ],
        ...
    ],
];

[tabacitu]

Thanks for pitching in everyone!

@ziming I agree it would be nice to have a clear&simple process for people to migrate from Nova to Backpack. I'd love to see an operation like that built - it shouldn't be too difficult.

@PizzaTibe thank you - didn't even know about Laravel Accountant .

@Bnxio Hmm... can't say I love the idea of a generic module - it's a level of abstraction that I don't think is needed in this case. You'd either have to
[A] create one package that supports all auditing packages; CON: very difficult to maintain
or
[B] built both a generic package, and adapters for each of the supported packages; CON: when installing, you'd need to install:

• the auditing package you want
• the generic module (aka the Operation)
• the adapter

Seems a little complicated. The way I see it, In Backpack v4 it's pretty easy to create a custom operation. And those operations can be delivered as composer packages. So instead of A or B above, I think it's easier to do [C] create different operations, for each auditing package - ex backpack/revisionable-operation andbackpack/auditing-operation. This would have quite a few benefits:

• the developer only has to install:
  • the auditing package they want;
  • the Operation for that auditing package;
• maintenance would be easier - if laravel-auditing changes something only auditing-operation needs to change;
• the operation itself would need zero/little configuration; it would just use the config values of the auditing package;
• each operation would be plug&play, if you're already using that particular auditing package - just use the trait on your CrudController and you're done;

As a first step, we'd have to split the current Revisions operation into a package. I've added an issue here for that. Anybody can already create an auditing-operation package, to provide a user interface for Laravel Auditing , but if we create that package, it will be easier to see how. And it will be easier for people to not have two auditing packages installed.

@Bnxio if you're building an auditing-operation for yourself anyway - are you interested in turning your operation into a package? Something like bnxio/laravel-auditing-operation-for-backpack sounds cool to me 👀 If not, please consider sharing your working code with us in any other way, for us/someone to create the package 😄

A different path forward would be [D] talking to venturecraft, altek and owen-it (the developers of the auditing packages) and pushing the code for the Backpack operations right inside the packages themselves. But I don't think many of them will agree to it - they would have the responsibility to maintain the code, which would make their job more difficult.

[bnxdev]

Thanks for the input! Appreciate the guidance and that definitely makes much more sense than my Monday morning ramblings.

I'll keep watch on #2430 hopefully you can go down that route. If so I can definitely start work on a package (in my env we use owen-it/laravel-auditing).

I know you said it can be done now but waiting on #2430 gives me an excuse to make this a priority within my current project (two birds one stone...) as I have not started anything yet unfortunately.

[brynnb]

Worth noting that venturecraft's library doesn't support JSON fields which may be used extensively in backpack projects when using the "fake" datafield. If you go forward with that option it'd be nice to see that fixed.

[jcastroa87]

Hi.

Due to not activity on many years i will close this discussion, if there is needed feel free to reopen or create a new one.

Cheers.