Support for auditSync and auditDetach on Auditable custom Pivot class

[txdFrancesco]

Allow the use of auditSync and auditDetach on BelongsToMany relations where the pivot class is an Auditable class.

This is useful in cases where the relation model is itself a Laravel model and may be updated (and thus audited) indipendently from the related models, without requring dedicated code around every ->auditSync call on the related models.

[willpower232]

are you able to correct your spaces to match the rest of the code and add some tests for the functionality you've added?

[txdFrancesco]

For the spaces sure, for the tests I'll need to add a couple of models to reproduce.
Users -> GroupMembers (with 'role' column) -> Groups could be an example of my case. Let me know if you have a better/preferred example structure. I'll update when I'm done, thanks

[txdFrancesco]

I added some tests that cover sync, attach and detach with an Auditable custom Pivot class.
AuditAttach is not affected by my code change, I put in the test anyway for completeness. Let me know if it is better to remove it.

The other tests are failing without the code change and are passing now.

[willpower232]

some final spaces and maybe wake up github actions

[bmoex]

I think auditAttach should be checked too if you want to implement fully

[txdFrancesco]

some final spaces and maybe wake up github actions

@willpower232 Sorry for the inconvenience, I'm not sure what should I do to make this pull request go through.
The spacing was fixed by your commit (I just fixed one more line), but it's not clear to me what you mean with "wake up github actions". Could you explain or point me in the right direction please?
Thank you

[txdFrancesco]

I think auditAttach should be checked too if you want to implement fully

The bug was caused by the way the detach method creates the query to delete the pivot class (creating a new instance and not retrieving the one in the database). Attaching is not affected by it (there is no instance to retrieve), applying the changes would just remove the "created" audit on the pivot class, which is against the idea of having an auditable pivot class.

A full solution would be to rework how the detach method builds the query instead of wrapping with withoutAuditing, but frankly I don't know the codebase enough to make such an impactful change for what is an edge usecase.

[willpower232]

I was confused as to why github actions wasn't working but it seems to be behaving now, I'll re read the PR shortly

[onlime]

The bug was caused by the way the detach method creates the query to delete the pivot class (creating a new instance and not retrieving the one in the database). Attaching is not affected by it (there is no instance to retrieve), applying the changes would just remove the "created" audit on the pivot class, which is against the idea of having an auditable pivot class.

Thanks a lot @txdFrancesco for this explanation. Would be super nice if this could be supported in the future.

@MortenDHansen is there something in the works for V14? f49ab23 looks promising, or at least it's a smart refactor to move that logic into a separate AuditsPivotRecords trait.
Thanks a lot for this great package and very cool to see some progress here.

[willpower232]

seems fine to me, not sure when is good to merge this @erikn69 perhaps just needs a pint/phpstan run after merging your other PR?

[willpower232]

@txdFrancesco are you able to update the PR now that the factories are modernised?

[txdFrancesco]

Should be done, test are passing on my machine. @willpower232 can you approve the action workflow? here it says it needs approval from a mantainer

[willpower232]

looking good to me, thanks for the quick response

@erikn69 time for merging and v14?

[erikn69]

@willpower232 the tests were not run on this change, I won't have time to review this for at least a couple of weeks, if you reviewed it and it won't cause problems feel free to merge it and make the release for v14, you would also have to put the note for the event breaking change (I couldn't find why it works differently in certain scenarios)