All Projects

ID Project Category Task Type Severity Summary Status Opened by Opened Progress
2638FlysprayUser InterfaceTODOLowAdd tag helper also for the add new task formNewpeterdd10.05.2021
0%
Task Description

Now that the edit task page has the tag helper it is logic to add the tag helper also to the add new task form.

2637FlysprayInstaller and UpgraderBug ReportHighFailure to upgrade 1.0-rc9 to 1.0-rc10 (postgresql 12.6...Assignedpizza29.04.2021
50%
7 Task Description

I administer a small personal (<1K ticket) 1.0-rc9 instance running on a Fedora 32 host (php 7.4.16, postgresql 12.6) Following the upgrade instructions (ie transfer attachments, avatars, flyspray.conf.php) the setup/upgrade tool loads, and prompts me to upgrade.

Unfortunately, the upgrade fails spectacularly, with a reported SQL error that belies what’s actually wrong. Here’s a snippet from the postgresql logs where the upgrade is failing:

2021-04-28 10:33:07.190 EDT [2032049] ERROR: column “attachment_id” of relation “flyspray_attachments” already exists
2021-04-28 10:33:07.190 EDT [2032049] STATEMENT: ALTER TABLE flyspray_attachments ADD COLUMN attachment_id SERIAL
2021-04-28 10:33:07.194 EDT [2032049] ERROR: current transaction is aborted, commands ignored until end of transaction block
2021-04-28 10:33:07.194 EDT [2032049] STATEMENT: ALTER TABLE flyspray_attachments ADD COLUMN task_id INTEGER
[…and everything else fails because the transaction aborted…]

It appears that the upgrade script is blindly trying to create columns that already exist in the -rc9 database, and postgresql is treating this as a failure. Because the entire upgrade happens within one transaction, this means the entire upgrade fails at the outset and won’t ever succeed.

The way past this specific problem is to make these ALTER TABLE operations conditional (eg “ALTER TABLE flyspray_attachments ADD COLUMN IF NOT EXISTS task_id INTEGER”).

2636FlysprayInstaller and UpgraderBug ReportHighFailure to upgrade 1.0-rc9 to 1.0-rc10 (mariadb 10.4.18...Assignedpizza29.04.2021
50%
6 Task Description

I administer a moderate-sized (~14K ticket) 1.0-rc9 instance running on a Fedora 32 host (php 7.4.16, mariadb 10.4.18) Following the upgrade instructions (ie transfer attachments, avatars, flyspray.conf.php) the setup/upgrade tool loads, and prompts me to upgrade.

It churns a while before refreshing the screen, claiming a successful 1.0-rc10 upgrade. However, the upgrade seems to not actually “stick”, because clicking on the “return” button I’m dropped back into the upgrader, which is once again claiming I’m running 1.0-rc9 and prompting me to perform the -rc10 upgrade.

According to Flyspray’s admin ‘checks’ tab:

* PHP 7.4.16
* MariaDB 10.4.18
* default_charset: utf8mb4
* default_collation: utf8mb4_unicode_ci
* All tables are ‘InnoDB’

There are no errors logged that I can find, but the upgrade is clearly not working. If I revert to the -rc9 php files, everything continues along as if nothing was done.

Any suggestions?

2625FlysprayUser InterfaceTODOLowavoid password manager popups in admin prefs areaNewpeterdd10.02.2021
0%
11 Task Description

We must teach browsers not to use some input fields in the admin prefs area to offer to store it in their password manager.

Steps to reproduce:

  1. Login with Firefox as admin into Flyspray. (Maybe other browsers behave same)
  2. Go to admin prefs area (top right gear icon)
  3. Click link somewhere else (so leaving admin prefs page)
  4. Firefox browser pops up password manager as it detected some password input fields on admim prefs setting page. But in this case this is not wanted.

Either by using different input field names where the browser does not assume it is a login password field or find input field attribute to tell them.

auto-complete="off"

is not working anymore in browsers for password fields.

webbrowser: Firefox 85.0.2

Popup probably triggered by the password fields for configuring Email and XMPP notification: smtp_pass and jabber_password input fields. Firefox heuristic is too stupid to detect that these are for server configuration, not user login fields!

Neither

autocomplete="new-password"

nor

autocomplete="one-time-code"

attribute helped.

Stubborn Firefox ..

2620FlysprayBackend/CoreTODOMediumPHP8 compatibilityNewpeterdd26.11.2020
20%
2 Task Description

PHP 8.0 is now released (2020-11-26) and Flyspray should be made compatible with it.

  • Replace removed and deprecated functions with alternatives in our source code.
  • Upgrade used libraries or make used libraries compatible:
    • post github issue or pull requests for ADODB
    • upgrade used dokuwiki or make changes in our integration (probably just review our as official dokuwiki project contains too much stuff we do not need and changed much)
    • review used geshi
    • upgrade our swiftmailer version to PHP8 compatible version
    • upgrade our oauth2-client stuff to PHP8 compatible version
2598FlysprayUser InterfaceBug ReportLowuser registration in admin area: "username taken" but t...Assignedjoril20.03.2020
0%
32 Task Description

Trying to add a new user having the same email address as an another user in the do=admin&area=newuser section results in

“That username is already taken. You will need to choose another one.”

instead of

“Email address has already been taken”

(I’ve stumbled on this issue because I have an older disabled user with the same email address)

2573FlysprayBackend/CoreTODOLowadd rel nofollow,ugc,.. settingsNewpeterdd14.09.2019
20%
1 Task Description
  1. Find a good configuration name just reuse relnofollow as used by dokuwiki
  2. Find a good translation keyword for that config relnofollow
  3. Find a good translation keyword for config description (title attribute)

Goes into prefs table as it is sitewide configuration.

As first implementation a simple checkbox should be ok. Should be on the tab with other spam handling stuff like captcha configuration.

Is enabled by default (1).
Adapt setup xml files, upgrade procedure.


	
2559FlysprayBackend/CoreBug ReportLowa duplicate close accepted even when missing comment/ r...Newpeterdd29.07.2019
0%
Task Description

Closing a task with selected close reason duplicate should warn when there is no comment or FS # id is given in the close comment text field.

The task is closed as duplicate without any further notice. The information to which task it is duplicate or a description (if the problem is logged/handled outside Flyspray) is lost.

Possible solutions

Frontend hints

  • variant F1 (soft): When duplicate as close reason is selected, a placeholder attribute in the close comment text field could be shown/updated. (maybe as ‘css only’ possible)
  • variant F2 (harder): Deny sending the form if duplicate selected, but comment text field is empty. and shows warning info. (javascript required, nojs browsers still send form.)
  • variant F3 (hard): Deny sending the form if duplicate selected and no task id detected in comment text field. and shows warning info. (javascript required)

Backend deny

  • variant B1 (soft): When request wants close a task with duplicate reason and (cleaned) comment string is empty, deny closing the task and give feedback to user why it was denied.
  • variant B2 (hard): It requires detecting a task id in the comment field and the first detected task id is taken for referencing as ‘is duplicate of’. Limitation of this is that the duplicate could be also a ticket or something of a complete other system.
2316FlysprayBackend/CoreBug ReportLow"wrongtoken" is displayed if the comment box is left si...AssignedArthmoor22.11.2016
0%
71 Task Description

I understand this is likely due to some sort of XSS CSRF protection, but the delay doesn’t appear to be long enough to be useful for a lengthy comment to be posted. I’ve now lost two detailed comments in our tracker because the software threw everything out and generated a meaningless error.

Further, attempting to do the normal thing and making the browser resubmit the page results in Flyspray throwing “Error #3” something something repeated action and causing a redirect to the homepage.

Surely there has to be a better way to handle this that doesn’t incur data loss?

2118FlysprayUser InterfaceFeature RequestLowShow overview of existing tags for usersAssignedpeterdd09.04.2016
20%
Task Description

At several places it could be useful to let the user view available tags:

  1. When editing a task a toggle popup could show a list of selectable and existing tags.

I found several nice vanilla-js-multiselect-with-autocompletion scripts, but none yet that still works at a basic level when javascript is turned off.

My plan is now:

  • Keep the current basic input text field for input tags and show current assigned tags like exampletag1;exampletag2;exampletag3 separated by ‘;’ that is sent to the server when saving the task and server handles evaluation of that string (validation, duplicates, removed, added, creating new tags if allowed for current user)
  • A CSS only toggle that shows available tags that can be assigned (works even with js turned off), similiar to other places within Flyspray like advanced search toggle.
  • If js turned off, the user must type the tag - not as fancy, but at least works. (I thought also about using a html select with multiple=”multiple” attribute, but was not convinced due styling not possible in modern browsers without js)
  • If js is enabled, more fancier stuff is possible:
    • The input text field is hidden by display:none and instead the styled tags are shown.
    • The current added tags also get a little x to remove a tag by clicking it. The content of the hidden input text field is updated to reflect the current editing status. (click eventlistener)
    • A generated text input field for typing with autocompletion list shown of matching availbale tags. An unknown tag is added to the list if user is allowed to create tags. Clicking a item in the autocompletion list adds the tag and resets the autocompletion input text field for the next autocompletion action.
    • The tags within the toggle list with all available tags get also a click event listener, so clicking it adds them to the hidden text input.
    • Not sure yet if an added tag should be removed from the all available tags list or just make an CSS indication that a tag is still added, currently I tend to keep the list untouched, just highlight used tags of the task.
  • Optionally make the all available tags sortable by:
    • list_position (default)
    • alphabetic
    • global or project level
    • popularity (count of tasks using a tag (n + unnumbered private)), requires adding a data attribute.
    • group by detected prefix like shape:triangle shape:circle shape:rectangle could show a group of tags as: shape: triangle circle rectangle
  1. Make the list of tags searchable for the advanced search. added with FS1.0-rc10 by just using search key words also for searching list_tags table.
2063FlysprayBackend/CoreFeature RequestVery Lowshow closed/open usage count on do=pm&area=XXXNewpeterdd229.09.2015
10%
1 Task Description

Currently on

  • do=pm&area=cat
  • do=pm&area=version
  • do=pm&area=os
  • do=pm&area=resolution
  • do=pm&area=status
  • do=pm&area=tags
  • do=pm&area=tasktype

a count of usage in tasks is shown for every property.

Interesting would be if the counter shows the count for open/closed tasks on each row.

Showing tasks 1 - 11 of 11 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing