Flyspray

Today I got first SPAM on bugtracker.

Question: Is it possible to enable CAPTCHA for anonymus task add?

Question 2: Is it possible to delete SPAM tasks.

There was a question on the mailing list:

I have a suggestion, even though I don´t know if it´s possible to do it. But if it is, it would be great!
In the comments list of a given task, is it possible that the comments appear from the newest one to the oldest ones, and not as it is now, with the new ones coming at the end of the list? This is because I deal with long comments list for a given task, and it is becoming difficult to reach the last one, that is, the newest comment, because the order in the comments is on the top, the older ones. If this could be altered it would be great. Kind regards
Ana ...

Quick anwsers:

1. Users can use ‘End’-key and ‘Pos1’-key on their keyboard to scroll to bottom and top of page. (lame anwser I know)
2. Another quick anwser is to just reverse the comments array in the appropriate template themes/CleanFS/templates/details.tabs.comments.tpl :

Replace

<?php foreach($comments as $comment): ?>

with

<?php
$comments_latestfirst=array_reverse($comments);
foreach($comments_latestfirst as $comment): ?>

But the real problem I think is that the details page (and others too..) is not optimized for todays wide screens (landscape views). Laptops have FullHD or higher but the Flyspray users still have to scroll to get an overview of a task.

And for narrows views too (mobile phones, tablet portrait view)

The attached screenshot shows moving the task details tabs beside their task description if the display width is over 1200 css pixel. (and the reversed comments too ). Done with pure css media query:

E.g. add to a custom stylesheet file custom_detailswidescreen.css in folder themes/CleanFS/ :

@media only screen and (min-width: 1200px) and (orientation: landscape) {
.details .tab.active{
        display:inline-block;
}
 
.details .tab{
width:44%;
padding-left:0px;
/*margin-top:60px;*/
box-sizing:border-box;
}
 
.details .commenttext pre {
overflow:auto;
}
.details .comment_container .comment {
width:auto;
margin-left:30px;
display:block;
}
.details .comment_avatar {
position:absolute;
}
.details #comments .fa.fa-user{
font-size:30px !important;
}
 
#submenu li a{margin-left:0;}
 
.details #submenu{
display:inline-block;
position:absolute;
padding:1em 0 0;
margin-top:26px;
}
 
.details #content{
display:inline-block;
box-sizing:border-box;
vertical-align:top;
width:55%;
}
 
/* just a temporary fix: should be redone in theme.css with class instead ids*/
#comments, #related, #notify, #remind, #effort, #history {margin-top:72px;}
 
}

(Has still some problems with current 1.0-rc1 when the project selector wraps. Also tab labels wrap if not enough width available and tab content do not adapt.)

What do you think? How should the details page look on different display sizes? How can it improve the workflow of the user?

Rethink the current sets of buttons and their functionality.

Maybe a mousover hint/cheatsheet of available dokuwiki syntax is more helpful in writing fast and efficient.

• buttongroup links http,email,ftp
• buttongroup code, code php: why a single button for php? maybe a cheatsheet or subselect for choosing a language (read directory plugins/dokuwiki/inc/geshi for that). Or even better: Let the project administrator define what source code languages are used/popular in a software project and dependend of that setting prefer/promote that languages
• I miss a blockquote- or cite-tag for citation, which is more semantic than bold, italic, underline buttons. Update: It is the > character followed by text!
• Show a cheatsheet (by mouseover?) of dokuwiki smileys as defined at plugins/dokuwiki/conf , update to current config of dokuwiki, facepalm for instance is missing

8-) 8-O 8-o :-( :-) =) :-/ :-\ :-? :-D :-P :-o :-O :-x :-X :-| ;-) ^_^ :?: :!: LOL FIXME DELETEME

icon_cool.gif icon_eek.gif icon_eek.gif icon_sad.gif icon_smile.gif icon_smile2.gif icon_doubt.gif icon_doubt2.gif icon_confused.gif icon_biggrin.gif icon_razz.gif icon_surprised.gif icon_surprised.gif icon_silenced.gif icon_silenced.gif icon_neutral.gif icon_wink.gif icon_fun.gif (not working as first character on a line, bug?) icon_question.gif icon_exclaim.gif icon_lol.gif fixme.gif delete.gif

This is at the moment just a bit brainstorming ..:

Let the project administrator define what source code languages are used/popular in a software project and dependend of that setting prefer/promote that languages at the dokuwiki editor buttonbar.

This requires probably an additional database field in the flyspay_projects table (if just used for dokuwiki that should be ok)

If thinking further like Filter me all software projects that may ontain CSS code on the projects overview, a m:n-table setup is thinkable. But thats maybe overengineering..
Or can we use the existing tag-feature for that and just ‘tag’ projects with tags?

If someone with ‘edit comment’-permission wants to edit a comment, the edit comment form is shown on an extra page.

This is not optimal, because the editor cannot see task details or the other comments while modifying the comment.

Possible Solutions

The register spam by probably bots in 2016 is annoying.

I ticked the setting, that an admin must accept a new registration. It helps to reduce spam task, but now admin must decide if the registrations are ok or just spam bots.

Beside the need of antispam-plugins, the management of users can be improved:

• column sorting of user list, similiar to the tasklist
• filtering user list, similiar to the tasklist
• pagination of user list (25,50,100,200,all?)
• more columns:
  • last login implemented
  • last activity (a resulting task/comment/project change in database)
  • tasks created implemented
  • comments created implemented
  • votes implemented

that may help to decide what status or settings a user should have in future.

• show time zone setting and language setting of users implemented in userlist now

• mass accept/deny of a list of user registrations waiting for admin approval.

Hello together,

it would be nice, if you could mention user in your ticket or comment which are not following the task.
for example when i will type @nickname, the user “nickname” should be get a e-mail that he is mentioned in the ticket.

(if we are “fancy” then we can print a automcomplete after the @-sign ist typed)

Maybe this is not an issue, but my problem is: upload images approximately 3000 px x 2000 px and this image appears larger than the monitor
is it possible that the image is automatically resized to 800 px x xxx px size

(reported by Ivan Cilic)

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

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'

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.

Currently the sessions are stored by the webservers default settings.

Having this sessions under control by Flyspray by storing it in the database has following advantages:

1. Allows handling of all sessions of a user by Flyspray.
2. Providing a session management for each user. The user can see on which devices he is currently logged in and could also force a logout on selective devices.
3. A forced logoff of all or some user sessions is easy implementable for admins.
4. Statistics about how many users and who is logged in. (user status: hide always, online, offline, do not disturb, ..)
5. Could make onpage-notifications easier to implement.
6. .. ?

Disadvantages:

1. A potential unknown security bug in Flyspray that could lead to reading a session db table could leak informations like who is currently online/active and make further attacks more focused or makes session takeover easier.
2. .. ?

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.

Motivation

Proposal

When a user is deleted from Flyspray, their opened tasks, closed task and task comments are then shown as Anonymous Submitter, the same way as anonymous reporters (not really anonymous, just that user does not have login account, but usually their email address is stored within that task data).

Currently just the entry from users table are deleted when a user is deleted. Their internal user_id integer is still within tasks and comments fields, and maybe some other tables too. So there is not a ON DELETE SET NULL rule or something like that applied. As it is just an autoincremented number by the system, this is not personal data imho and should be no problem for GDPR, but gives Flyspray the ability to distinguish between anon reporters and deleted users. Well, we could also look if there is an email address within task table entry for notification of anonymous reporter, but there are also tasks possible that have no user_id nor an email address.

It might by useful to present that information differently like deleted user or showing the info differently like icon + title-tooltip with explanation.

Also interesting what happens with mentions of a deleted username in a comment or task description. (see FS#2322)

The user isn’t in database, but deleting that now gone user should not modify tasks or comment where that username was mentioned I think.
But what if another user registers under that now gone username? In that case that new user would inherit that mentions. Probably we can ignore that edge case as there will be not much things will happen with an old mention in old tasks/comments.

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

Navigation and Forms

Editors

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.

It would be terrific to have a small pop-up window that appears when you click to start tracking of an item. In the window could be:

• the task name
• a timer
• a button to close the timer pop-up and jump to the effort tracking screen, or even to stop the effort timer in FlySpray if possible.

This would help tremendously to remind a developer that he has one or more timers going in FlySpray.

If multiple timers are started, there could be multiple timer windows, each identified by the task name showing as part of the window (title bar or some text near the timer).

For users with administrative permissions, a moderation UI for spam tasks could be useful.

For other normal users a “mark as spam”-button (similiar to voting for a task) could help moderators to identify spam tasks.

1. Modify the spam task: Move to a hidden “Trash” project, replace summary and description with a default spam summary text end empty description.
2. The decision which kind of punishment of the account who created the spam depends on several things:
   • Is it a previously normal used account who got captured by a bad guy and suddenly started spamming?
   • Is it a fresh bot created account who tried creating many spam task to promote bad websites or do search ranking manipulation?
   • Is it a sneaky smart account who waits for the opportunity to offload spam in a subtile manner?

I think this is not so easy to automate without producing false positives, especially for a project without commercial interest and funding and no huge meta informations like Google or similiar data collecting corporation who have the ability to identify spam waves across the internet.

From mailing list:

Hello,

I could not find if this was already posted before. We have this basic profile where customers only can create new tasks and receive some notifications when the status or details change. The idea is that they do not see the comments, we want to use them for internal communication.
The think is that we just realized that they can not see the comments when they login but they receive them as notifications by email!

We want this notification for the admin users involved in the task but not for the customers. Is there a way to correct this behavior?

Thanks,
Manu

When there is a link to the new task action from another site to a Flyspray installation and the user is not yet logged in, there is a redirect to the Flyspray start page losing the GET parameters.

Example:

https://bugs.flyspray.org/index.php?do=newtask&project=1&item_summary=blablabla%product_category=1

Or short example (nicer urls using .htaccess rules)

https://bugs.flyspray.org.de/newtask/proj1?item_summary=blablabla&product_category=1

After login the user should see the form with the original link parameters (if the user is allowed to and parameters are valid)

Currently the user must navigate to the correct project (if there are several) and the parameters from the origin link are lost.

I have been working with Eventum (http://www.mysql.org/downloads/other/eventum/) for quite sometime now and in contrast, I like Flyspray for its simplicity and practicality. But one thing I badly miss (and something that Eventum scores high) is a Workflow Engine. If not a sophisticated W.E., I (as an Admin / Manager) should be able define role-based state transition rules of the tasks reported in a particular project. For example, I should be able to implement the following scenario:

1. For a “Developer”, the subsequent tasks from various states. Likewise for other roles
2. “Developer” should not be able close out the bug reports. He/she can only flag them as implemented. The “Reporter” of the bugs or the “Manager” alone should be able to close out issues
3. ..
4. .. it will go on like that

This feature, in my opinion, is very crucial for corporate organizations to give a serious consideration to Flyspray.

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.

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

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.