2.7 Bidirectional Relationship field isn't updated automatically to the opening modal when adding related record

[PodsBot]

2.7 Bidirectional Relationship field isn't updated automatically to the opening modal when adding related record submitted via Slack by jimtrue updated by Quasel

Parent

• if the parent item isn't saved add a warning/hint and disable AddNew

Child Modal

• Modal links need to pass Pod, Field, and Parent Item ID (where modal is coming from)
• When adding new item, set default for that field using the Parent Item ID if the pick field is bi-directional AND related to that pod AND sister field matches that field
• if the child's relation is single select hide it ( Hide bidirectional relationship field from Flexible Relationships 'Add New' #4567 ) or just "disable it"+ hint text

[jimtrue]

Not sure how this one is going to work. When you add new to the related record, the 'connection' to the related record in it's bidirectional field won't be updated until you 'save' the originating record. The item has been selected and added to the parent window, but the bidirectional relationship won't be saved to the child record until you 'save/update' the parent.

[sc0ttkclark]

Bi-directional only gets set when you commit to saving the current item. So any items you add within the modal can't be bi-directionally related until they commit to saving it.

[jimtrue]

Correct, but as a usability standard: If there's a related record in the modal for the child record, it should automatically be set to the parent record. Don't know how you could do that, however.

[sc0ttkclark]

We could do that by appending the originating pod/field slug so we can reference that on saving of a field that's bi-directional. We'd have to add some stuff to the corresponding pod form to do it, which would take some effort -- however I am strongly against any bi-directional association until committing to the save from the primary save form, which would then handle the bi-directional saving on it's own.

[jimtrue]

My thought actually would be, we'd be setting the value for the bidirectional record (if it's detected in the child pod) the same way we would if it was a 'default value' set via parameter or Query Var, in this case the ID of the Parent Pod. We'd only set it in the 'form', we wouldn't save it until they hit save. But it would only be if the child record had a bidirectional pointing back at the parent.

[renaudham]

Hi
This, I think, a very important element of this new feature, in term of UI and UX, to make it usable by most users.

**First lets note that it can be working ONLY on EDIT form mode. (on Add new, of course no ID exist yet to refer to)

**What is obviously needed is that
When we open the modal related form
the related field should appear automatically set up with the correct value.
Once loaded, so the value selected would be visible to the user, on this field - no on saving.

**To make it understandable let me give a use case

A project form, in EDIT mode, with multiples bugs elements as a related field list view.
And a Add new button.

On add, modal window with a Bug form, and a Project single selector is there
and needs to be auto set to the correct project ID.

**My own guess as I feel is that
*We add parameters in the url sent by JS
wp-admin/post-new.php?post_type=bugs&pods_modal=1&rel_id=1&target_relation=project
rel_id = the parent Project id (coming form the related field data-item-id)
target_relation=the field name

*Then in the relation field code,when we display the proejct field in the bug form, we only and simply need to detected if there is a param target_relation with the same name.
and catch the rel_id ID to set as default.

In case of ajax this should be set in JS after loading of course, but its not a big deal at all

If you don't plan to do it,
I will modify the pick.php and related JS myself for my own, as I really need this.

Saddly all those codes are missing of hook actions and/or filters so we could add this out of the core.
Any plan to add more hooks in the code?

thanks

[renaudham]

By the way
quite important also more globally
you should offer an option also to HIDE the Add New button in case the form is in ADD mode and not in EDIT mode.....

[jimtrue]

Add New 'relationship' if you're allowed to do a multiple select will always be available, because you might be adding new 'child record'. When you're in the Child Record 'modal', the Add New is not available or that would take you into an 'inception' style interface. We only allow adding child records from the parent. Even if you are Editing the current record, you might need to Add a New Child record.

[renaudham]

Hi jimtrue.
Of course, I agree that on child modal form they always need to be hidden.
What I was meaning in my last point was about allowing in the main parent form
to show it but only in case of an EDIT form, and not when we are doing a Add new form.

Its already an issue in the current situation of your code, without changing anything.:

You add a new entity Project
in this one you have a field multiple bugs, with a ADD NEW Button
If you do Add new bug before saving your current project
then you will have a modal with a bug form and a Project selector.
But in this project selector you have of course ONLY old project pre existing.
And then the only thing you cuold do is add a new bug to on of the old other projects, with no relaionship with the current new object you are building.

This is a kind of usability non sens.

So we should allow a setting to show this button only in case of EDIT,
I believe that this is a usability need.

***Another note about code:
I see the new JS for this field is totally changing of logic with all that was existing before,
https://github.com/pods-framework/pods/blob/release/2.7/ui/js/pods-dfv/_src/pick/views/add-new.js using Backbone and a more complex structure behavior.
I understand your idea to make new elements this way,
but then could we know what tool you use to build the unique file pods-dfv.min.js from other files, is there some page with documentation on your new process?

[renaudham]

For info I managed very quickly to add the first part I was talking about

to have this url auto generated for the modal
wp-admin/post-new.php?post_type=bugs&pods_modal=1&rel_id=9&target_relation=project

just adding this

---

//ADDED BY REN 20170528
self::$type . '_set_related_auto' => array(
'label' => __('Add New > Auto set child related field', 'pods'),
'help' => __('On adding a new record, the related child field will be auto set to the value of the current parent', 'pods'),

            /*   'depends-on' => array(//array( self::$type . '_object' => 'user' )
                self::$type . '_allow_add_new'   => 1,
            ),

            'excludes-on' => array(
                self::$type . '_allow_add_new'   => false,
            ),*/
            'type' => 'boolean',
            'default' => 1,
        ),
        self::$type . '_related_auto_child_slug' => array(
            'label' => __('Add New > child related field slug name', 'pods'),
            'help' => __('On adding a new record, define the related child field slug name', 'pods'),
            'default' => '',
            'type' => 'text',
        ),

---

public function build_dfv_field_config($args)
{
.....
$iframe_src = '';

    // Potential valid modal target if we've set the file name
    if (!empty($file_name)) {
        // We extend wp.media.view.Modal for modal add/edit, we must ensure we load the template for it
        wp_enqueue_media();

        // @todo: Replace string literal with defined constant
        $query_args['pods_modal'] = 1;

//ADDED BY REN 20170528
if($args->options['pick_set_related_auto']==1){
$query_args['rel_id'] = $_GET['id'];
$query_args['target_relation'] = $args->options['pick_related_auto_child_slug'];//$args->options['name']; pick_set_related_auto pick_related_auto_child_slug

        }
     

        // $query_args['toto'] = 1;

        // Add args we always need
        $iframe_src = add_query_arg($query_args, admin_url($file_name));
    }

---

Note that the 2 extra config are not yet hiding/showing in case we use or not Add New button

But I think its the simple way to go
I will make the second part and share my idea, if usefull for anybody

[pglewis]

but then could we know what tool you use to build the unique file pods-dfv.min.js from other files, is there some page with documentation on your new process?

The build process is a moving target as we learn what is working well and discover new pain points. In depth documentation right now would likely be stale within a few weeks, a couple of months at most. (see: #4253, #4178)

The process is not at a state where third party code should rely on it, and providing any public documentation runs the risk of that happening.

[jimtrue]

@renaudham It actually sounds in the last several comments, that you're discussing a different requirement or potential enhancement to child relationships (almost a new capability or at least control scope). Might I suggest opening a new 2.7 Enhancement request so that your discussion doesn't get lost in this issue?

[renaudham]

Ok yes thanks

[sc0ttkclark]

Punting to 2.8 since this looks like a bit more effort. I'll make a task list though

[quasel]

For Bi-Directional Situations

• Parent
  • if the parent item isn't saved add a warning/hint and disable AddNew
• Child Modal
  • preselect the child's relation to the parent
  • if the child's relation is single select hide it ( Hide bidirectional relationship field from Flexible Relationships 'Add New' #4567 ) or just "disable it"+hint text - for consistency

[renaudham]

Hi

As I understand the version 2.8 under beta should offer a solution for this?

I have done my own fix for this

Child Modal

preselect the child's relation to the parent

but I hope the new version will allow me to have it also.
How could we test this new feature?

-For my side the solution was very simple,
(not trying to check if the parent is saved yet or not but it could be added by some lines of JS)

in pods-dfv.min.js
modifying - "onChildviewAddNew: "

 onChildviewAddNew: function (e) {
                var t = this.model.get("fieldConfig");
                t.iframe_src=t.iframe_src+"&"+t.pod+"_id="+t.item_id;
                N = new g({title: t.iframe_title_add, src: t.iframe_src}), this.setModalListeners(), N.modal.open()
            },

Result: adding a variable in the url of the modal opened, getting automatically the current parent pod type and post id

in my case
admin.php?page=pods-manage-client_childs&action=add&pods_modal=1**&user_id=457**

then you just need to set in the child bi -directionnal field, in the child form, this
Tab advanced > default value = {@get.user_id}

and it all works quite well

[jimtrue]

@renaudham No, at present, we haven't provided or coded a solution to this yet. That's what we're asking you: If you have indeed modified the core code to create a solution for your situation, we're asking you to provide that code for review (as a Pull Request against our code) so we can incorporate it into Pods and credit you for the work.

[renaudham]

Hi Jim
I could do this, just waiting to see your idea on what I added that you can see on my comment 1hr ago, above.

Its really basic
and then could be used only with some documentation because the user needs to know how to set up the child default value,

and its not yet handling the case when the post is not saved yet but I could add it easily.

I wait to see for your comments. Not sure if its usable by anybody...

Thanks

[jimtrue]

That would have to be up to @sc0ttkclark and @pglewis to decide. I'm not a developer so can't review whether your implementation makes sense or not.

[KarlBaumann]

Any ideas when this might be implemented? Or is it available already?

[JoryHogeveen]

Punting to 2.8 as @sc0ttkclark mentioned before: #4249 (comment)
This issue shouldn't have been punted to another version.

[sc0ttkclark]

This one didn't make the 2.8 cut-off, will push this to the next available release.