Last call for bugs before 1.05 release

[cheesegrits]

If anyone has any last minute bug fixes or outstanding issues with 1.04, Speak Now Or Forever Hold Your Peace. Or at least hold it until 1.05 is out.

We'd like to get 1.05 rolled out over the next day or two, based on the latest 1.04 SVN.

The final bugfix we are currently working on are the issues with repeated group validation. I say we. I mean Rob. I took a look at it, and it looked waaay too much like hard work, so I threw it over the fence to Rob.

Unless anyone has anything else, this will be the final bugfix to 1.04 before we freeze for 1.05.

-- hugh

 

[mirceat]

I'm not very sure it's a bug:

using database join, "advanced" option, put in "Table to select from (leave blank to default to this element's table)" jos_users and restrict values to some specific ones: where id IN (64,66,67,71). Then select "Create table filter for this element" and "Filter type" as dropdown. The result it's look fine in form (return only users who had id 64, 66, 67 and 71) but in table view filter, i see a list of all users, shouldn't be only four of them?

Sorry if i missunderstand the idea for this option

thanks

 

[cheesegrits]

Hmm, I'll take a look at that.

-- hugh

 

[mirceat]

Hello?

Have you found the error?

 

[cheesegrits]

Nope, I've been busy tracking down and fixing a nasty bug I introduced when I added filtering to CSV exports. Bad Hugh, No Donut.

I'm going to start on the list of Other Stuff this evening, but it's a long list ...

-- hugh

 

[cookn22]

I installed the latest SVN today and am noticing a minor problem. I think it's a bug, unless I'm missing something obvious.

I have an element called row_date that is a date field and stores the date that the row in the database is created/edited. It's set to eval and the default value is 'return date('Y-m-d H:i:s');' I have another element called row_user that performs a similar function but stores the name of the user who created/edited the field. Both of these fields are set to 'hidden'.

Anyways, in the detail view the values, but not the labels, for row_date and row_user are being displayed. Another wrinkle to the bug is that the value stored in the database for row_date is being shown, but the currently logged in user, not the user who created/edited the row, is what's shown for row_user. As far as I can tell it's just a problem with the username element type and elements that have 'return ____' eval'd for the Default Value.

I'm doing a simple workaround for the moment. I changed line 54 of the bluesky template to this:

<?php } if($element->hidden == 0){?> <?php echo $element->label;?> <?php echo $element->element; }?>

 

[cheesegrits]

OK, I've confirmed this one as a bug. It's common to all templates, so it isn't a template problem.

I'll get it fixed ASAP.

-- hugh

 

[cookn22]

I'm using rev 811

I was trying to set up a search form following the typical method that's in the FAQ and has been posted on this forum. I've done this before on an early site on an earlier revision. I did all the same steps but the form jumped to the table, it would just show all the entries in the table and not just the rows that matched the search terms.

I struggled with this for awhile, but then I checked 'Show' for 'Append Jump Url with Data', and then everything worked as expected. I assume that this shouldn't be necessary for the search form to work, so I'm guessing there's a bug in there somewhere.

If it's not a bug, and something unique to my setup, then it's no big deal, I can live with that data being posted to the url.

 

[cheesegrits]

Rob should be back soon, I'll sic him on that one.

-- hugh

 

[cookn22]

Hi again.

I seem to have fixed the problem by commenting out a 'session_destroy()' function call at line 1515 in the file fabrik.class.php (in the function buildJumpPage).

It remains to be seen if this doesn't make something else go haywire..

 

[cheesegrits]

Yes, that could well mess other features up.

-- hugh

 

[rob]

hi

I've tidied up the session code into one function in fabrik.class.php

function _storeDataInSession( $arErrors ){
....
}

which will destroy and restart the session before storing the form's data, this seems to work for the search form problem, and at the same time keeps in the session_destroy() call before hand

rob

 

[cookn22]

Alright, that fixed it. Thanks Rob!