All Projects

ID Project Category Task Type Severity Summary Status Opened by Opened Progress
2142FlysprayBackend/CoreBug ReportLowPost-authenticate redirect does not make use of baseurl...UnconfirmedTabbycat28.06.2016
Task Description

I run flyspray behind a reverse proxy with the front end url being https and with the actual back end server not being on a standard port and not using https.

Setting force_baseurl seems to sort most areas with flyspray’s url generation using that instead of picking up from $_SERVER, however post-authentication redirection does not do that it just processes redirect_to as is (which in my case means it picks up the protocol, name and port for the back end server rather than what’s set in force_baseurl).

./themes/CleanFS/templates/loginbox.tpl puts out $_SERVER[’REQUEST_URI‘] into a hidden redirect_to input field - on my setup on the front page that’s e.g. “/” or for a ticket url it would be “/index.php?do=details&task_id=999” so no protocol or hostname.

scripts/authenticate.php picks up that redirect_to value and just passes it to Flyspray::Redirect, which in turn calls FlySpray::absoluteURI on what it’s passed, and FlySpray::absoluteURI doesn’t use $baseurl to qualify the url.

Not sure what the best fix is - my suggestion would be that Redirect detects urls that aren’t fully qualified and adds the $baseurl on to the front of them, rather than calling absoluteURI (absoluteURI is used to set $baseurl if force_baseurl is unset, so that’s not appropriate to modify). Alternatively scripts/authenticate.php could check redirect_to and add $baseurl if needed.

 2128 FlysprayText RenderingBug ReportLow Geshi (part of dokuwiki plugin for code blocks) uses de ...ClosedTabbycat20.05.2016
211 Task Description

The dokuwiki plugin uses a very old version of geshi for syntax highlighting which uses the deprecated /e modifier in preg_replace in two places rather than preg_replace_callback.

This can trigger warnings such as the following when initially parsing content which uses dokuwiki syntax and includes code:

PHP message: PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/phpapps/flyspray/plugins/dokuwiki/inc/geshi.php on line 2058

PHP message: PHP Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/phpapps/flyspray/plugins/dokuwiki/inc/geshi.php on line 2067

This affects as well. Several hits came up on google when I search for the following due to the warnings having been displayed ahead of the page content (seen screenshot): flyspray preg_replace_callback

Because flyspray caches the results of processing dokuwiki content then the warnings don’t get emitted if the content has already been cached (so you may find that when you access the url in the screenshot that it doesn’t show the warnings unless you clear the cache entry for that task). Previews can get the warnings spat out as well if there are tagged code sections in the content.

I had a look at a more recent version of geshi ( from sourceforge) and they had fixed that issue in it (presumably along with a lot of other stuff) so I tried replacing plugins/dokuwiki/inc/geshi.php and plugins/dokuwiki/inc/geshi/* with the versions and that stopped the warnings. I haven’t extensively tested it, but it was processing stuff in code blocks correctly still on the couple of samples I tried.

I guess it’s a separate issue but the new flyspray theme doesn’t have any css styles to apply to the syntax highlighting (if you look at  FS#1107  you can see that, and in fact you can see it with the css bit below - if you inspect them with a browser dom inspector you can see that the genshi plugin has parsed and tagged the bits, but no styles are applied so its all just in the default colour). I can raise that as a separate task if worth doing? The following section in bluey stylesheet covered it I think:

.code .br0 {color:#6c6;}
.code .es0 {color:#009;font-weight:700;}
.code .kw1 {color:#b1b100;}
.code .kw2 {color:#000;font-weight:700;}
.code .kw3 {color:#006;}
.code .kw4 {color:#933;}
.code .me0 {color:#060;}
.code .nu0 {color:#c6c;}
.code .re4 {color:#099;}
.code .sc0 {color:#0bd;}
.code .sc1 {color:#db0;}
.code .sc2 {color:#090;}
.code .st0 {color:red;}
.code .co1,.code .co2,.code .coMULTI {color:gray;font-style:italic;}
.code .kw5,.code .re0,.code .re1,.code .re2 {color:#00f;}
 1096 FlysprayBackend/CoreBug ReportLow Call to logEvent in for event type 14 pa ...ClosedTabbycat01.11.2006
Task Description

In current svn version of for 0.9.9 there's the following line:

Flyspray::logEvent($task['task_id'], 14, trim(Post::val('assigned_to')), Post::val('old_assigned'), null, $time);

This should actually be:

Flyspray::logEvent($task['task_id'], 14, trim(Post::val('assigned_to')), Post::val('old_assigned'), '', $time);

The column field_changed in the database is constrained to be NOT NULL and the value used for field_changed by convention to indicate that the event is not releted to a field is an empty string rather than NULL. At present if this line of code fires it leads to a database exception due to the NOT NULL constraint on the column.

 1086 FlysprayBackend/CoreBug ReportLow New $local_only check in Redirect not compatible with $ ...ClosedTabbycat30.10.2006
4 Task Description

I just upgraded our flyspray with the latest set of patches and noticed that for some reason the redirects that should be happening after login weren't working. Looking through the code I think this is because Redirect now has a $local_only argument which defaults to true and is used to check if the url passed in is "local" - it does this by checking against the Host header, however in situations where there's a reverse proxy in front of the flyspray instance and the $force_baseurl is used to force the host name used in urls to something different to that which comes in from the Host header then Redirect will just discard any urls given to it.

Perhaps instead of getting the host to compare against from $_SERVER['HTTP_HOST'] it would work more generally if the host to compare against was gotten by calling parse_url against $base_url and getting the host component of that - if $force_baseurl isn't set then $base_url will be constructed using $_SERVER['HTTP_HOST'] anyhow, so this should work in both situations I think (although I'm not familiar enough with the code to be sure of that!)

 1066 FlysprayJavascriptBug ReportLow Followup to FS#1050 - Del not working under IE ClosedTabbycat15.09.2006
2 Task Description

I requested a reopen of  FS#1050  as I found an issue with my suggested code, but the reopen request hasn't been processed yet so figure maybe I should just add it as another issue. This was my reopen comment:

Found an issue with my suggested replacement code: "else if (to)" needs to be "else if (to && to.add)" for it to work under IE otherwise it seems to hit occasions where to doesn't have an add method and errors.

So the portion of dualSelect changes from:

            if (to && to.options) {
            } else if (to) {

To be:

            if (to && to.options) {
            } else if (to && to.add) {

I'm not sure why "to" neither has options nor add as I'm not familiar with the contexts its used in, so maybe the error is actually symptomatic of another issue, however when the above code change the "Assigned To" list adding and removal does seem to work OK under both IE and firefox as I applied the change to the flyspray install here and it works ok :).

 1063 FlysprayBackend/CoreFeature RequestVery Low Return ability to configure baseurl ClosedTabbycat11.09.2006
Task Description

You used to be able to configure the baseurl for the system by setting a config variable of $baseurl, however this no longer works - flyspray always uses autodetection.

I think it would still be useful to allow $baseurl to be set as a config variable and to override flyspray trying to figure it out. The reason this can be useful is if, for example, you use a reverse-proxy/caching proxy in front of the server that flyspray is hosted on. Although reverse-proxies happily rewrite Location headers, they don't (usually) scan the content of pages and rewrite absolute urls listed in those. I think it would be sufficient in to set the global $baseurl to the config variable baseurl if that config variable is set, otherwise it can just make the call to absoluteURI to figure out what it should be set to.

 1062 FlysprayUser InterfaceBug ReportLow Projects list once viewing tasklist for project not sho ...ClosedTabbycat11.09.2006
Task Description

When a user with access to only some projects logs in, from the "All Projects" tasklist the list of projects they see in the drop down next to "Switch" is restricted to only the projects they have access to, which is fine... If, however, they then switch to a project they have access to this list changes to show all projects, including ones they don't have access to.

Similarly, when editing a task the "Attached to Project" field shows all the projects in the system rather than just the ones the editing user has access to (although perhaps I should create a seperate bug report for this one?)

(As an aside - maybe the editability of the "Attached to Project" field should be something that can be configured on a group-by-group basis, as I would have thought that often even if you want to let a user edit their own tasks you don't want to allow them to change the project of a task)

 1061 FlysprayUser InterfaceBug ReportLow User search callback for new user picking ui for "Assig ...ClosedTabbycat11.09.2006
3 Task Description

I'd probably be inclined to call this a bug report rather than a feature request - with this one it depends on perspective though.

When you type in a letter or two into the user list search box to add users to the "assigned to" on a task it lists matching users globally from within the system. This means if you happen to use the same flyspray instance for multiple projects and each of those projects has a fairly different set of users with access to it, you will keep seeing users pop up in the search results that don't have access to the project.

I feel this to be a bug, in that I'd say the correct behaviour should be to only show users that have access to the current project selection in the "Attached to Project" field.

 1057 FlysprayDatabase QueriesBug ReportLow Project creation gives error 'null value in column "not ...ClosedTabbycat07.09.2006
Task Description

When creating a new project under beta2 (and I think also probably in the current svn codebase) the code in to do "INSERT INTO" for the new project details in the project table doesn't specify a value for the notify_reply column, and in flyspray-0.9.9-devel.mysql when the column is added to the project table it doesn't have a DEFAULT '' clause:

ALTER TABLE `flyspray_projects` ADD `notify_reply` TEXT NOT NULL AFTER `notify_jabber_when` ;

So this leads to a non-null constrain violation error when trying to create a new project.

 1050 FlysprayJavascriptBug ReportLow Assigned To "Select Users..." box add/del buttons don't ...ClosedTabbycat04.09.2006
Task Description

The issue is that IE is a bit rubbish and the select list add method doesn't work propery. See this link.

To fix the add button I'd be inclined to replace the following line in adduserselect:


With this instead:


Not as elegant but the latter does work in both firefox and IE.

The "del" button doesn't work because dualSelect calls to.add(opt,null). The replacement of that is more involved because there's some drop through exception, so I'm wondering if "to" can be something other than a select list which is why this exists?

Instead of:


I hacked in:


It maybe that the try/catch block should just be replaced with:

 1049 FlysprayBackend/CoreBug ReportLow Another problematic use of GROUP BY under postgresql ha ...ClosedTabbycat04.09.2006
12 Task Description

In scripts/details.php the following block of code in beta2 and in the devel copy:

    $result = $db->Query('SELECT u.user_id, u.user_name, u.real_name, g.group_name
                            FROM {assigned} a, {users} u
                       LEFT JOIN {users_in_groups} uig ON u.user_id = uig.user_id
                       LEFT JOIN {groups} g ON g.group_id = uig.group_id
                           WHERE a.user_id = u.user_id AND task_id = ?
                        GROUP BY u.user_id
                        ORDER BY g.project_id DESC',

Will result in an error something like:
Query {SELECT u.user_id, u.user_name, u.real_name, g.group_name FROM "flyspray_assigned" a, "flyspray_users" u LEFT JOIN "flyspray_users_in_groups" uig ON u.user_id = uig.user_id LEFT JOIN "flyspray_groups" g ON g.group_id = uig.group_id WHERE a.user_id = u.user_id AND task_id = ? GROUP BY u.user_id ORDER BY g.project_id DESC} with params {797} Failed! (ERROR: column "u.user_name" must appear in the GROUP BY clause or be used in an aggregate function)

Usual thing of needing to have everything in the select or order by parts of the query listed in the group by (or using aggregates) under postgres if you use a group by.

I've temporarily hacked my copy by adding everything from the select and order by to the group by to get it to work, but there's probably a better way of fixing things :)

 1031 FlysprayJavascriptBug ReportLow Dokuwiki syntax toolbar bold/italic/etc buttons don't s ...ClosedTabbycat08.08.2006
Task Description

Flyspray's version of the dokuwiki syntax toolbar doesn't seem to work under IE 6.

The javascript functions in javascript/functions.js that are used don't seem to work with IE 6 for doing text insertion at the caret position and replacement of selected text.

I had a look at the techniques used in toolbars that do work under IE 6 and came up with the following that seems to work ok under IE 6 (shown in diff form against javascript/functions.js):

@@ -409,6 +409,11 @@
                textarea.scrollTop = scrollPos;
+       else if (document.selection) {
+               textarea.focus();
+               sel=document.selection.createRange();
+               sel.text=text;
+        }
        // Just put it on the end.
@@ -451,6 +456,33 @@
                textarea.scrollTop = scrollPos;
+        else if(document.selection) {
+               textarea.focus();
+               var sampleText = 'TEXT';
+               var currentRange = document.selection.createRange();
+               var selection = currentRange.text;
+               var replaced = true;
+               if(!selection) {
+                       replaced=false;
+                       selection = sampleText;
+               }
+               if(selection.charAt(selection.length-1)==" "){
+                       // If trailing space ended up in selection move it after the tags we add
+                       // (as double click word select in IE often selects trailing space)
+                       selection=selection.substring(0,selection.length-1);
+                       currentRange.text = text1 + selection + text2 + " ";
+               }
+               else
+               {
+                       currentRange.text = text1 + selection + text2;
+               }
+               if(!replaced){
+                       // If putting in sample text (i.e. insert) adjust range start and end
+                       currentRange.moveStart('character',-text.length-text2.length);
+                       currentRange.moveEnd('character',-text2.length);
+               }
+     ;
+        }
        // Just put them on the end, then.
 1030 FlysprayBackend/CoreBug ReportLow SQL error when sorting the task list on some columns un ...ClosedTabbycat08.08.2006
Task Description

Beta1 was a bit ropey under postgres and I had to fix a number of things. I'm now going through the list of things I've fixed and checking whether you've already cured them in the latest svn version. This is one issue I don't think is fixed yet...

I don't think the query generation automatically adds column references added to the ORDER BY clause to the GROUP BY clause - under postgres if you have the "Assigned To" column shown in a task list and try to sort on it you get an error because u.real_name gets added to the ORDER BY but isn't in the GROUP BY (quite a few columns you can sort on because they're already in the GROUP BY). I fixed it with this hack:

 //Get the column names of table tasks for the group by statement
 if (!strcasecmp($conf['database']['dbtype'], 'pgsql')) {
-    $groupby .= "p.project_title, p.project_is_active, lst.status_name, lt.tasktype_name, ";
+    $groupby .= "p.project_title, p.project_is_active, lst.status_name, lt.tasktype_name,u.real_name, ";

However this probably isn't the cleanest way of doing it and I don't know if there are any other columns that can be shown in the task list that are sortable that would suffer from a similar issue so also need fixing!

Showing tasks 1 - 13 of 13 Page 1 of 1

Available keyboard shortcuts


Task Details

Task Editing