Flyspray - The bug killer!

This is the Bug Tracking System for the Flyspray project. This is not a demo!

2019-04-22: Flyspray 1.0-rc9 released See https://github.com/Flyspray/flyspray/releases

ID Category Task Type Severity  desc Summary Status Progress Assigned To Due In Version Opened Last Edited
2337DocumentationInformationLowFlyspray ThemesNew
0%
402.02.201716.02.2017 Task Description
  • Flyspray 1.0 includes 1 default theme CleanFS. That decision was made to reduce maintainance effort and the old blue theme was dropped. Also the CleanFS contains UI-logic implemented in HTML/CSS and tries to be usable even for the people who turned off javascript in their web browsers for security reasons. (and reduces spam on many other websites too without an adblocker)
  • Current Flyspray source and the theme CleanFS provides several methods to customize the layout without touching the .tpl files. These are:
    1. custom_*.css files that extend or overwrite properties of CleanFS/theme.css
    2. 2 fields in admin area where to put code
      ?do=admin&area=prefs#lookandfeel

      For instance a corporate footer menu or something like that.

Advantages of CleanFS instead running your own

  • Theme is maintained with Flyspray source. Detected security issues related with themes are fixed with Flyspray releases.
  • Added features or capabilities are implemented for the default theme.

‘Subtheme’ can be a compromise: Theme CleanFS is always uptodate in sync with Flyspray. Subthemer only needs to check changes required for own subtheme .tpl files.

I do not want complete stop people from writing their whole new template, it allows new ideas implemented or alternative usability. For them, it is probably better to create a Github project for that theme.

This is just raw info from me and can be discussed. Something should be finally written on https://www.flyspray.org in the documentation area.

2436Backend/CoreBug ReportLowdokuwiki renderer creates nonunique html-id for h1,h2,h...New
0%
202.08.201702.08.2017 Task Description

The dokuwiki renderer automatic creates for each h(1-6) tag an html id attribute, but doesn’t ensure that this:

  • is not used by Flyspray templates
  • is unique across all tasks (tasklist summary/description mouseover!), id must be unique on a webpage.

Example: id=”footer” and id=”title” are used by the default CleanFS template for example.

id=”footer”

title

id=”title”

title

id=”title1”

title

id=”title2”

The original intention I think is to make dokuwiki content each h-section linkable, for instance by a “table of contents” at top of a wiki content page.
This is currently not used by the dokuwiki integrated in Flyspray, but could be in future.

Possible solution

Add the task_id to the generated id h(1-6) tags, for instance “d1234_footer” “d1234_title”

d - like description

(t1234 used for tags/labels id currently)

2439Backend/CoreFeature RequestLowClone a ProjectNew
0%
15.09.201715.09.2017 Task Description

There is a request for cloning a project on Flyspray mailing list:

Would be a very welcome features to have Project Templates for repetitive workflow. Any idea if its in the pipeline?
Thanks

Well, not yet.

The question is, how exactly you want that project clone.

Do you want just a rough copy of the project table entry?
Thats quite easy and can even be done without programming or writing a line of SQL just by using PHPMyAdmin (or similiar Tools for PostgreSQL) and copy a row of the project table for example.
See yellow marked project table on the right of the attached dbschema screenshot.

The other extreme is copying every project depending list table entries to new ones.
This sure requires some programming, but not too hard to add this to Flyspray. (all yellow marked tables in the attached dbschema screenshot.

I attach a rough form mockup how could this could look like.

Possible solution

  1. add a new file scripts/ folder for instance copyproject.php (check admin permission)
  2. add a template file to themes/CleanFS/templates/copyproject.tpl
  3. Set a link to that clone form page somewhere, for example on the toplevel page of a project (see screenshot)
  4. Handle the adminuser (or add a clonepermission for that project manager usergroup) submitted form careful and savely either by includes/modify.inc.php (or like scripts/copyproject.php to keep it seperate from core)

The link to the clone form looks then ?project=123&do=copyproject

2440Backend/CoreFeature RequestLowOption to disable tag featureNew
0%
15.09.201715.09.2017 Task Description

There is a wish on the Flyspray mailing list:

Is there a way of hiding the TAGS input field from the Add New Task form?
Alan

If it is just hiding on that form, there are several options to achieve this (from simple to complex)

A) Hide by CSS

Add that rule to themes/CleanFS/theme.css CSS file:

#edit_tags{display:none;}

B) Hide by CSS (better)

Add a rule to a custom_*.css, for instance themes/CleanFS/custom_mytheme.css

#edit_tags{display:none;}

and choose custom_mytheme.css in your project settings.

D) Edit themes/CleanFS/templates/newtask.tpl directly

and remove the whole div-tag with id=”edit_tags” (all between ‘<div id=”edit_tags>”’ and its closing ‘</div>’ (not recommended)

E) Use a custom template

  1. Create a folder in themes/, for instances themes/mynotagtheme/
  2. Only copy themes/CleanFS/templates/newtask.tpl to themes/mynotagtheme/templates/newtask.tpl
  3. Make the changes to that newtask.tpl like in B) (custom theme not overwritten by Flyspray Updates if you keep or backup your themes/mynotagtheme/ folders, but requires review if something has changed within themes/CleanFS/templates/newtask.tpl between version updates)
  4. Choose your mynotagtheme as project theme. All other files fall back to default themes/CleanFS/

(not tested, but thats the way it should work with current Flyspray 1.0-rc5)

D) Nag or caress someone

to finish tag feature for Flyspray with options/permissions to turn it off per project or project group or something like that.

This would effect not only that newtask form but all places where that options should kick in (listing tags in tasklist, tasklist filters etc)

2444Installer and UpgraderInformationLowcomposer hits memory limitsNew
0%
04.10.201704.10.2017 Task Description

Quick anwser: enable swap partition on your server.

Tried upgrading a rc4-dev to rc5-dev/rc6/flyspray-master on a virtual server with 500MB RAM and php5.6.30 on the commandline (debian)

After file upgrade, I wanted also update the vendor stuff according to composer.json changes.

But surprisingly this failed:

php composer.phar update

and also after

php composer.phar selfupdate


to version Composer version 1.5.2 2017-09-11 the memory limit bug exists:

The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details

PHP Warning:  proc_open(): fork failed - Cannot allocate memory in phar:///var/www/***/composer.phar/vendor/symfony/console/Application.php on line 979

Warning: proc_open(): fork failed - Cannot allocate memory in phar:///var/www/***/composer.phar/vendor/symfony/console/Application.php on line 979

  [ErrorException]
  proc_open(): fork failed - Cannot allocate memory

Also doing a more fresh vendor install like

rm composer.lock
rm vendor/*
(keeps the .htaccess there)
php composer.phar install

300 MB not enough for a handful of php package installations? wtf, but didn’t dig deeper..

I temporarly solved the problem by making a swap partition on this vServer like suggested at
https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
chmod 600 /var/swap.1
/sbin/swapon /var/swap.1
free
             total       used       free     shared    buffers     cached
Mem:        506300     374920     131380      30628      21904     143872
-/+ buffers/cache:     209144     297156
Swap:      1048572          0    1048572

This is just documentation and is for the people who prefer a Flyspray development version from github.com

Full Flyspray release download files do not needs to fiddle with composer.

Maybe an entry for the FAQ

2454Backend/CoreBug ReportLowPHP warning in admin edit user areaNew
0%
15.01.201815.01.2018 Task Description

Since PHP7.2 shows a warning in admin area ?do=admin&area=users&user_id=1234567890, when user_id is set, but no alternative user_name parameter.

Probably related to scripts/admin.php

$id = Flyspray::UserNameToId(Req::val('user_name'));
if (!$id) {
  $id = Req::val('user_id');
}
2491Backend/CoreBug ReportLowgroup member links if project manager but not adminNew
0%
1.001.09.201801.09.2018 Task Description

When a user has project manager permissions, but not admin permissions, then on the ‘edit group’ pages like index.php?do=pm&area=editgroup&id=8
the links in the list of users of that group are

index.php?do=admin&area=users&user_id=12345

instead of linking to the users page

index.php?do=user&area=users&id=12345

and a redirect follows with Error #4: You don’t have administrative rights.

2531TranslationsFeature RequestLowdetect usage of translation keywordsNew
0%
110.01.201919.03.2019 Task Description

Some translation keywords of Flyspray are used at more than one code location.

To help translators doing the correct translations, it would help to show in what context a translation keyword is used.
Especially when a keyword is used more than once.

As we have our own translation helper integrated into Flyspray, we could show a ‘translation keyword usage counter’ there and maybe show on request in which file
a translation keyword is used.

It would also help to identify ‘abandoned’ translation keywords that are not used anymore by Flyspray source.

Also it would help to identify when a translation is used at more than one location with maybe different context.

I think we can use a regular expression and scan the whole Flyspray source for that.
(and maybe database entries if there are places that have translation keywords stored - I don’t think so, but better check that too first than forget that case)

The regular expression should match that examples case insensitive for the translation keyword report:

L('report' 
L("report"
eL('report'
eL("report"

but also ugly cases like
l(    'report'
or 
El ( "report"

case insensitive.

But not for example

createURL('report'
2535Backend/CoreFeature RequestLownew optional Flyspray setting: add new users automatica...New
0%
216.01.201921.01.2019 Task Description

When a Flyspray installation allows user self registration and has public but also more private projects, this feature could make the required configuration more clear:

In this case, keep the number of global user groups as low as possible and the global user group for basic or just registered users has only the ‘can login’ permission and nothing more.
Because that only would be useless for new registered users, adding them also to a basic user group of a public project could be useful.

So my suggestion is:

A new optional global setting: Something like ‘default project user group’ (store 2 values: a project_id and a group_id). Validity of that setting must be checked during any user registration, so that project must exists now and at later time as also that project user group within that project. (’Checks’ of admin prefs)

So it would be like this for a new registered userA:

  1. userA is in a basic default global user group: only login permission to handle his account registration (login, logout, user preferences, password forgotten)
  2. userA is in project X default user group: some basic permissions you want allow for every (new) registered user in project X
  3. project Y: all ‘allow anyone ...’-settings are unchecked, userA not in any user group of project Y

The setting is probably best put below the ‘Default global group for new users’ setting in the global admin prefs tab #userregistration as

Either: A dropdown list with all public projects with an existing user group and dependend on the selection the available basic project groups are loaded by ajax as a select list too.

Or: Only one dropdown list that contains a list of public projects with possible project user groups. Would not require extra ajax calls and is maybe enough because we could exclude project groups that have project manager permission or such configuration nobody would allow new registered users.

no default project user group
public projectA - simple user groupA1
public projectA - simple user groupA2
public projectB - simple user groupB
public projectC - simple user groupC

This idea could be enhanced further (put the new user to multiple public projects when he registers or let user choose from public allowed projects during registration process), but lets start simple.

2548User InterfaceFeature RequestLowCSS grid layout for task details page typeNew
0%
05.05.201905.05.2019 Task Description

Layouts from 320 pixel mobile portrait, tablet sizes and up to 4k monitor landscape mode using

@media queries

Mockups required not only for different sizes, but also different project configurations, user permissions, and task relations.

Should look ok whatever project configuration is done or how weird a task description is.

On wider screens the comments could be beside the task description for instance.
Or some tabs or menus could be shown directly instead of grouping in the tabs.

2553User InterfaceTODOLowintelligent accesskey shortcut helper dependent of OS, ...New
50%
106.06.201929.07.2019 Task Description

The HTML accesskey attribute feature is differently accessible dependent of operating system, web browser and web browser configuration, and users keyboard layout and user language.

By taking advantage of the User-Agent HTTP header value provided by default by web browsers, Flyspray could better know of what kind of keyboard and browser the user sits in front off and show the key combinations for the accesskey feature that best fits the users environment.

2554User InterfaceTODOLowkeyboard shortcuts help box should adapt to current pag...New
0%
06.06.201906.06.2019 Task Description

The shortcuts help infobox should adapt to the current page type.

So when in editing a task for instance, the n (next task) and p (previous task) shortcuts are not available for a good reason. Listing them there with same priority as other keys then is not helpful.

The simpliest solution is probably putting some if-statements depending on the $do variable into CleanFS/templates/shortcuts.tpl ..

2559Backend/CoreBug ReportLowa duplicate close accepted even when missing comment/ r...New
0%
peterdd29.07.201929.07.2019 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.
2560Backend/CoreBug ReportLowdo not allow close task with reason duplicate referenci...New
0%
peterdd29.07.201929.07.2019 Task Description

So closing a task

FS#1

with

reason: duplicate

and close comment

FS#1

referencing to self should be detected to avoid such user mistakes.

2572User InterfaceTODOLowadd link attributes ugc and nofollow to user generated ...New
0%
13.09.201913.09.2019 Task Description

no task description

2573Backend/CoreTODOLowadd rel nofollow,ugc,.. settingsNew
20%
peterdd114.09.201915.09.2019 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.


	
2575Backend/CoreFeature RequestLowability to view and reset Flyspray default settingsNew
0%
19.09.201919.09.2019 Task Description

Motivation

Over the years the count of possible Flyspray configuration options has grown. Meanwhile there are ~60 global Flyspray settings stored in the prefs database table in contrast to only 14 entries of the 0.9.7 (not 0.9.9.7!) version from around 2005. But each configuration setting might add a little to the feeling of overwhelming when there are too much switches, buttons, checkboxes and probability of a misconfiguration raises due misunderstood or overseen settings.

But Flyspray still aims to be easy to use and work with while being accurate and customizable.

Proposal

Having a way to view the description and default value of each option would probably give people administrating a Flyspray installation a better understanding of each setting and confidence in making good decisions for their use case.

With the flyspray-install.xml file within the setup folder we yet have an elegant solution that is waiting to unlock its power!

Unfortunately the setup/ folder requires (until now at least) to be removed after install or upgrade. So we need a way to keep the flyspray-install.xml of the installed version. A trivial way would be to copy it to the include/ directory after any install or upgrade, but also other solutions could be.

Keeping the flyspray-install.xml could making following features easier:

  • Reading default value of prefs setting. That could be shown for example as css title attribute /tooltip for each setting in the matching admin forms.
  • Reading default value and field description of any table field using the descr feature of ADOdb xmlschema03.
  • Comparing the real database structure with the table structures in flyspray-install.xml . This could be useful if someone extended or fiddled with database/tables to compare with official Flyspray releases. Or for developers to compare if an database upgrade went well and as intended.
  • Having the description of a setting or database field contained within the flyspray-install.xml is good at one place and the information is not spread around like in an external manual/wiki that maybe get unmaintained, not in sync with the application or get even lost over the years.
  • Using the xml format makes a migration easier (in a broader context, to Flyspray or away from Flyspray)
  • Using the descr tag could be used to hold information which field(s) of a database table is/are foreign key field(s) pointing to primary key field(s) of another table, even if ADODB xmlschema03 does not support it yet. Would generating database schema diagram directly from flyspray-install.xml possible. (instead of manually painting it that gets outdated when structure changes)

Things to take care:

  • ADOdb and xmlschema03 does not handle table comments and field comments yet. The descr tag so is there only used when looking into the .xml file, but it does not appear in the real database schema. To make this happen, there is a good portion of contribution to the ADOdB project required (making pull request, but also get them reviewed, tested, accepted and released with a ADOdb stable release)
  • ADOdb xmlschema03 does not define or handle foreign key constraints. Adding that would require a substantial amount of constribution to get it working reliable for all supported databases that could use foreign key constraints.
  • limits of table comment length, field comment length depend on database type and database version
2581User InterfaceFeature RequestLowreplace bitmap icons of default themeNew
0%
31.10.201907.12.2019 Task Description

I played with adding a dark mode color theme to the default CleanFS theme.

To make the dark theme just simple exchange some colors, the bitmap icons should be replaced with alternatives.

Easiest would be using the fontawesome font icons as Flyspray still uses them and they can simply get a css color assigned.

Examples

  • caret of tasklist
  • the ‘select all’ icon of tasklist, but also used at some more locations.
  • some icons in the Flyspray main toolbar (Overview, Tasklist, Event log, ..)
  • the black calendar icons for date selects
  • maybe the file type icons for attachments

Editors

  • Dokuwiki toolbar
  • CKEditor: some modern CKEditor themes support color/dark mode, I will probably choose the moona-lisa theme as default.
2586Backend/CoreTODOLowPHP7.4New
50%
peterdd1.0-rc10312.12.201918.02.2020 Task Description

PHP 7.4 is out now and a few things should be done to make Flyspray work well with it.
Nothing really breaks, but a view deprecation warnings should be fixed.

Flyspray source itself: Just a few new notices, most are yet fixed in the master branch.

Watching the PHP7.4 compatibility of dependencies defined by composer.json:

  • ADOdb/ADODb: 5.20.15 should be OK for Flyspray
  • swiftmailer/swiftmailer: We still use 5.* branch, so either do quickfix for a notice in a fork or upgrade/rewrite our integration to the 6.* branch.
  • ezyang/htmlpurifier: 4.12 OK
  • thephpleague/oauth2-client: unknown, we still use 0.13, last real source change was Nov 2018, to upgrade requires rewrite of integration into Flyspray and there is low demand for OAuth2.
  • dapphp/securimage: seems to be OK
  • jamiebicknell/sparkline: OK, but probably obsolete for us in future due
    • still annoying problems with our github/travis tests (problem of travis, not sparkline itself)
    • better solution (interactive hover infos, scales, screen size adaptive) by Flyspray source planned
2606Database QueriesFeature RequestLowduedate column sort asc in tasklist should put unset du...New
0%
02.05.202002.05.2020 Task Description

When a tasklist contains the duedate column and the user sorts by duedate ascending, the tasks that do not have a duedate set should not be listed first. Instead they should be listed after the tasks with duedates.

This way a user can see the task with the earliest duedate first instead of seeing a bunch of probably not so important tasks without duedates set.

1236User InterfaceFeature RequestLowMark Issue As Verified or UnverifiableUnconfirmed
0%
3409.04.200718.07.2016 Task Description

Currently, the Vote functionality provides users a way to say "this issue is important to me". In addition to that functionality, it would be great for users to have a "Verify" ability on open issues; it would provide users a way to say "yes, this happens to me as well".

A "Verified" label would fit nicely right under "Votes", to the right of the label would be "Yes | No", each option being a link. After clicking Yes or No, or if unable to specify (lack of permissions), the text would display "Yes - # | No - # (% verification)" where '%' is the result of ((Yes/(Yes+No))*100).

This feature should not show up on all issues, though. It does not make sense to "verify" a feature request or todo item, for example. When defining task types, the administrator would specify if a type was "Verifiable" by checking a box in a column next to "Show".

If implemented, two great, mini extra features would be:

  1. The ability for the administrator to set the number of "Yes" verifications an issue would need before it was elevated to the next priority, severity, or both (specified by the administrator).
  2. The ability for the administrator to set the number of "No" verifications an issue would need before it was lowered to the previous priority, severity, or both (specified by the administrator).

Both settings should have an option to be incremental (priority / status increased every x verifications) or not (increases once, no matter how many verifications are received); an "Incremental" checkbox would do nicely. Also, a little "Enabled" checkbox next to both settings would be clearer than having zero act as the disable mechanism.

As with voting, a permission should exist to enable or disable this option for a user group. For larger projects, moderators tasked with verifying bugs could be given the permission whereas smaller projects may leave verifications up to the community.

Lastly, a way to send a notification once the number of "Yes" verifications reached a certain value would also be a great addition.

1481User InterfaceFeature RequestLowDiff visualisationUnconfirmed
0%
4104.05.200809.03.2015 Task Description

Flyspray should be able to render attached patches visually like, for example, Bugzilla: https://bugzilla.wikimedia.org/attachment.cgi?id=4807&action=diff

1491User InterfaceFeature RequestLowCustom task table columns for individual usersUnconfirmed
0%
2.0301.07.200801.10.2015 Task Description

Allow individual users to define custom views of the task tables much like the project manager can for the entire project; only on a user scale.

An option for the user to "use default" project settings should be possible and should be the default.
Only pro users will change it to their needs, not the average reporter.

Interesting would be the possibility to change it dynamic on the tasklist view, not only on the myprofile setting page.

Open Question: Simple or complex implementation?

  • Simple: A new varchar field for the user table like it is in the project table and provide the same field chooser like on project setting page.
  • Complex: User settings for global tasklist view and each project. Needs extra 'project_user' (or 'user_project' ;-) ) join table. Well, maybe over engineered.
1518NotificationsFeature RequestLowShow last date/time when a reminder was sentUnconfirmed
0%
15.11.200815.11.2008 Task Description

This information is already stored in the table "reminders" in field "last_sent". It might be helpful in some situations, if this date/time would be visible to the user on the reminder list, too.

1521Backend/CoreFeature RequestLowAssignees should be able to see and create reminders fo...Unconfirmed
0%
22.11.200818.04.2009 Task Description

In version 0.9.9.5.1 (unfortunately I couldn't select this version in the dropdown list on the left), reminders can only be created and edited by Admins and Project Managers. I recommend to give Assignees the permission to create reminders for themselves. To minimize any programming impact, his may be done as part of the "edit own tasks" permission.

This topic has been reported by Engie as part of Bug #713 for version 0.9.8 as well: "Also it would be useful if a user could create reminder for himself." Although that bug is already closed ("fixed in devel"), this part is not yet solved in the current version.

1539Backend/CoreFeature RequestLowSitemap.xml GenerationUnconfirmed
0%
2.12112.01.200911.03.2015
1599User InterfaceFeature RequestLowImplement "Tasks not blocked by other tasks"Unconfirmed
0%
2.1111.08.200903.03.2013
1608Installer and UpgraderBug ReportLowreserved characters cause database error after installa...Unconfirmed
0%
2.107.10.200903.03.2013
1612Backend/CoreFeature RequestLowAllow Comments by anonymous UsersUnconfirmed
0%
2.02120.10.200917.01.2013
1628NotificationsFeature RequestLowGlobal Notification addressUnconfirmed
0%
2.0125.02.201017.01.2013
1670User InterfaceFeature RequestLowAssign Key-Shortcuts to form fieldsUnconfirmed
0%
04.12.201004.12.2010
1749User InterfaceBug ReportLowSubmit form buttons on lower rightUnconfirmed
50%
117.06.201224.09.2015
1977Backend/CoreBug ReportLowWeird URL after closing task with referenceUnconfirmed
0%
115.03.201518.03.2015
1983Backend/CoreFeature RequestLowExport Roadmap as "Changelog"Unconfirmed
0%
21.03.201521.03.2015
2025User InterfaceFeature RequestLowAdding new tasks is too undiscoverableUnconfirmed
0%
109.08.201509.08.2015
2045User InterfaceFeature RequestLowneed add option for can set default Severity and Priori...Unconfirmed
0%
204.09.201504.09.2015
2046User InterfaceFeature RequestLowGrouping in Task List Unconfirmed
0%
104.09.201504.09.2015
2048Backend/CoreBug ReportLowerror when adding data containing national charactersUnconfirmed
0%
09.09.201509.09.2015
2052Text RenderingFeature RequestLowAdd Markdown syntax option for task descriptionsUnconfirmed
0%
216.09.201508.08.2016
2068Backend/CoreInformationLowDeprecated: mysql_connect(): The mysql extension is dep...Unconfirmed
0%
710.10.201508.12.2015
2083User InterfaceInformationLowDrag and drop tasks on roadmapUnconfirmed
0%
30.10.201530.10.2015
2107AuthenticationFeature RequestLowSupport CAS Server AuthenticateUnconfirmed
0%
202.03.201604.09.2019
2142Backend/CoreBug ReportLowPost-authenticate redirect does not make use of baseurl...Unconfirmed
0%
28.06.201601.08.2016
2160Backend/CoreBug ReportLowCannot "accept" PM close request if already closedUnconfirmed
0%
14.07.201614.07.2016
2198User InterfaceBug ReportLowMulti-Select from tasklist offers options to those who ...Unconfirmed
0%
1122.08.201622.08.2016
2203Backend/CoreInformationLowlanguage files are in folder lang. But i can't change l...Unconfirmed
0%
121.09.201621.09.2016
2210User InterfaceInformationLowTasklist color for due dateUnconfirmed
100%
612.10.201618.10.2016
2214Backend/CoreInformationLowChanging status of task automaticallyUnconfirmed
0%
417.10.201606.11.2016
2216NotificationsFeature RequestLowAdd slack integration (webhook)Unconfirmed
0%
1118.10.201625.10.2018
2220Backend/CoreInformationLowOne status with different color in tasklistUnconfirmed
0%
524.10.201603.11.2016
Showing tasks 201 - 250 of 316 Page 5 of 7

Available keyboard shortcuts

Tasklist

Task Details

Task Editing