Edit link and delete button not working on tables.

Status
Not open for further replies.
eshelman.carl

eshelman.carl

New Member
I have a static content page that shows several table via the tablebot. As near as I can tell the tables are all configured the same. There are 2 issues on this page.
1) The delete does not work. When an item is checked and the delete button is clicked nothing happens.
2) The edit link works on some table but not others. One one table when you click the edit link it allows you to edit the row data. On the rest of the tables the EDIT link takes you to a new record form.

*** 2-3-2008 Update***
Updated to SVN 680 code. Did not resolve issue.
After many hours of trouble shooting I was finally able to narrow the issue down. It is related to the pre-filters applied to the tables. All of the tables are set to pre-filter parent_batch_id --> Equals --> "{rowid}" --> Everyone where parent_batch_id is my foreign key. With this setting when the edit link in the table is clicked it takes you to the form with a NEW record. If I set the pre-filter to parent_batch_id --> Equals --> "{rowid}" --> Public Front End then when the Edit link is clicked it takes you to the form with the record info loaded for editing. I checked the url that is being generated both ways and they are exactly the same. Since they are the same it must have to do with how Fabrik is accessing the row data for the edit form. The table where it was working on did not have the Everyone selected.

Also determined that the delete issue is a JS error. I have not tracked this down any farther.

Thanks, Carl.
 
Are you sure you are understanding the access control on the filters? In filters, the access level you set is the level at which the filter will NO LONGER be applied. See the tooltip on that setting for more info.

So basically, by setting it to "Public Front End", you are saying "for anyone with access level of Public Front End or above, do NOT apply this filter".

If you want to point me at the page I'll take a look at the JS error.

-- hugh
 
Yes, I understand how it works. That is exactly my point. This page is only accessible to registered users. When I set the pre-filter access to apply to a user then the edit link in the table no longer works. It appears to me that when Fabrik goes to get the data for the form it is applying the pre-filter and not returning any data. When I set the access to no longer apply, then data is returned to the form and one can edit it.

The page with the JS errors for the delete is located here. If you are taking a look at it please take a look the header of the page as well. Fabrik seems to mess up my header... the logo is not displayed (only text of site name) and if I add another main menu item it will really go crazy and screw up the header image. Pages with out any Fabrik tables or forms all work properly.

Here is the link. You will need to login. I will PM a login. Try to edit a record while your at it... wont work because I have the access level set to apply.
http://www.vintnerresources.com/index.php/Winemakers-Log.html?rowid=8&fabrik_cursor=0&fabrik_total=1

Thanks, Carl.
 
Mea Culpa, I mis-read your initial post. That's what I get for speed reading through almost two weeks of questions. :)

I'll see what I can do.

-- hugh
 
lol hugh - if you remove the task field from the table when rendering in mambot no tasks will be performed ! ;D

i think ive fixed this in the svn, Carl can you try again pls?

Cheers
Rob
 
Just updated to SVN 684 and the issue is still there. Ran the same test, when the pre-filter is set to apply then the edit link takes you to a empty record form. When the pre-filter is no set to apply then it populates the form.

Thanks for looking into this for me!
 
Upgraded to SVN 690 today and have some good news and some bad news...

Bad news: No change in the behavior of the edit link.

Good news: When I click the delete button it does something. Before it did NOTHING.

Bad news: The something it does is not deleting anything. It simply chugs and churns for a few seconds and refreshes the page but the record is not deleted.

Thanks for all the work on this. I know it has been a pain in the back of the front but it is greatly appreciated.
 
can you pm me a superadministrator account please, i need to debug to see whats going on a simple user account wont help i fear

one thing i noticed for the edit page is this, if you amend the edit url with &fabrikdeug=1 it shows you the query run to get the form's data.
e.g. http://www.vintnerresources.com/ind...&fabrik_cursor=4&fabrik_total=5&fabrikdebug=1

normally the end of the query would be something like "jos_fabrik_formdata_3.fabrik_internal_id = '44'" but in your case its:

WHERE jos_fabrik_formdata_3.parent_batch_id = '44' AND jos_fabrik_formdata_3.fabrik_internal_id = '44'

I have a feeling that this simply returns no records hence why the edit form doesnt work?

cheers
Rob
 
The account I sent a couple of days ago has been bumped back up to SA. I thought you were through with it so I kicked it down. I will leave it for a while this time!

I will do some testing with the debug command and see if the SQL query changes based on the filter application. Let me know if there is anything else I can do to assist.

Thanks, Carl.
 
Called the edit form 2 times, once with the parent_batch_id pre-filter applied, once with it not applied. The URL changed. With the pre-filter applied:
Code: 
WHERE jos_fabrik_formdata_3.parent_batch_id = '44' AND jos_fabrik_formdata_3.fabrik_internal_id = '44'

Without the pre-filter applied:
Code: 
WHERE jos_fabrik_formdata_3.fabrik_internal_id = '44'

So when the pre-filter is applied it to the table, it is also incorrectly being applied to the edit form query.

Hope this helps.
 
I did some more testing on this and verified that placement on the page does not matter (it can be the first, middle or last tablebot on the page) and exclusion of the add record form does not matter either. The only table that can be edited is the table where the pre-filter is on table key "fabrik_internal_id" instead of the foreign key "parent_batch_id"

Does the form use the "_getSQLWhere" function from the fabrik_table.class.php file to load the data? If so the default behavior is to apply the prefilter. Is the form not requesting to override this default?

Thanks, Carl.
 
Hi Carl

I've been thinking long and hard about this one, and I've come to the conclusion that prefiltering the table is not the way to go.
Prefilters are applied to both the table and the form - this is for security reasons to ensure that users can't edit records they are not meant to see.

What I suggest doing instead is
-remove the {rowid} prefilter from your tables
- alter the url that loads the page from

http://www.vintnerresources.com/index.php/Winemakers-Log.html?rowid=8&fabrik_cursor=0&fabrik_total=1

to something like

http://www.vintnerresources.com/ind..._cursor=0&fabrik_total=1&tablename___batch_id[value]=4

which will filter the mambot tables on the batch id, but wont be applied to the form's
 
There are several problems with this idea:

1) This presents a much larger security risk. With the pre-filter in place the most a hacker could hope to display is the records from a single parent batch at a time. With this solution, leave off the "&tablename___batch_id=0" and they could view and edit EVERY record from that table. Any security holes associated with not applying the pre-filter to a edit link can be fixed by simply adding another pre-filter and pre-filter on user ID. Which I have always planned to do as soon as I have this working.

2) The page is called with "http://www.vintnerresources.com/index.php/Winemakers-Log.html" in the "Detailed View URL" of the parent table. The "?fabrik_cursor=0&fabrik_total=1&rowid=8" portion is all generated by Fabrik. As a result there is no way to add the "&tablename___batch_id=0" on to the end of the URL with out hacking the code and having this applied to EVERY detailed view URL, which will not work either.

3) EVERY table that is pre-filtered on anything other than its primary key will have this issue. One could never build a relational db with editable fields using pre-filters. Accomplishing this is one hell of a lot easier with pre-filters than it is with joins as with joins require the creation of custom templates for each table to get them to display right.

This is a bug in the software. If you don't want to fix it for the general release for security purposes, thats your call. But PLEASE send me the code to fix it for my site. I will take full responsibility for the security of my site.

Thanks, Carl.
 
hi Carl

1) Ok fair point ;)
2) You can alter the view details url with the tables "Detailed view URL" option
3) not true - the issue is that you have lots of filters accumulating on top of each other - as the variable {rowid} refers in the table view to the batch id and then in form view to a different id

Have you considered not using {rowid} as the filter value? This is where the heart of the problem is.
If it was me designing it i would prefilter all records on the user's id. - so completely secure
Then use the batch number in the querystring to show data pertaining to a specific batch created by the user.

Cheers
Rob
 
1) ;D

2) I am using the tables "Detailed view URL" option. That is how I am calling the page. I can edit the URL but the variable are tacked onto the end of what ever I put in the field. There is no way for me to do URL --> auto generated variables --> my manual variables. I would have to hack the code and have this applied to EVERY custom detailed view URL.

3) Ahh... yea... good point. ;)

Not sure I follow you on this paragraph:
"Have you considered not using {rowid} as the filter value? This is where the heart of the problem is.
If it was me designing it i would prefilter all records on the user's id. - so completely secure
Then use the batch number in the querystring to show data pertaining to a specific batch created by the user."

{Rowid} IS the batch number. That is how it is passed from the batch table to the custom detailed view page. So I am filtering first on Rowid (which is the batch number) and then on user ID to secure it. I am not aware of any other way to pass the info in Fabrik. If there is another way let me know, I will be all over it.

Thanks, Carl.
 
2) In the svn as of rather recently you can insert the current table rows data with the syntax {elementname}

This is how i would attempt to do things:

1) Create an element for the batches table called "owner_id" which was set to be a "username" element type - Thus each time a user adds a batch the record is "owned" by them
2) create a table view of the batches and add a pre-filter "where owner_id = {$my->id}" - this means users can only ever see their own batches

From her on in i'm not sure exactly what would have to be done with out testing, but at a guess

3) Add to all tables an "owner_id" column - the same as for the batch column, and again create pre-filters on these tables, the same as for the batch table.
4) Edit the "detail view url" to point to your content page with all the table bots on it and include "&batch_id[value]={__pk_val} " in this url

Or something like that :)
 
Upgraded to SVN 700 and tried to implement this. Problem is that {__pk_val} is not being evaluated.

Here is what I put in the table Detailed View URL field:
http://www.vintnerresources.com/index.php/Winemakers-Log.html?parent_batch_id[value]={fabrik_internal_id}
I have also tried:
http://www.vintnerresources.com/index.php/Winemakers-Log.html?parent_batch_id[value]={__pk_val}
http://www.vintnerresources.com/index.php/Winemakers-Log.html?parent_batch_id[value]={key_id}
and a few others, using both element names and labels. None of them were evaluated.

None of them evaluate what is in the {}
The URL comes out:
http://www.vintnerresources.com/index.php/Winemakers-Log.html?parent_batch_id[value]={__pk_val}&rowid=8&fabrik_cursor=0&fabrik_total=1
If I manually change the {__pk_val} to a valid batch ID then it works just like you said it would.

We are getting close... VERY close!

Thanks, Carl.

Thanks, Carl.
 
After many failed attempts I have not been able to successfully use an element reference variable in the tables Detailed View URL section. I have upgraded to SVN 702 and it is still not working. Are you sure you were not confusing the form jump url section with the tables detailed view url?

I finally got this working. Here is what it took for future refference:
1) Had to rename the primary key on the parent batch parent_batch_id so it would match the field name in the URL filter for the child tables on the page.
2) Disabled detailed views in the table setting of the table that calls the custom detailed view page.
3) Created a custom template for the table that calls the custom detailed view page. This template creates its own view link that uses the url filter syntax instead of the standard View link created by Fabrik.
4) Change all table so be filtered only on user ID and not on RowID.

Delete still does not work but I will open a new thread for that.

Thanks, Carl.
 
Status
Not open for further replies.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    Total: 58 (members: 2, guests: 56)
    Back
    Top