Inserting Primary Key (ID) into Another List/Element

[talkinggoat]

I have two lists, one is a master, the other a child. The master holds the records for the individual being served. The child holds the records the operator who will be serving. In order to associate the two, I need an inner join, which I think I know how to do.

Here is what I haven't really been able to figure out:

The master and operator records are joined, on the same form, so when the operator record is written, it needs to index the master record (id), so the join knows how to associate them. For instance, if we're working with ticket #4 (which is the primary key in the master record) and operator Bob is assigned, there needs to be an association with ticket #4 in the Operators list. How do I tell Fabrik to stick that PK into the Operators list? Is this going to be a script or is it already available in the Fabrik settings?

Thank you.

 

[talkinggoat]

I don't know if this is the correct way, but, here it goes.

In the Operators list, I made an element called "Master Ticket" and put {rescue_requests_2___id} into the "Default" section. This grabs the master element's ID and copies it to the element "Master Ticket". You can then make "Master Ticket" a hidden field.

and joined the element ID of the master list to this element.

This created a copy group of all the elements in the Operations group.

I also changed it from inner join to left join. For noobs, like me, if you only use an inner join, you'll not be able to see all your master list records, just those associated with each other.

By copying the master ID to the Operations list, I can now associate tickets with operators.

@cheesegrits @troester Please let me know if there's a better way to do this.

 

[cheesegrits]

You don't need to default the FK. Once you've made a list join, Fabrik automatically handles setting it, assuming you are adding the child (tickets) as part of the repeat group on the master form.

If you are adding tickets directly on the Tickets list, the than master id placeholder won't exist. In that case you'd typically make the FK a join to the master, and select which master you want the ticket to be part of. One note in that scenario, you'd have to "unlink" the two copies of the FK element, and leave the one in the copy of the group that forms the repeat group on the master table as a hidden field.

The only time you'd use that element default would be if you were linking to the ticket form from somewhere else, where you know the master ID, and can add it to the query string. Then you use a little PHP, like ...

return $this->app->input->get('master_id', '');

... which would pick up a &master_id=123 on the URL.

-- hugh

 

[talkinggoat]

@cheesegrits what I've currently got is a list that shows up as an injection into the intro of the group that the join created (rescue requests 2 (operations)). That shows the list of boaters assigned to the Rescue Request's ID, which we'll use as the Ticket number (Below).

What I want is when the dispatcher changes or adds the name of a rescue boater to the ticket, (#1) and clicks Save (#2) it creates a new entry in the Operators list, with a new ID. (#3). It is assigned to the Master ID, which is the Ticket Number, here. Instead, it just updates the ID. This is probably normal behavior. If nothing changes in the Operations list and they change something else, like the Number of Children, when the dispatcher clicks save, nothing should be updated in the Operations list. Of course, the normal user won't have the ability to make any modifications to the list or add to it, directly, just through the form. The only reason you can see the Edit, View and Delete icons is because they are assigned to my account.

The master ticket's ID is joined to the Operations Ticket #, through a left join. I made the group repeat, in case there is a need to add more than one rescuer.

Am I going about this the right way, or is this completely wrong?

 

[cheesegrits]

Hmmm, that's problematic, because you can't embed lists inside forms. I'm surprised that works at all. The problem being that Fabrik lists are wrapped in HTML forms (all the controls on a list are form inputs), and HTML doesn't allow you to nest form tags. It's possible to customize a list template not to use the form tags, if you don't need any of the inputs (filtering, pagination, etc) ... and maybe you've done that?

Maybe I'm just confused, but I don't understand why you are embedding a list, why that embedded list isn't just the repeat group. But it's really hard to understand someone else's app design just reading a brief description in the forums.

I think really the only way I can help is if we schedule some time to have a hands-on session where you walk me through what you've got so far. Unfortunately I'm kinda slammed this week, I have to drive to Houston on Thursday (a 12+ hour drive), and have some stuff I have to wrap up before then.

Where are you located? I'll be coming down 59 to New Orleans, then 10 through Baton Rouge, etc. If you aren't too far off course, it's conceivable I could stop by. I could use a break on that drive anyway. I had planned to leave here Thursday late evening, so passing through New Orleans around breakfast time (so I can get a decent breakfast!), but I'm flexible. I just need to get to Houston early enough to get a solid 12 hour downtime before JDay on Saturday.

-- hugh

 

[talkinggoat]

@cheesegrits I modified the list with a custom template/layout to exclude the <form> tags; we won't need the controls there, anyway and it was causing an issue with the form. They are only displayed there, because I gave superusers access to them. It's more to display the log of rescue workers assigned to the ticket, than to be functional, as an editing tool, in that location. For the average user, it's supposed to be read-only, so we know who is assigned to the rescue ticket.

We'll also need another section to display what dispatcher(s) are assigned, as well. It will basically just be a repeat of what we're trying to do, here, so I have to get this part right.

Section #1 is where we're adding rescue workers to the list. It should only add, when there is a change, that way, it's not adding blank lines or multiple copies of the same boater, when the ticket is saved, in section #2.

Whew, yeah, that's a long drive! From here, it's another 4 hours. I'll send you a PM.