A forum for technical support discussion related to Fogbugz.
Great work on 6.0! The organization I work for has 50 FogBugz users and the response to the upgrade has been very positive.
We are using the latest (6.0.23) build on Windows Server 2003 and we have encountered the following issues:
- We changed one of the names of the Areas for a project and the change is not visible when pressing 'New Case'. We can see the renamed area in the filter selection, but the area drop down on new case has a stale listing. We tried clearing the cache and restarting IIS, no luck.
- If the case notes contain a single long string of text the overflow:hidden is clipping it off. If the cases are going to be fixed width it would be nice to have overflow:auto so that a horizontal scroll bar would appear. To reproduce this simply enter a long string (a few hundred characters) of the same letter.
- This is a bug we were having since 5.0 but it either still exists in 6.0 or there is something wrong with our schema. Every time we remove the ‘Due’ column and save the filter it returns at the end when we view the list again. I ran a check database but it reported no errors.
Friday, September 7, 2007
Thanks for the feedback!
As far as the long lines, I've added your comment to the case we have open for that.
I'm not sure I understand the last point - are you saying that no matter what you do, the Due column ends up in your filter? That's really odd. If you go to Filters->Customize... and remove it from there, it still shows up?
We are still having the issue of the Adrea drop-down having stale content. We are using SQL Server 2005 Express edition. The FogBugz check database function returned no errors. I'm using Firefox 126.96.36.199 and IE 6.0, both have this problem and on both I have tried clearing cache/cookies which does not help. I have also tried restarting the browser and re authenticating without luck. Other users are experiencing this too.
I'm not aware of any other caches that could be in the way and the stale listings appear to only affect the drop-downs. The filter selection on the list pages show the updated content. The 'Edit Saved Filter' screen that uses the drop downs is also stale.
I checked the source for the output and it is indeed stale as well. I have to assume something is causing the server to cache the content. To rule out caches on the network I went to the server and used the loopback to access FogBugz (https://127.0.0.1:444/fogbugz/) and there too the content was stale.
I restarted the World Wide Web Publishing Service and the content was still stale. So it likely isn't a memory cache issue. Next I tried the database to see if content was getting cached in there. The 'Area' table shows the proper updated content.
I next looked in the fragment cache and I did a search for the old area name 'All Unknown' and what I changed it to 'Renamed Area'.
select top 1 * from FragmentCache where sValue like '%All Unknown%' order by dt desc;
select top 1 * from FragmentCache where sValue like '%Renamed Area%' order by dt desc;
The first query returned a row and the second returned nothing.
I think what is happening is that your cache is not updated for the area drop down when I change it.
Here is how I change the area:
1) Click Settings > Project
2) Click the Edit icon beside the project name
3) Click the name of the Area I wish to change
4) Change the area name and hit enter
I then leave the project page without hitting the big 'OK' button at the bottom. (Though I tried this too and it does not make a difference)
No matter what I change the area to I can't see the update value in the fragment cache and I have the stale drop downs.
We have also experienced a similar and most likely related cache issue with the drop-down for users when a new LDAP user joined.
On the 'due' column problem, I have tried from the filter tools and from Filters > Manage Saved Filters... > Edit and no luck. It just keeps coming back.
Wednesday, September 12, 2007
FYI, with help from Jason Rosoff and Eric Nehrlich we were able to get the first issue resolved. The problem stemmed from having no rows in the fragmentdependency table which Jason was able to patch up.
Wednesday, September 12, 2007
This topic is archived. No further replies will be accepted.Other recent topics