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

table editing problem

Discussion in 'Fabrik 2.0 Beta Testing' started by jc513, Oct 27, 2008.

Thread Status:
Not open for further replies.
  1. jc513

    jc513 New Member

    Level: Community
    Updated to SVN 627 to fix an element type user problem now I have a bigger problem.

    Creating the first record for the table is no issue. Editing that record, either through the front-end or back-end, causes a hidden user element type 'id' to be blank and the default values of the element to become the new edited value. Looking at the schema, the time_date is also NULL -- not populated like the other table I have. The table has a prefilter to show only records if the registered user matches the 'id'. When it blanks out after the edit the user can no longer see their data. Element is set to 'No Update on Edit'. If edited on the back-end the id field blanks and another element type user called username changes to the backend account making the the change even though the field is also set not to update on edit. Is it suppose to do that?

    In addition, an older table created circa SVN 573 is no longer editable, though the new tables created with SVN 625 do show the edit functionality. The edit label shows up but no edit link. Rolling back to SVN 573 and this table is now editable (link available). So somewhere between SVN 573 and SVN 625 my table edit functionality stop for this particular table.

    Any idea?
     
  2. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    OK. I don't have any pre-573 tables, as I had to blow my site away and recreate form scratch a week or so ago. So it'll probably be tomorrow at the earliest before I can test this one, as I'll have to create a sacrificial instance of J! to test it in. My main test site is also my main SVN checkout, which always has changes I'm testing and haven't committed yet, so I can't roll it back.

    -- hugh
     
  3. jc513

    jc513 New Member

    Level: Community
    Update...

    My older table (circa SVN 573) had the 'fabrik_internal_id' element listed in the elements menu. The newer tables have it within the schema as well but they are not showing up in the elements menu list. Presumably this visibly listed element was added automatically to my older table because I don't remember adding it and haven't added it to the newer ones. There is a 'fabrik_internal_id' and 'time_date' element not assigned to any grouping - presumably default for the install. If I set 'Show in Table' in the element the columned auto number displays providing a link to edit each record. The edit column is there but blank. If I "Don't publish" the element then the Edit column is populated with the link and word Edit. All this testing was with SVN 627.

    Is this by design because I didn't have have to un-publish the element in SVN 573?

    As for other issue of I editing an existing record on the table that is restricted to only show records for that particular user the hidden element id value blanks and the new values now become the default values for those edited elements -- I still have no clue.
     
  4. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    All tables created with Fabrik should have a fabrik_internal_id and a time_date element, and they should be assigned to a group on the form (usually the first group listed for that form). You must not unpublish them, although they can be hidden on the form and table.

    The fabrik_internal_id should almost always be the primary key for that table, with auto-increment enabled, unless you have good reason to use some other element as the PK.

    -- hugh
     
  5. jc513

    jc513 New Member

    Level: Community
    Understand.

    With element published I can not edit - unless I have 'show in table' selected. With the element unpublished I can edit. Adding a new record with the element unpublished STILL auto increments the fabrik_internal_id count. Strange.

    Update...

    Found that I have SVN 589 stored away on my hard drive. Put it on. Still able to have the EDIT option with the fabrik_internal_id published. Updated to SVN 630. No change in original problem.

    Problem must be between 589 and 625 for this issue.

    On the other issue, editing the userid field when set 'Not to update on edit', only works with the SVN 573 I have. SVN 573 still writes the new element value as the default value for that element for the next ADD. At least this code version does not blank out my userid field on an edit nor update it to admin if I edit in the back-end. Hope this helps.
     
  6. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    I'll leave this one for Rob to deal with. Sounds too much like hard work to me. :)

    He should be back Wednesday, although it'll probably take him a day or two to get caught up.

    -- hugh
     
  7. jc513

    jc513 New Member

    Level: Community
    Update...

    Issue 1 -- No Edit Link

    No occurring...Updated to SVN 636 and now the older table has the edit link showing even with the published set. No more an issue for me anymore.


    Issue 2 -- userid field going blank when 'Update on Edit' set to no

    Still occurring....After trail and error I have found that if on the Publishing tab if the 'Access' and 'Read Only Access' are not set equal to or lower than the editing account it set the value blank. The functionality question is if the value is set to 'NO' on the 'update on edit, why is it changing? Editing it from the back-end changes the values to admin.


    Issue 3 -- default values changing on edit

    Still occurring...On the edit of the table, the default values of the elements type as integers are changing from nothing to the newly entered values. This is only occurring on that table where Issue 2 exist. Maybe a correlation on updating all values.
     
  8. jc513

    jc513 New Member

    Level: Community

    Updated to SVN 695...Issue 2 does not appear to be occurring anymore. Thanks!

    Issue 3...still happening. Whatever the lasted edited entry for the element was it is saved as the default value for the edited element. When a "new" form is used, these wrong defaults show up for the user (which are suppose to be blank).
     
  9. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    I'm not entirely sure what you mean with issue 3. Are you talking about the back end, or when creating / editing a form on the front end?

    -- hugh
     
  10. rob

    rob Administrator Staff Member

    Level: Community
    think for 3 i have this fixed locally - I've made quiet a lot of changes for a site I'm working on. I'll commit them when its done
     
  11. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    Ah yes. The Big Commit. "Just when you thought it was safe ...."

    -- hugh
     
  12. jc513

    jc513 New Member

    Level: Community
    I will wait for the next SVN. Using SVN 698 now.

    In the meantime I will try and get this a short as possible to give you a better understanding to make your fix matches my issue.

    I have a table consisting of 6 elements (+2 default internal_id and date_time).

    element_1:type=user:hidden:user data=ID:update on edit=NO
    element_2:type=user:hidden:user data=User Name:update on edit=NO
    element_3:type=text field:width=20:default=null:max_len=50:format=text
    element_4:type=text field:width=3:default=null:max_len=3:format=integer:int_len=3:sum total=yes
    element_5:type=text field:width=3:default=null:max_len=3:format=integer:int_len=3:sum total=yes
    element_6:type=text field:width=3:default=null:max_len=3:format=integer:int_len=3:sum total=yes



    Table is set to filter records to only show record(s) of logged in ID if ACL is less than Publisher. Only registered user have access.


    User 1 logs in and goes to the form. Form comes up with all element fields empty. The desired state. User 1 adds data to the fields and submits.

    User 2 logs in and goes to the form. Form comes up with elements 4,5, & 6 with the values entered from User 1. Not the desired state. Element_3 is still blank. The desired state. If User 2 submits changes, elements 4, 5, & 6 now have the values of the change as the default value.

    Log in the backend as the admin and view elements 4,5, & 6. Default is now saved as the last submitted value. Edit the table on the back end and same issue occurs.
     
  13. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    Try updating to the latest SVN again. Rob finally did The Big Commit of changes he made for Linux Expo, and which he thinks might fix this issue. I think the rev# for The Big Commit was 702.

    -- hgh
     
  14. jc513

    jc513 New Member

    Level: Community
    Using SVN 704 now....Ah...alas...no change in the problem. The last users entries are still being set as the default for the element.
     
  15. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    Strange, I can't duplicate this at all.

    How are you testing this? Are you using the same browser on the same machine, logging out and logging back in as user 2? Or logging in as different users in different browsers (but still on the same machine). Or is this happening "in real life" with different users on different machines?

    I'm trying to simulate different users by logging in as different users in different browsers (so User1 in FF, User2 in Chrome and User3 in IE), but my forms all correctly show the expected default browsers.

    I'm also a little confused by this:

    Are you saying that the actual 'Default' value under the element options on the backend has been changed to whatever the previous user submitted with their form? If so, can you PM me a superadmin backend login? This I must see! I can't even begin to imagine how that would be happening.

    -- hugh
     
  16. jc513

    jc513 New Member

    Level: Community
    I am hoping a picture is really worth a thousand words and one easy solution.

    I am working on an internal test site so none of this is live. My test have been in the form of a varity of methods -- same browser-same machine, IE7 for user 1 FireFox3 for user 2-same machine, same browser types-different machine, different browser type-different machines.

    Let me know if you need more information.
     

    Attached Files:

  17. jc513

    jc513 New Member

    Level: Community
    More Pictures



    __________________
    J! 1.5.7 | Apache/2.2.9 (Fedora) PHP/5.2.6
    MYSQL 5.0.45 |Fabrik 2.0B, SVN 704:
     

    Attached Files:

  18. rob

    rob Administrator Staff Member

    Level: Community
    i can't replicate this one, even with the descriptive images you posted - very odd!
     
  19. jc513

    jc513 New Member

    Level: Community
    Any suggestions on next steps. I really don't want to blow away all my tables/Fabrik installation and start over. I have a couple other tables that are working fine and I really don't want to recreate them all (oh the number of elements!).


    Update....

    I deleted all forms, groups, tables, elements and dropped the MySQL table dealing with this particular form. Recreated everything. Problem still exist. UUgghh...I don't want to wipe everything....
     
  20. cheesegrits

    cheesegrits Support Gopher Staff Member

    Level: Community
    The only way we can get a clue on this one is to get access to your server. Is there any way you can provide temporary access? We'd need a superadmin login, and either xTplorer installed in Joomla, or ftp access. Might need phpMyAdmin as well.

    One long shot sanity check, are you absolutely sure you have updated ALL your files, front and back end, from the latest SVN? Even if you are sure, can you grab the latest SVN and upload everything (remembering to do the 'export' step from SVN, so you aren't including the thousands of SVN metadata files in your live site).

    -- hugh
     
Thread Status:
Not open for further replies.

Share This Page