Flyspray

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.

[ ] ADOdb xmlschema03 issues
[ ] other warnings/notices

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.

From: https://groups.google.com/forum/?hl=en#!topic/flyspray/rAnks5y_uLk

19-04-09 // More one year ago.

There are not http → https redirections.

Only one example:
- http://www.flyspray.org/docs/download/ is not redirected to https://www.flyspray.org/docs/download/

Note: It is better to have the main website in https://flyspray.org/.

http://www.flyspray.org/ + https://www.flyspray.org/ + http://www.flyspray.org/ must be redirected to https://flyspray.org/

Regardless if a gmail.com or other address (tested with my gmail and also other email address)

So this is probably a mail server problem. I try to reach server admin.

I can see my “unfinished registrations” tests in the admin→checks area, but received no emails (waited and checking spam folders too)

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?

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?

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”).

My project has 37 pending requests. Each has a set of Accept / Deny buttons next to it.

If I click on Deny, a textbox pops up for me to enter “Reason for denial” but the entire page immediately regreshes/reloads back to the task list before I have a chance to enter the reason and submit it.

I can always “Accept” the request implicitly by going to the appropriate task and closing/re-opening it, but there’s no way to “deny” something without going through this UI path.

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)

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

• The @ operator no longer silences fatal errors. Some checks in installer or other areas might not work anymore as expected when the @-operator was used as silencer for previous PHP versions.

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.

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.

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

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

Backend deny