Laravel-Backpack / CRUD

Build custom admin panels. Fast!
https://backpackforlaravel.com
MIT License
3.17k stars 896 forks source link

[Bug] 4,1 - Using select2_multiple field, when pivot is not using auto ID as relation criteria, create/update fails #3179

Closed aaron-1pbx closed 4 years ago

aaron-1pbx commented 4 years ago

Bug report

What I did

I setup a many to many relationship in Laravel and defined migrations correctly and models correctly.

One table, called Plans, is a typical table where a bunch of plans will be listed. It uses its primary key, auto incrementing ID as its pivot table relationship key.

Second table is called Apps. This table we are syncing with a third party, and it is not guaranteed that our primary auto incrementing ID will always stay consistent. So I know that the field "name" which is a system name for the app. We use Label for the human friendly readable name. I am using the name field (with index on it, if that is relevant) as the relation with the other table and within pivot table.

I know it is setup properly as even in phpMyAdmin, I get nice drop downs when doing a manual insert and it inserts records correctly. As well, doing any operating in Laravel Eloquent also produces expected results.

What I expected to happen

I expect when I select 1 or numerous "Apps" to associate with my Plan, for them to be inserted in the pivot table based on exact definition in models

What happened

Insert into pivot tables is using the ID of the Apps table even though it should be using the name.

What I've already tried to fix it

Details can be found in my stackoverflow post. After deeply reviewing the Backpack documentation I think this may be a bug, or an impossible operation I've reviewed the documentation in great detail in regards to these fields and the options, and have tried any and all possible combinations that made any sense to try.

https://stackoverflow.com/questions/63687569/cant-get-backpack-to-pass-correct-value-when-inserting-updating-a-many-to-many

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

I haven't pushed this code to the real server, but on test server where I do development, results is:

[root@office adminapi]# php artisan backpack:version

PHP VERSION:

PHP 7.3.21 (cli) (built: Aug 4 2020 08:06:20) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.21, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.3.21, Copyright (c) 1999-2018, by Zend Technologies

LARAVEL VERSION:

v7.26.1@fad3e5f03b9ae89853c8a0925231d2b3ce07a9c3

BACKPACK VERSION:

4.1.21@187bb0c3ce52ac2bfefeb9cd7518fec27a82ebcc

welcome[bot] commented 4 years ago

Hello there! Thanks for opening your first issue on this repo!

Just a heads-up: Here at Backpack we use Github Issues only for tracking bugs. Talk about new features is also acceptable. This helps a lot in keeping our focus on improving Backpack. If you issue is not a bug/feature, please help us out by closing the issue yourself and posting in the appropriate medium (see below). If you're not sure where it fits, it's ok, a community member will probably reply to help you with that.

Backpack communication channels:

Please keep in mind Backpack offers no official / paid support. Whatever help you receive here, on Gitter, Slack or Stackoverflow is thanks to our awesome awesome community members, who give up some of their time to help their peers. If you want to join our community, just start pitching in. We take pride in being a welcoming bunch.

Thank you!

-- Justin Case The Backpack Robot

aaron-1pbx commented 4 years ago

Based on comments on Stack overflow it seems Pivot table in laravel requires the connecting column to be the primary key. I made adjustments to my table structure, models, and now it all works. It was not a Backpack bug at all as when testing in laravel tinker: $plan = Plan::find($somePlanId); $app = App::find($someAppId); $plan->apps()->attach($app);

This did not produce the correct results, It also didn't produce correct results if I used the app Name in the attach parameter, and if I used the primary key in app table as attach parameter, it gave same error I was getting in backpack.

tabacitu commented 4 years ago

Thank you for posting your findings here too @aaron-1pbx . I'm sure someone, someday will run into this and you'll save them some frustration.

Cheers!