Is it possible to Pre-Filter using {$_SESSION['filtername']}

[andrelewis]

My understanding is that you should be able to use any global term in the pre-filter area, and PHP considers $_SESSION as a global variable, so this should evaluate in the Pre-filter, yes? The other one that should work is {$_REQUEST['elementname']}

I can not test this as the filtering in rev 50 is broken.

Anyone else care to try it?

Andre

[andrelewis]

Ahhhh I think I just figured out that the filtering is set up in rev 50 to apply to ALL levels EXCEPT the one you set the filter to, hence the comment before that the filter should be set to super administrator.

Interesting.

[andrelewis]

K I tested this, and well, I need someone to add session_start() in the pre-filter code.

Then this would work. Testing it with passed in variables like $_REQUEST now.

[andrelewis]

That would be a no. Of course it would be, that would be way too simple.

So far I think I am batting 6 out of 116

[andrelewis]

Bump: Rob is this a possibility?

Andre

[andrelewis]

Scratch that, you know what would be REALLY usefull?

If on the prefilter section you set it up the same way the elements are done, with an eval this text checkbox, so we could put in any php there and evaluate the contents for the filter.

Save a LOT of time and energy for people doing advanced work.

Andre

[rob]

Hi Andre

Perhaps the help message is less than clear, by "globals" I meant the following can be used:

$mosConfig_absolute_path, $mosConfig_live_site, $mosConfig_offset, $Itemid, $mosConfig_sitename, $my, $mosConfig_mailfrom

Also the form can access request variables, but i don't think session (even with a session start in place)

In 2.0 you have the option to run a query and use that queries results in the prefilter.
I have added as a task the option to eval the prefilter, but this will only be for 2.0, as I have a feature freeze on 1.0.x now

Cheers
Rob

[andrelewis]

Hi Rob,
$_REQUEST doesn't work, tried it before. Happy to try it again if it's a possibility but it didn't work when I tried this on rev 78.

The real reason for this is that I need to validate and pre-filter something on a table which has no direct correlation to the current Joomla_id. Several of the pages actually won't have anyone logged in and I need to filter the table data somehow. More importantly I need to embed several Fabrik Mambots (form and table) on the same page, and I know there is no way to filter those short of using the Fabrik session filtering which means hard coding Fabrik form and table ID's into my code. I also don't know how consistant that would be between page requests etc.

The crazy way of doing it would be to make a connection pool of the same Fabrik table data structures and using my custom component to modify Fabrik table records in the pool writing in string literals of the pre-filter per session. This seems like overkill and painfull way to do dynamic pre filtering with security built in.

$mosConfig_absolute_path, $mosConfig_live_site, $mosConfig_offset, $Itemid, $mosConfig_sitename, $my, $mosConfig_mailfrom
Realistically the only thing I would ever filter on would be $my, the rest of the globals other than $itemid are set in configuration.php and would always be constants for a single joomla configuration and have the same value for every record.

Multiple joomla configurations would really be able to use those other globals, but a very limited subset of people need that.

I definitely can't wait for the 2.0 release on this one, as I am several months behind and the customer is taking a serious hit.

[rob]

i've not changed anything in the code (the assumption about request was based from reading the code), so if request wast working don't test it.

I'll see what i can do about evalutaing the pre filter

Cheers
Rob

[rob]

hi

revision 98 should allow for evaluation of prefilters in 1.0.4

Cheers
Rob

[andrelewis]

You are AMAZING! Does this require an update to the DB? I would imagine there would have to be an additional column to store the option to evaluate?

Andre

[rob]

hehe cheers

no update to the db needed, the info is stored in the exisiting attribs field (which is used to build the $params object)

[andrelewis]

Beautiful!
Thanks Rob!

I just realized it is storing just one line of code in the eval section of the pre-filter.
Also the existing pre-filters now have {$my->id} which works correctly until edited to remove the > so apparently if it's not going to be evaled, this is going to have to be the way it is entered. Which is fine because older versions will continue to work and going forward you would expect people to use the same code from everywhere else:


global $my;
return $my->id;

The pre-filter works with this as long as everything is on one line. Might also want to expand the data type to allow more text - don't know what the current width of the field is?

Andre

[joaquinjgc]

SVN 99

The pre-filter works with this as long as everything is on one line

Correct, works, but have a litle problem:

You put:
global $my; return $my->id; (in the same line)

When you save the field change to:
global $my; return $my->id; --- works

If you save again the field change to:
global $my; return $my->id; --- don´t works

If you save again the field change to:
global $my; return $my->id; --- don´t works


......... bucle

:o :o :o

Joaquin

[rob]

Hi Guys

Line breaks are now maintained in the value field and the text is not encoded (so -> stays as -> and is not converted to >)
Joomla code svn seems to be having a fit this morning so I can't commit the changes... :(

[andrelewis]

Thanks Rob!

[andrelewis]

Hi Rob, just did a check and multiple lines cause issues since the code is escaped and added to a single line using \n.

Example:
global mosConfig_absolute_path;
require_once( $mosConfig_absolute_path . '/components/com_ponent/class.ponent.php' );
return ComPonent::getOrgFromHostId($my->id);

turns into:
global mosConfig_absolute_path;
require_once( $mosConfig_absolute_path . '/components/com_ponent/class.ponent.php' ); '
+ '\nreturn ComPonent::getOrgFromHostId($my->id);'

And editing it again to fix my global vars to
global $my, $mosConfig_absolute_path;
resulted in
global $my

Actually it seems to chop off anything after the first term that starts with a $.

Tried putting it in there again all in one line, this time with the global $mosConfig_absolute_path, $my; as the first line, and now the prefilter gets trunc'd down to :
global $mosConfig_absolute_path

Andre

[andrelewis]

Well looks like it's getting stored correctly, it's just not getting read back in correctly.

From the DB:
filter-value=global $mosConfig_absolute_path, $my; require_once( $mosConfig_absolute_path . '/components/com_ponent/class.component.php' ); return ComPonent::getIdOneFromId2($my->id);

From the error logs:
[Thu Aug 02 00:20:25 2007] [error] [client 127.0.0.1] PHP Parse error: syntax error, unexpected $end, expecting ',' or ';' in /var/www/html/components/com_fabrik/fabrik_table.class.php(1554) : eval()'d code on line 1, referer: http://localhost/index.php?option=com_frontpage&Itemid=1
[Thu Aug 02 00:20:25 2007] [error] [client 127.0.0.1] PHP Warning: Attempt to assign property of non-object in /var/www/html/components/com_fabrik/fabrik_table.class.php on line 3709, referer: http://localhost/index.php?option=com_frontpage&Itemid=1
[Thu Aug 02 00:20:25 2007] [error] [client 127.0.0.1] PHP Notice: Undefined variable: oTable in /var/www/html/components/com_fabrik/views/table/view.html.php on line 151, referer: http://localhost/index.php?option=com_frontpage&Itemid=1
[Thu Aug 02 00:20:25 2007] [error] [client 127.0.0.1] PHP Notice: Trying to get property of non-object in /var/www/html/components/com_fabrik/views/table/view.html.php on line 151, referer: http://localhost/index.php?option=com_frontpage&Itemid=1


My guess is that the reload of the code from the database isn't un-encoding correctly...

Andre