Related data - field not displayed when access form-view=special

[blue-mouse]

Hi,

I have a problem for all my lists (parent + child, left join) where i use "Related data"---Form.

I have a problem on "Related form" with a field that is used for left-join-connection.

In an example list CC-19 this left join is:
left JOIN ccjom_cc_srodki_ochrony_wymiana ON ccjom_cc_srodki_ochrony.id = ccjom_cc_srodki_ochrony_wymiana.nazwa

Problem is with field: ccjom_cc_srodki_ochrony_wymiana.nazwa ----- "Nazwa --"

I need 2 different cases:
1. Picture: Zaznaczenie_51 ----> "Nazwa --" - Form view - Special
Picture: Zaznaczenie_52 ----> "Nazwa -- " - should be displayed, but not editable ------------------
but "Nazwa -- " is not displayed in this case

This is more important for me.


2.
1. Picture: Zaznaczenie_51 ----> "Nazwa --" - Form view - CC-ISO-Pracownicy-p = CC-ISO-Our_workers_level
Picture: Zaznaczenie_52 ----> "Nazwa -- " - should be displayed, and editable----it-is-databasejoin---- should be possible to change to other value ------------------
but "Nazwa -- " is possible to change to other value from dropdown --- but when "save form" then the other value is not saved/changed - is saved only old value - this what was opened when click "Related Form"---"dodaj wymian?".


Is possible to solve this?
This is very important for me.

 

[blue-mouse]

Friendly bump,

 

[blue-mouse]

Friendly bump,

 

[cheesegrits]

So in case 2, are you saying you need to change the "parent" of the related form. So you want to edit the "child" record in a one-to-many join, and change the FK to point to a different parent? And that this doesn't work, but only when you access it as related data?

I'm setting up some test cases now.

-- hugh

 

[blue-mouse]

Yes, in case 2 problem is only with form that is related-form. When do the same from list that is not Parent+child and that includes the same records as childs on list_parent+child then all work.

 

[troester]

About your case 1:
I assume the read only element is empty if you are ADDING a record (not if you are displaying an existing one)?
This is the expected behaviour - you can't fill a read only element via a URL parameter because of security reasons (everyone would be able to override every element).
You have to set the default value of such a readonly element. You can set it to the URL parameter with

$app = JFactory::getApplication();
$input = $app->input->get('your-table___element_raw','','int');
return $input;

 

[blue-mouse]

troester:
I try in edit element ---> options ---> Eval default - Yes
Default - Your code
see screen-shoot
But this doesn't work

I get still empty field "Nazwa -- "

 

[troester]

The placeholder must be the element name of your dbjoin itself (the element where you are defining the default, i.e. the element 7066, tablexxx___nazwa_raw), not some element this dbjoin is pointing to.

 

[blue-mouse]

Thanks troester - this - case 1 - works !

 

[cheesegrits]

I'm having a hard time working out a way round case #2. It's fixed in Fabrik 3.1/2, but in a way we can't back port to 3.0.

The problem is that that when you preset a value when loading a new form with a query strings value, which is how we do the related data form thing, by adding &othertable___parent_id_raw=123 to the URL to pre-set the FK, that raw value stays in the query string in the request array when the form is posted, and overrides the POST'ed value in the form itself.

We never really considered that a "bug", as nobody ever had a need to change an element that was being preset on the query string. We tend to consider "preset" as being different to a "default", the difference being that defaults should be changeable, presets should not. And in this specific case, of using the related data feature, we really don't really see it as being a "problem", as if the user wanted to choose a different parent for the new form, they can just click the "New" button on the row they wanted it to be created in, in the first place.

In 3.1/2 we have a mechanism to work round this, which adds a couple of options to the getValue() method in the main element model(s), so the calling code can specify whether they want raw value son the query string to override the posted data. But this isn't back portable to 3.0, as the whole getValue() method, and some other associated code, has been entirely rewritten, in a way that wouldn't work in 3.0, and it's only that rewrite which allows us to do that.

I spent about 2 hours looking at this last night, and I'm afraid I'm going to have to say this can't be done in 3.0. There is one possibility which wouldn't be too hard to code, but it's a change which would require a lot of testing to make sure it had no other unforeseen side effects, and it just isn't something we could do as part of "standard support".

-- hugh

 

[cheesegrits]

PS, it might be possible for you to work round this on a case by case basis, by adding a PHP plugin running onBeforeProcess which removes the _raw from the request array, but I have a feeling that by the time onBeforeProcess runs, the $formModel->_formData[] array will have already been set with the "wrong" value during validation.

But it would certainly be worth trying, and just do a ...

var_dump($_RQUEST, $formModel->_formData);exit;

... to see if the non _raw value the user set is still in either array. If it is, then you can fix it.

Although the caveat there would be that the "new" value is not the one which would have been run through validation.

-- hugh

 

[cheesegrits]

Hmm, I checked, and by the time onBeforeProcess runs, the damage would already have been done, setFormData() will have been run, and the _raw value will have been used to overwrite the posted data.

And there is currently no plugin hook which runs before validation that we can use.

But ... I'll do you a deal. If you take out a Pro sub, I'll take the time to add an onBeforeValidation hook to the code, and add it as an option to the PHP form plugin, and help you write a plugin which would do what you need, by removing that nazwa_raw value from the request array before it gets seen and used by the form submission code.

-- hugh