Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Original data persists when emptying a relationship field with inline_create #3543

Closed
WayneFrisby opened this issue Feb 19, 2021 · 3 comments
Assignees
Labels

Comments

@WayneFrisby
Copy link

Bug report

What I did

I have created many relationship fields. Most work fine.
Tags with Polymorphic relationships work with no casting on its Model.

Yet, on my Business Model I have this relationship and casting to an array

// Business Model
protected $casts = [
    'phones' => 'array', // Required to get it working
];

public function phones()
{
    return $this->hasMany(Phone::class);
}

// Phone Model
public function business()
{
    return $this->belongsTo(Business::class);
}

without 'inline_create' set to true with the entity set, it works fine, but once set with like this

'inline_create' => [ 'entity' => 'phone' ],

I can't make it null once I have any current-value's set.

Everything else works as expected, but once I've added anything to the database, it's impossible (in the UI) to go back to an empty state.

What I expected to happen

Once deleting all items (in this case, phone numbers) then saving, it updates to an empty state.

What happened

The same or similar to #2760

It remains populated with the original value(s).
I can remove many items to 1 fine, but many/one to none, the original data persists.

What I've already tried to fix it

Many things.

I've tried comparing to working relationship fields. Only difference being the relationships and casting to array (due to JSON string) versus no casting (returns Collection).

Dug into the fetch_or_create file as this seems like where the issue may be.

When clearing the select box the <select> <option>'s remain, yet disappear from the render block. At first I thought this was a bug (might still be?), yet this seems to happen all the time, even on working fields. So I'm guessing that's just how select2 works? Seems odd, but maybe some sort of accessibility thing? We add options (to the select), but never remove them.

The only way I've manged to get it to work (not persist) is to set one <option> to an empty value via the dev tools, then save.

As for the field definition, I've tried many variations with no luck.

            [   
                'name'    => 'phones',
                'type'    => 'relationship',
                'ajax'          => true,
                'inline_create' => [ 'entity' => 'phone' ],
                'attribute' => "number",
                'minimum_input_length' => 0,
                'allows_null' => true,
            ],
           
            // Simplified
            [   
                'name'    => 'phones',
                'type'    => 'relationship',
                'ajax'          => true, // Not sure this makes any difference
                'inline_create' => [ 'entity' => 'phone' ], // Required for desired feature, works fine without but I want it
                'allows_null' => true, // Not sure this makes any difference
            ],

Backpack, Laravel, PHP, DB version

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

PHP VERSION:

PHP 7.4.3 (cli) (built: Oct 6 2020 15:47:56) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
with Zend OPcache v7.4.3, Copyright (c), by Zend Technologies

LARAVEL VERSION:

v8.28.1@73dd43d92fcde6c6abc00658ae33391397ca119d

BACKPACK VERSION:

4.1.x-dev@62856b1f01fc3e05c80140fc22f85ea2aac8368c

@welcome
Copy link

welcome bot commented Feb 19, 2021

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:

  • Bug Reports, Feature Requests - Github Issues (here);
  • Quick help (How do I do X) - Gitter Chatroom;
  • Long questions (I have done X and Y and it won't do Z wtf) - Stackoverflow, using the backpack-for-laravel tag;
  • Showing off something you've made, asking for opinion on Backpack/Laravel matters - Reddit;

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

@pxpm
Copy link
Contributor

pxpm commented Mar 4, 2021

Hello @WayneFrisby thanks for the report.

Indeed InlineCreate was not designed for HasMany relation, because in HasMany the related key is stored on the related model, and not in the current one like BelongsTo. It could work but only on update because you need to have the current entry key to setup in the related model.

We are in the process of providing that functionality but it's through a different field, repeatable.

PR is here: #3410

If you want to give it a try, let us know the results.

Best,
Pedro

@pxpm pxpm self-assigned this Mar 4, 2021
@pxpm
Copy link
Contributor

pxpm commented Apr 7, 2021

I am going to close this due to inactivity. The solution is beeing provided in the mentioned PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants