Something is not right with SafeCracker and relationships, or with the way I’m creating add/edit forms.

I created forms that create a hidden relationship for the customer (in EE 1.6x), in SAEF/Form Helper.  It was accomplished by having them click on a permalink within the parent record (outside of the related entries portion)... that put the entry_id of the parent record in the hidden relationship field of the new child record, essentially:  {permalink=group/addformname}. 

The customer never knew they were doing this.  They’d never have to deal with drop downs/drilling to find the records they needed.  We’d never have to worry about screening out only their own records, as the links to the associated entries were next to the parent records (that were only their own).  (I can’t take credit for this.  It was a trick I learned from Mitchell at Solspace.)

Similarly, if the customer needed to edit the child records, the edit links were located within the boundaries of the parent record, again, only their own, so only their own records appeared.

I realize that I can’t have one add and edit form for this because of the entry_id—no biggie.  Two forms in SOME cases, where I ALWAYS used to have to have two forms, is a situation I can live with.

In the add form, I pick up segment_3 for the relationship field (because it is a permalink from the parent record), and I dropped most of the variables from the safecracker code, especially entry_id=”{segment_3}”.  I can see that the correct Entry ID is in the relationship field (because I haven’t hidden it yet, so I can see what is being placed there).  I save it.  I checked the database. 

Relationship Table After Add:
rel_id, rel_parent_id, rel_child_id
333, 1821, 1435

After Edit:
rel_id, rel_parent_id, rel_child_id
334, 1821, 0
335, 1821, 333

Unfortunately, all of that is wrong.

After add, the initial record should have been:
333, 1435, 1821 (the parent and child record were transposed)

After edit, new entries shouldn’t have been created and the initial deleted.  I don’t know if the correction of the first problem would eliminate the second.

Can you let me know if it is a problem with my method, or if there is a problem with the way Safecracker is saving relationship data?

You should omit the field totally on edit, this way, the original value is preserved. Try that first and see what happens. I have had other users successfully use hidden fields to create relationships, so I am sure that relationship data gets saved properly.

Even so, isn’t it still recording it backwards?

The parent is the entry you’re creating, the child is the entry you’re referencing.

You’re right.  Sorry.  Backwards from the way we think of it.

Yeah, I see why you’d think the one you’re setting is the “Parent”, it makes more sense to think of it that way, but as far as the database is concerned it’s the child

Rob Sanchez - 23 February 2011 11:51 PM

You should omit the field totally on edit, this way, the original value is preserved. Try that first and see what happens. I have had other users successfully use hidden fields to create relationships, so I am sure that relationship data gets saved properly.

Just wanted to follow up with a solution that works.  It may not be the ONLY one, but it was the only one from a VERY long list I went through.

I tried the one you suggested (omitting the field from the edit form) and it didn’t work. It set the relationship field value to nothing (blank).  Not only that, it didn’t save any of the other edits made in the form at the same time (very rude behavior).  I tried playing with the other parameters, but nothing seemed to fix it.  (I even tried switching from a vanilla relationship field to a Playa field, but couldn’t find a way to set the value when it was hidden, but it handled not being invited to the edit form quite nicely.) 

Anyway, to save someone else from being up all night, the solution is to keep the relationship field in the edit form (but a text=“hidden” field won’t work). It works on the add, but will not work on the edit (CRAZY!).  You have to use a div to hide it.  Something like:

#hiddentext {
display: none;
}

Then, using your elegant {field:custom_field_name} and that hidden div, the field will retain its original value, but still remain hidden from the user. If this was something super top secret that the user really shouldn’t see by clicking “View Source”, this solution probably wouldn’t be the answer, but then, if this was something really super double-top secret, I doubt they’d be using HTML and the Intarwebs (or we can HOPE!).

Bed time!  Finally.