1. Fabrik 3.9 has been released. If you have updated Joomla to 3.9, this is a required update.
    Dismiss Notice

Modify IP element value on submission

Discussion in 'Standard Support' started by Incremental, Dec 8, 2013.

  1. Incremental

    Incremental Member

    Level: Community
    I'm developping an event registration application and I would like to get and update User IP.
    I want to avoid IP modification if the administrator is modifying the record.

    In my Form I set a PHP plugin (onBeforeStore) modifying the Form IP adress without effect. The Form IP is stored.
    $formModel->updateFormData('inscriptions___IP_Address_raw', '', true);
    I also tried with 'inscriptions___IP_Address' without success.

    If I insert
    echo "<pre>";print_r($formModel->formData);exit;
    the IP shows but he table stores the first IP.

    What could be wrong ? Thanks
  2. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    Do you have 'update on edit' set to Yes? If so, we ignore the posted data (i.e. previously saved value) when we save the IP element, and use $_SERVER['REMOTE_ADDR'] instead, so changing the posted data in a plugin won't have any effect.

    So you'd need to set 'update on edit' to No, and handle the edit logic in your plugin.

    Or not use the IP element at all, make it a simple field element, and handle it all in your plugin.

    -- hugh
  3. Incremental

    Incremental Member

    Level: Community
    Thanks cheesegrit
    I changed 'update on edit' to NO.
    I had not understand that it was for the Edit button used by admin.

    I would like to prefill a list with some user data and send to each, a link to the record.
    Then each user would be able to correct his data.
    I'm wondering if the IP could be then updated by the user (hidden information).
  4. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    Well, it doesn't matter who is editing it, or which link they used to get to the edit page. That option just controls whether the element only records the IP when that record is first created, and never updates (so it's a "which IP created this row"), or whether it changes every time the row is saved, so it shows "which IP last edited this row".

    Hmmm. You might be able to achieve this with normal ACL's. If you assign "Form view" access to a viewing level which ONLY has the normal users in it, not the admins. So admins wouldn't have edit privs on that element. And set "Update on edit" to Yes. That might do what you need without any custom scripting. But I can't promise anything, as the IP element doesn't do things quite like other elements.

    If that doesn't work, then I suspect that the easiest way to do this may end up being my suggestion of just using a field element, and do all the IP assignment in a plugin.

    -- hugh[/quote][/quote]
  5. Incremental

    Incremental Member

    Level: Community
    Thanks Cheesegrits,
    ACL could be the solution and I always neglect it !!!
    Ideally for my app it would be better to condition IP update on "non-Admin" profile.

    I tried with IP element and ACL and I have a strange behaviour with List View button :
    As my database has empty IP (displayed as is in the list) when I click on view, IP element displays my current IP, not the one stored.
    • Update on edit : YES
    • Access Form Add : Admin
    • Access Form Edit : Public
    I can understand that it displays my IP, based on your preceding post, but not in VIEW mode which should display what is in database.

    In fact, I would like to implement "which IP last edited this row" BUT NOT "Admin".
    Public can only edit their data through a dedicated Form
    Admin only use List appearing in front-end when logged as Admin.

    It doesn't work, if Admin edit the row : IP is updated with Admin IP.
    Does Admin privilege override Public ?

    Then I will use a regular field. But how could I block the update in my PHP form, detecting that the current user is "Admin" ???
    I found the placeholder {$my->groups} but if you haven't a better idea, it's not very user friendly as it's an ID.
    By the way, not all placeholders as described in the wiki are working. most of the returns a string with their name :(
    (It would be an overkill to add an ACL Access in plugins (at least PHP and JS))
  6. Incremental

    Incremental Member

    Level: Community
    Friendly bump ;)
  7. Sophist

    Sophist Well-Known Member

    Level: Community
    Based on my knowledge of your site, I think this is one where it might make sense to create a new Viewing Access Level (called "NotSpecial") with the opposite user groups checked to the VAL Special.

    The you can see the Details ACL for the IP element to Public (so everyone can view the IP address read-only) and the Form Edit ACL to NotSpecial - and then Special users should only get read-only access.
  8. Incremental

    Incremental Member

    Level: Community
    for Public, display of IP should be completely hidden, as it has no interest for users.
    The preceding topics are relating to IP-plugin automatic updates and when these updates should be possible.
  9. Sophist

    Sophist Well-Known Member

    Level: Community
    Yes - and there is a hidden=yes setting on ip elements which will hide it from view.

    But that is different from deciding which elements will be updated when. If you want to log which non-Admin user has edited the rows, but you want to allow updates to change the IP stored, then you cannot use update-on-edit=No. So the only way of stopping it being changed is to use ACLs, and so you need to make the element accessible by all non-Special users and not-accessible by Special.

  10. Incremental

    Incremental Member

    Level: Community
    I understand.
    I created a Not Special ACL with Public and Registerd. Is it correct ?
    And set it to IP element Form Edit. Form Add and Details are public.
    IP stored is public and not modifiable in the form.

    1) On administration side, when Edit : IP is read-only (OK) but the value stored in the DB is not displayed. I just get my IP.
    You can check it, I've set to all records in the DB.

    2) As IP is still visible in my Public form, if I set some javascript to hide it on form load, will it avoid IP storing ?
  11. Sophist

    Sophist Well-Known Member

    Level: Community
    Well - you now have several new View Access Levels, and have changed some of the default VALs too. Personally I think this is becoming somewhat messy, and think you should:

    1. change FabrikSpecial back to Special, FabrikNone to None, and FabrikNotSpecial to NotSpecial.
    2. remove Manager user group from Registered VAL (goodness knows what this does to normal Joomla functionality)
    3. remove FabrikAdmin user group entirely as this is essentially the same as Super Users.
    4. remove FabrikAdminForm VAL entirely and use Special instead.
    5. add to NotSpecial all User Groups except either Super Users or any groups which are children of SuperUsers.
    You should not change the default VALs which come with Joomla unless you fully understand the impact changing them will have on Joomla itself. Personally I think you should only add new VALs if there is a specific need which is not met by existing VALs.

    (So for example on the site I am developing, I want to register two types of users Customers and Staff, which will have specific access which is different from any existing Joomla groups i.e. from a CMS perspective they will only be like Registered users, but from a Fabrik perspective they will have different capabilities to either normal registered users or each other - so I have created two new groups and two new VALs. But in your case, your Fabrik Admin / FabrikAdminForm is identical to SuperUser / Special.)

    For IP element:
    1. I think that there is a bug preventing the element being shown read-only (like other element types are) on Form Edit if ACL for Form Edit is invalid and ACL for Details is valid.
    2. Since the IP element is updated on load, you probably need a calc element which is a copy of it and which is updated only on save in which to store the old IP address.
    But as I have said before, using the same record for a reply is probably not the way to go - perhaps you need a Related Data relationship to hold replies in a separate but similar list. Or just use the contact form for the customer to send you an email, and use your email system to reply.

Share This Page