Flyspray

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.

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

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.

Understand.

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

FS#123

to

PSS-123

or

PSS#123

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

Obstacles with implementing by as an output filter

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

from

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

to

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

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

from

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

to nothink

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

Example:

Never do:

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

Ok:

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>

to

<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!

Regards
Nikos.

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?

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 bugs.flyspray.org 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

'FS#123'

, 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 www.flyspray.org too.

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

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