[SOLVED] Issues setting a value of a protected field using JavaScript

Status
Not open for further replies.
This is my form:

1.png

When the user inserts a date in Attivato il, I want fill Attivato da with the current user using JS .
Attivato da is a DatabaseJoinElement linked to _users table, displaying name.

I tried reading the value of Utente ultima modifica that is a User plugin with option Update on edit, Form (add) = Superuser and Form (edit) = Superuser (so normal users cannot modify).

I became mad (1 day!) before understand that JS doesn't return the raw value (it gave me error) but only the the name without _raw.

So I added id_utente_corrente Hidden (in the screenshot is displayed to explain better); the result is very very strange:


2.png
...(all numbers)...
3.png
It is first time I see this...

It works well (the name of user is displayed) if I set Attivato da as Form (add) = Registered and Form (edit) = Registered.

I have just updated (this afternoon) to J! 3.4.3 and Fabrik from GitHub (downloaded this afternoon).
How can I solve/work around?
 
So from what I can understand you are trying to copy the value of a user element, to a join element?

Personally i wouldn't use Javascript to do this, I'd use a PHP form submission script. But if you want to do it with JS ...

When rendering the user element, if it's read-only, we will only display the "label", not the "value". So if you've set it to show the username, you'll only get the username in the element on the page.

So in order to do this, you'll need to set the user element you are copying form to display the ID, not the username. You may need to create a second user element to do this, if you need to display another one with the username in it.

Using my fab_fx_test form as an example, here's how to get the userid:

Fabrik.getBlock('form').formElements.get('fab_fx_test___userid').getValue()

... which returns an array (the user element is an extension of the join element, for which the data type is an array). So the value you want is the first (and only) value in the array:

Fabrik.getBlock('form').formElements.get('fab_fx_test___userid').getValue()[0]

... then you can set your join element using the update() method, like this:

Fabrik.getBlock('form').formElements.get('fab_fx_test___user_join').update(Fabrik.getBlock('form').formElements.get('fab_fx_test___userid').getValue()[0]);

Obviously substitute your full element name.

http://screencast.com/t/pd73J6Sc33

-- hugh
 
Hi, Hugh.

Until now I used Fabrik.getBlock('form_x').elements.get()...
I didn't know the notation Fabrik.getBlock('form').formElements.get()...
This notation avoids modifications of copied forms/elements.; very good.

I am sorry, but:
I tried
Code:
var attivato_il = Fabrik.getBlock('form').formElements.get('fabrik_soggetti___Attivato_il').getValue();
var id_utente_corrente = Fabrik.getBlock('form').formElements.get('fabrik_soggetti___id_utente_corrente').getValue();
 
alert(Fabrik.getBlock('form').formElements.get('fabrik_soggetti___id_utente_corrente').getValue());
alert(Fabrik.getBlock('form').formElements.get('fabrik_soggetti___id_utente_corrente').getValue()[0]);
 
 
if(attivato_il !== '')
  {
    Fabrik.getBlock('form').formElements.get('fabrik_soggetti___Utente_Attivazione').update(id_utente_corrente);
    Fabrik.getBlock('form').formElements.get('fabrik_soggetti___Attivo').update('Si');
  }
else
  {
    Fabrik.getBlock('form_40').elements.get('fabrik_soggetti___Utente_Attivazione').update('');
    Fabrik.getBlock('form_40').elements.get('fabrik_soggetti___Attivo').update('No');
  }

The first alert shows 805, that is right; the second 8, that is wrong.
The statement
Code:
Fabrik.getBlock('form').formElements.get('fabrik_soggetti___Utente_Attivazione').update(id_utente_corrente);

works right if I set Attivato da (fabrik_soggetti___Utente_Attivazione) as Form (add) and Form (edit) = Public/Registered (as the user can modify);
but, if I set it Form (add) and Form (edit) = Superuser (the user cannot modify), I get what you see on screenshot (all numbers 0 --> 804).
 
OK, well that makes sense. If it's only editable by Superusers, then normal users can't modify it. Doesn't matter whether it's being set by "hand" or through JavaScript. The form submission can't modify it period. Our form processing on the server side won't even include any read-only elements in the database update query.

So you have two options. Either make that element writeable but hide it, or do this as a PHP form plugin.

-- hugh
 
I'm sorry, Hugh, but something doesn't work.

As you suggested, I added an hidden field id_Utente_Attivazione_Nascosto (not in the screenshot, to show you).Ashampoo_Snap_2015.07.14_18h50m52s_005_.png

Using JS, when a date is inserted in Attivato il, id_Utente_Attivazione_Nascosto is set; it works, as you can see.
Attivato da is a Calc element, setted as:
Calculation: return '{fabrik_soggetti___id_Utente_Attivazione_nascosto}';​
Only Calc on Save: NO​
Ajax calculation: Yes​
Calc on load: Yes​
but Attivato da is not shown when id_Utente_Attivazione_Nascosto changes; it is shown if I save and load the form.
I use the Calc element in other forms and it worked; I didn't check if it works now.
 
I don't think setting the nacosto element by hand will trigger the change event that the calc watches. You'll have to trigger that by hand.

-- hugh
 
I don't think setting the nacosto element by hand will trigger the change event that the calc watches.
I tried setting id_Utente_Attivazione_Nascosto by hand and Attivato da (Calc element) works well: it changes immediately, before saving.
 
I'll need to see your page to get any further.

However, I still think JS is the wrong place to do this, you should be doing it in a form submission plugin.

What I would do is have a hidden element, like date_changed. WHen the date gets changed, a simple one line of JS to set that to "1".

Then in a form submission plugin on onBeforeProcess, check to see if date_changed is "1", if so, use $formModel->updateFormData() to set the user element to the logged on user, and set date_changed back to 0.

Trying to do it in JS is, as you have discovered, like trying to hammer a round peg into a square hole.

-- hugh
 
trying to hammer a round peg into a square hole
It's a amusing mental picture :)

I'm sorry, but what you suggest isn't the solution to get what I need because the value is set after the form submission, not shown at the moment to the user.

If I may take the liberty to say, I suggest to you ("you" = "all developers") to consider to standardize the options of all the elements: some element has a lot, some others not; in this case, the option Read only (as field element) would be the solution.

Another example (it is the first that comes to my mind) is the internalid element: why is the only one (if I remember well) that I cannot choose if display on form? Sometime it is necessary.

In any case, thank you, Hugh, for your time.
 
The problem with Read Only is that it uses the "disabled" attribute, which makes input fields unchangeable, but still submit their data. The point of "Read Only" on field elements, as opposed to using the ACL's, being that you can still change the value through JavaScript. But this doesn't work for anything that uses a SELECT form input, as opposed to a simple input field, because SELECT doesn't have a "readonly" attribute, it only has "disable". Which looks the same (a greyed out, non-changeable rendering), BUT the value doesn't get submitted with the form. So to try and do a "Read Only" mode for things like checkboxes and dropdowns is extremely problematic.

As for the internal ID, the whole point of that element is to hide it, and not let anyone do anything to it, which for 99% of Fabrik use is the correct approach. If you need to display it, you can simply change it's type to a simple field element, set to Integer.

As for your actual issue ... if you need to give your user the warm and comfortable feeling of seeing their name in the "Changed by" (or whatever it's called), you could always fake that with a junk element you simply stuff their username into (maybe a calc), and show that when they change the date. But do the actual work with a user element in the form plugin.

The reason I'm pushing the form plugin is, we have a mechanism baked in to the $formModel->updateFormData() method that allows you to override the values of what would otherwise be ACL protected elements. So where you cannot change the value of an element with ACL's set to Administrators through the client side form, you *can* change it with a PHP plugin.

-- hugh
 
Status
Not open for further replies.
We are in need of some funding.
More details.

Thank you.

Members online

No members online now.
Back
Top