Flyspray :: https://bugs.flyspray.org/ Flyspray :: Flyspray - The bug killer!: Recently edited tasks 2019-02-06T00:59:54Z FS#2408: spam https://bugs.flyspray.org/index.php?do=details&task_id=2408 2019-02-06T00:59:54Z anonymous FS#2543: spam https://bugs.flyspray.org/index.php?do=details&task_id=2543 2019-02-05T02:50:28Z anonymous spam spam

]]>
FS#2483: Tags is actually only for a single tag https://bugs.flyspray.org/index.php?do=details&task_id=2483 2019-01-28T12:41:53Z Lucas K Just relabel it to say “tag”.— OK, that’s everything i’ve noticed in my 30-45 minutes of playing around... hope you find any of this helpful! Just relabel it to say “tag”.

OK, that’s everything i’ve noticed in my 30-45 minutes of playing around... hope you find any of this helpful!

]]>
FS#2102: strict ordering of tags required https://bugs.flyspray.org/index.php?do=details&task_id=2102 2019-01-26T13:25:02Z peterdd When saving the tag list at admin and project area, the ordering of the tags must be recalculated. So it is not more legal to have a list ordering like (0,0,0,1,3,4,7) That should be recalculated and stored as (1,2,3,4,5,6, 7) (or 0,1,2,3,4,5,6)currently in file includes/modify.inc.php Why? The SQL for the tasklist uses currently GROUP_CONCAT (and a equivalent syntax for postgres) that groups by list_tag.list_position.Well, we could just ‘group by’ the tag_id too, but with list_position value we can show the most important tags first. 3 times, and that 3 result fields must be in the same order. (tag id, tag name, tag class field) Also that sql-query part there needs a little modification, but first fix that strict ordering. Alternative Don’t use group_concat() or similiar for list_tag.tag_name or list_tag.class. Instead load an indexed array once per http request and only when needed. For instance as function within class.flyspray.inc.php: /** * load all tags into array * * compared to listTags of class project, this preloads all tags in flyspray database * ideally maximal called once per http request, then using the array index for getting info * * @return array */ public static function getAllTags() { global $db; $at=array(); $res = $db->query('SELECT tag_id, project_id, list_position, tag_name, class, show_in_list FROM {list_tag}'); while ($t = $db->fetchRow($res)){ $at[$t['tag_id']]=array( 'project_id'=>$t['project_id'], 'list_position'=>$t['list_position'], 'tag_name'=>$t['tag_name'], 'class'=>$t['class'], 'show_in_list'=>$t['show_in_list'] ); } return $at; } in scripts/index.php in function tpl_draw_cell(): function tpl_draw_cell($task, $colname, $format = "<td class='%s'>%s</td>") { global $fs, $db, $proj, $page, $user, $alltags; ... case 'summary': ... if($task['tagids']!=''){ # if global $alltags are yet undefined, preload the tags now. if(!is_array($alltags)) { $alltags=$fs->getAllTags(); ... foreach($tagids as $tagid){ $tgs.='<i class="tag t'.$tagid .(isset($alltags[$tagid]['class']) ? ' ' .htmlspecialchars($alltags[$tagid]['class'], ENT_QUOTES, 'utf-8') : '').'" title="'.htmlspecialchars($alltags[$tagid]['tag_name'], ENT_QUOTES, 'utf-8').'"></i>'; } When saving the tag list at admin and project area, the ordering of the tags must be recalculated.

So it is not more legal to have a list ordering like (0,0,0,1,3,4,7)

That should be recalculated and stored as (1,2,3,4,5,6, 7) (or 0,1,2,3,4,5,6)
currently in file includes/modify.inc.php

Why?

The SQL for the tasklist uses currently GROUP_CONCAT (and a equivalent syntax for postgres) that groups by list_tag.list_position.
Well, we could just ‘group by’ the tag_id too, but with list_position value we can show the most important tags first.

3 times, and that 3 result fields must be in the same order. (tag id, tag name, tag class field)

Also that sql-query part there needs a little modification, but first fix that strict ordering.

Alternative

Don’t use group_concat() or similiar for list_tag.tag_name or list_tag.class. Instead load an indexed array once per http request and only when needed.

For instance as function within class.flyspray.inc.php:

        /**
         * load all tags into array
         *
         * compared to listTags of class project, this preloads all tags in flyspray database
         * ideally maximal called once per http request, then using the array index for getting info
         *
         * @return array
         */
        public static function getAllTags()
        {
                global $db;
                $at=array();
                $res = $db->query('SELECT tag_id, project_id, list_position, tag_name, class, show_in_list FROM {list_tag}');
                while ($t = $db->fetchRow($res)){
                        $at[$t['tag_id']]=array(
                                'project_id'=>$t['project_id'],
                                'list_position'=>$t['list_position'],
                                'tag_name'=>$t['tag_name'],
                                'class'=>$t['class'],
                                'show_in_list'=>$t['show_in_list']
                        );
                }
                return $at;
        }

in scripts/index.php in function tpl_draw_cell():

function tpl_draw_cell($task, $colname, $format = "<td class='%s'>%s</td>") {
  global $fs, $db, $proj, $page, $user, $alltags;
...
  case 'summary':
...
    if($task['tagids']!=''){
                        # if global $alltags are yet undefined, preload the tags now.
                        if(!is_array($alltags)) {
                                $alltags=$fs->getAllTags();
...
 foreach($tagids as $tagid){
                                $tgs.='<i class="tag t'.$tagid
                                        .(isset($alltags[$tagid]['class']) ? ' ' .htmlspecialchars($alltags[$tagid]['class'], ENT_QUOTES, 'utf-8') : '').'" title="'.htmlspecialchars($alltags[$tagid]['tag_name'], ENT_QUOTES, 'utf-8').'"></i>';
                        }
]]>
FS#2523: tagname length not checked (was tags containing a comma (,) produce an sql error) https://bugs.flyspray.org/index.php?do=details&task_id=2523 2019-01-24T16:01:10Z lynxis flyspray version: 1.0-rc6 How to reproduce:Create a bug with tags (preferable with spaces)Edit this bugChange the spaces to &#8216;,&#8217; Save Expected behaviour:Saves the tag with comma (even ; is the correct seperator).It looks to me, that sanitisation of user input is missing here. flyspray version: 1.0-rc6

How to reproduce:
Create a bug with tags (preferable with spaces)
Edit this bug
Change the spaces to ‘,’ Save

Expected behaviour:
Saves the tag with comma (even ; is the correct seperator).
It looks to me, that sanitisation of user input is missing here.

]]>
FS#2536: store session in Flyspray database https://bugs.flyspray.org/index.php?do=details&task_id=2536 2019-01-21T06:44:41Z peterdd 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: Allows handling of all sessions of a user by Flyspray. 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. A forced logoff of all or some user sessions is easy implementable for admins. Statistics about how many users and who is logged in. (user status: hide always, online, offline, do not disturb, ..) Could make onpage-notifications easier to implement. .. ? Disadvantages: 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. .. ? 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. .. ?
]]>
FS#2062: review do=admin&area=editallusers https://bugs.flyspray.org/index.php?do=details&task_id=2062 2019-01-21T06:11:55Z peterdd Bugs Small javascript issue: When checkbox of one users row clicked, it doesn&#8217;t select the checkbox because the row click event handler doubles the click (check and uncheck, tested with firefox41). Clicking in the row (not on the name) selects the checkbox. fixed browser back button after delete of a user not working as expected. (fix it by redirect 303 , see modify.inc.php how it done for other form submits) Missing features no sorting possible of the table (like tasklist) no paging (like on tasklist) OK, probably not needed: ~2000 user registrations on bugs.flyspray.org and no problem rendering the table in browser. no filtering of user list possible no helpful information for admins like registration date and last time of login of users (last login time requires a new field in flyspray_users) implemented in Flyspray 1.0-rc7 no summary about users like how many exists or how many are currently online (requires storing sessions in a db session (e.g. flyspray_session) table instead php default session directory) on the install. Or a statistic graph of activity or peaks of new registrations over time. maybe show user profile image too in the list. choosable user field columns - partially implemented since 1.0-rc7 by selecting groups of user fields and calculated user fields: user stats, user settings Bugs
  • Small javascript issue: When checkbox of one users row clicked, it doesn’t select the checkbox because the row click event handler doubles the click (check and uncheck, tested with firefox41). Clicking in the row (not on the name) selects the checkbox. fixed
  • browser back button after delete of a user not working as expected. (fix it by redirect 303 , see modify.inc.php how it done for other form submits)

Missing features

  • no sorting possible of the table (like tasklist)
  • no paging (like on tasklist) OK, probably not needed: ~2000 user registrations on bugs.flyspray.org and no problem rendering the table in browser.
  • no filtering of user list possible
  • no helpful information for admins like registration date and last time of login of users (last login time requires a new field in flyspray_users) implemented in Flyspray 1.0-rc7
  • no summary about users like how many exists or how many are currently online (requires storing sessions in a db session (e.g. flyspray_session) table instead php default session directory) on the install. Or a statistic graph of activity or peaks of new registrations over time.
  • maybe show user profile image too in the list.
  • choosable user field columns - partially implemented since 1.0-rc7 by selecting groups of user fields and calculated user fields: user stats, user settings
]]>
FS#1972: Advanced search form - ideas for faster/better usability https://bugs.flyspray.org/index.php?do=details&task_id=1972 2019-01-18T00:49:59Z peterdd This task can maybe splitted into separate sub tasks. Task properties Current situation Currently 8 multi select fields with height of 5.5 visible options. For most of the selects you must scroll to make the right selections. floating Ideas Multi select option styling Some (not all, intentional!) browsers support CSS styling of option tags. For these who support it I think option styling is a good usability enhancement: severity: We use background colors for styling in task list, so we should use the same colors for the select. priority: maybe, but must be good distinguishable from severity styling. maybe not background, but maybe icons,borders,lines? task type: This styling would be related to an other task, where I suggest icons/font icons for bugs, feature requests and TODO (see also themes/CleanFS/custom_example.css) progress: maybe use the green %-bars as background styling status: If for some status types very intuitive icons exists, they could be used for the options too. due version: no idea yet, no option styling reported version: no idea yet, no option styling Update: CSS of option tags working in multi selects: Firefox 64: yes Safari 12: no Google Chrome 71: no So only Firefox. The intended styling could be also achieved by Javascript that renders alternative select boxes based on reading the original select boxes and their option attributes and show the user CSS styled div-tag or li-tag based constructs which do not have such restrictions. Custom fields challenge/doom level - doom faces: from easy/normal to bloody/angry face os: logos like tux for linux, devil for bsd, window for ms, apple icon, osX icon, android, apple, iphone/smartphone icon, ipad/tablet icon, .. But Consider: Different project may need different custom fields. Your gardening project may need no OS version selector. Make some intelligent positioning and sizing dependent on the count of options of the selects. This task can maybe splitted into separate sub tasks.

Task properties

Current situation

  • Currently 8 multi select fields with height of 5.5 visible options.
  • For most of the selects you must scroll to make the right selections.
  • floating

Ideas

Multi select option styling

Some (not all, intentional!) browsers support CSS styling of option tags. For these who support it I think option styling is a good usability enhancement:

  • severity: We use background colors for styling in task list, so we should use the same colors for the select.
  • priority: maybe, but must be good distinguishable from severity styling. maybe not background, but maybe icons,borders,lines?
  • task type: This styling would be related to an other task, where I suggest icons/font icons for bugs, feature requests and TODO (see also themes/CleanFS/custom_example.css)
  • progress: maybe use the green %-bars as background styling
  • status: If for some status types very intuitive icons exists, they could be used for the options too.
  • due version: no idea yet, no option styling
  • reported version: no idea yet, no option styling

Update: CSS of option tags working in multi selects:

  • Firefox 64: yes
  • Safari 12: no
  • Google Chrome 71: no

So only Firefox. The intended styling could be also achieved by Javascript that renders alternative select boxes based on reading the original select boxes and their option attributes and show the user CSS styled div-tag or li-tag based constructs which do not have such restrictions.

Custom fields

  • challenge/doom level - doom faces: from easy/normal to bloody/angry face
  • os: logos like tux for linux, devil for bsd, window for ms, apple icon, osX icon, android, apple, iphone/smartphone icon, ipad/tablet icon, ..

But Consider: Different project may need different custom fields. Your gardening project may need no OS version selector.

  1. Make some intelligent positioning and sizing dependent on the count of options of the selects.
]]>
FS#2535: new optional Flyspray setting: add new users automatically to a project user group https://bugs.flyspray.org/index.php?do=details&task_id=2535 2019-01-16T17:28:12Z peterdd 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 &#8216;can login&#8217; 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 &#8216;default project user group&#8217; (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. (&#8217;Checks&#8217; of admin prefs) So it would be like this for a new registered userA: userA is in a basic default global user group: only login permission to handle his account registration (login, logout, user preferences, password forgotten) userA is in project X default user group: some basic permissions you want allow for every (new) registered user in project X project Y: all &#8216;allow anyone ...&#8217;-settings are unchecked, userA not in any user group of project Y The setting is probably best put below the &#8216;Default global group for new users&#8217; 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. 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.

]]>
FS#2534: Private projects https://bugs.flyspray.org/index.php?do=details&task_id=2534 2019-01-16T11:51:57Z Trent Gamblin I would like to restrict certain projects from view from normal users (Basic group.) I couldn&#8217;t find out a way to do it. I could restrict them from viewing tasks, which is good, but it would be nice to hide the project entirely from the Overview screen. I would like to restrict certain projects from view from normal users (Basic group.) I couldn’t find out a way to do it. I could restrict them from viewing tasks, which is good, but it would be nice to hide the project entirely from the Overview screen.

]]>