Flyspray - The bug killer!

  • Status Unconfirmed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Medium
  • Priority Very Low
  • Reported Version 1.0 devel (github master)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Nikos Baris - 20.01.2017

FS#2328 - Add [key] support for each project instead of FS#


Let the administrator choose the key for project.

What’s a project key?
It prefixes each task in the project

Project Manager

Hi Nikos,
what is the problem which you try to solve with this feature request?
It is just too ugly/long or what are you trying?

I have 2 variants how I understand your request.

1. Changing FS# as marker to 'build' an link to a task in task description or comment text. or
2. How links to tasks 'look' within Flyspray

For the first variant I see problems with this feature request.

  • output filters (e.g. dokuwiki), that parse the task description and comments and replace FS#<id> by HTML-links that link to the task within Flyspray. So the filters must know about the dynamic of that prefix.
  • What prefixes are allowed and which could lead to potential problems with parsing (dokuwiki syntax, code highlighting, HTML/CKEditor)
  • Users have to relearn the prefix 'key' for each project and/or Flyspray installation again.
  • Moving a task to a different project (task description, comments) would require the prefix must automagicly adapted in the description/comment.
  • For global tasklist description preview(mouseover) → different dokuwiki parsing modes for different projects within one HTTP request →performance?
  • Makes probably writing stuff that automates things between Flyspray and other tools a bit harder. For instance referencing a Flyspray task in a pull request and a bot that updates/comments a task based on pull request.
  • probably more potential pitfalls ...

I know that and probably other bug tracker use single chars as prefix for that.

Probability of setting an other prefix instead FS# on a per project basis: ~ 0%
Probability of setting an other prefix instead FS# for a Flyspray installation: low (doable, with some restrictions which is an allowed prefix)

But maybe I understand your request completely wrong and it's about the 'look'.

Do you mean when viewing a task and there is a link to a task and it is rendered as FS#<taskid> ?
And you want it to appear the link with a tiny logo of the target project of that task?
So you can see if a task is linking to a task of the same project or links to task of another project? (permission of target task/project must be checked if logo or similiar is allowed for viewing by user)

I used JIRA Software before and JIRA uses a project key for each project.

I think it's easy to handle the link "build" for comments, descrition etc. just use only the #<id> istead of FS#<id> and make a replace of that based on default format of project key (see bellow the rules) but leave the FS#<id> also available/enabled for all ready installed Flyspray sites.

Some rules for a project key.

Must use only uppercase alphabetical characters requires two or more characters based on the regular expression ([A-Z][A-Z]+).
(maybe max ten)

All letters must be from the Modern Roman Alphabet

Then first charracter must be a letter.

The default format of project key <project key>-<task id> (not with #) for example ABC-123

If no project key is set the default project key is set to FS

A project key is useful if you have multiple projects and multiple users/devs.

For example let's say you have two projects named "PHP Socket Server" and "Socket Control Panel", the project keys for projects are "PSS" and "SCP", also each project have tasks.
PSS-1, PSS-2, SCP-3, PSS-4, SCP-5, SCP-6, PSS-7, SCP-8, SCP-9, SCP-10 ...
... it's easier to user/dev to know in what project belongs a task by viewing only the SCP-5 but if you leave it as is now, it will be difficult to the user to understand in which project belongs the  FS#5 .

I try to make that by my own and I will create a pull request on github.
Project Manager


For me it looks like an output filter could achieve this.

Flyspray allows moving tasks between projects and it is a feature important to several users/installations.

task_id's are 'autoincrement' across projects, which makes moving them around without touching other tasks description or comments possible.
Are the id's in Jira 'unique' for each project or 'unique' for each installation?
(Is PSS-1 and SCP-1 possible or it is PSS-1, SCP-2 ...)

So lets say a unique project prefix key - say 'PSS' - then the link text could change from






on output, but description/comments in database keep the same (FS#..)

Obstacles with implementing by as an output filter

  • Cached output (if caching is enabled) of dokuwiki syntax descriptions/comments must be updated whenever a task is moved to another project. (All tasks and comments that link to the moved task in the description text!)
  • There is no output filter configured for the CKeditor/html 'syntax_plugin' variant yet. Only the input filter that filters before writing to database.

Btw. manages a lot of 'bugids' for many projects. They are now
at 1.3 million.

No, every project in JIRA starts from id 1 PSS-1 and SCP-1 but that is not a problem, I think it's better to have the same id like PSS-1 and SCP-2.

Moving task between projects in JIRA brings a wizard to make the necessary changes (Select a project, Task type, New status, new version etc.) It's bring you to change only the values that are different to other project.
After that, the "old" task id remain on the database with a redirection to the new. for example if the task of previous project has the id PSS-16, after move the new id became SCP-5. If some user has an email or the url of the previous id (PSS-16) and open it, a redirection makes to the new id SCP-5

sorry for my bad English.

I have complete that feature (I think) Needs test from you because you know better Flyspray project.

this is my Commit on Github akisc/flyspray

Do you want to make a pull request for that or can you test it as is ?

Before any pull request two things needs to be replaced/deleted.

The first on file /scripts/depends.php at line 194


$page->setTitle(sprintf('[%d] %s', $proj->formatTaskId($id), L('dependencygraph')));


$page->setTitle(sprintf('[%s] %s', $proj->formatTaskId($id), L('dependencygraph')));

and the second on the file /themes/CleanFS/templates/header.tpl line 94


<?php echo 'Project key: ' . $proj->key; ?>

to nothink

Project Manager

Hello Nikos,

I did a quick overview. Sorry, I do not see any chance that this can be commited to Flyspray1.0 for several technical reasons:

Incomplete list of my considerations, can go into more detail if asked:

  • hidden side effects
  • permissions: for instance restricted users get information about forbidden/hidden projects - solution would caching dokuwiki task descriptions useless. (requires to rebuild a task description/comment output rendering for each user dependend on his permissions for each project)
  • performance: for instance extra SQL queries for each tasklink on a page.
  • current status of Flyspray 1.0 development: focus on bug fixes (exception: features that are important and easy to implement = not many code change and no/very low side effects).

Aside from the deny for Flyspray 1.0, here some more thoughts:

  • Do not name it project key, that's too ambiguous I think. (primary key, index key, ..) Maybe project prefix instead?
  • I know there is no coding style enforced (that's ok), but I insist when applying new code/fixes to Flyspray: Always add parenthesis on one-line code blocks


Never do:

if($x==true) $bla=1;


if($x==true){ $bla=1; }

A little bit more typing work for the programmer, but avoids surprises in future.

All I wanted was to help with new features (in my opinion missing from flyspray) and also fixing some bugs.

As of your considerations, I can't understand some:
* What do you mean hidden side effects?
* permissions: become a little clearer. I think the only difference is the printing of the word on the acnhor for example from

<a href="...&task_id=1">FS#1</a>


<a href="...&task_id=1">DP-1</a>

and users have no permissions to see this "task" still do not have the permissions to see it. But perhaps confuse me the "caching" you mention.
* performance: This was the first idea, I'll look at it better. But in this way which is now written, never in a comment will have the wrong link.

Project key means that there is a key that belongs to the project, not something that prefixes the project :-) as Project Key used by jira also and some any others and is known by managers/admins. The End-user just see a prefix to the task. But it can be changed if indeed considered that confuses.

Btw I never had problem using the "if" condition without parentheses for many years. It depends on the people and how it's easy or hard to reading with or without parentheses. But if is one of Flyspray's coding-standards, I will respect it!


P.S. Off-topic: I have made a new theme for FLyspray (based on CleanFS) (in fact I'm at 90% to complete) but has changes in all files. It will be considered as "many code" changes?

Project Manager

Be not too disappointed. It is that I'm the only dude left who reviews before commit. In my freetime. I'm not glad about the situation too.
My personal priority ordering is security fixes, keep Flyspray's master on github as the most stable, bug fixes and moderation of to keep Flyspray at least maintained.

So my work on Flyspray the last 1.5 years is quite conservative. (because no other does the maintenance :-( )

Looked at the dokuwiki description (parsing) cache, it stores


, not a html-link, so link is built on output.
So maybe it is not the big problem that I thought first.

Postponing your work for FS1.0 doesn't mean it is completely denied.

Your themes topic will be discussed by FS#2337. And sure it needs some paragraphs on too.

I think that is dublicate of a closed issue  FS#1235  ? But I where is that feature ?

Project Manager

Interesting - 10 years ago.
Probably a question only former devs of 2007 ( @floele, @judas_iscariote ) can answer. A quick look at git history I didn't found matching stuff 2007-04 to 2007-05.


Available keyboard shortcuts


Task Details

Task Editing