• Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend/Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 0.9.5
  • Due in Version deprecated 1.0.0
  • Due Date Undecided
  • Votes 8
  • Private
Attached to Project: Flyspray
Opened by kswartz - 13.04.2004
Last edited by peterdd - 17.10.2015

FS#218 - Extensibility mechanism for adding new task properties

It would be great to have the ability to add additional fields to the task definition/detail pages – either as free-form text, or a list (which means adding something to the admin pages). For example: If I’m developing a web-based application, I would want to require every person reporting a bug to indicate the browser they are using as well. So in addition to adding that to the new task and details pages, I’d also want to add a list definition section to the admin page to define the list of acceptable browsers.

Although this is an extremely valuable feature, I think it’s a fair low priority because, thankfully, the code is well laid out and easy enough for even a half-decent coder (like me) to make the changes to the code directly.

In fact, the example above is a real one; after only a couple of hours of tinkering with the program, I was able to understand the code well enough to create the necessary database objects, and modify the necessary files to add a ‘Browser’ field to the task entry and details pages, as well as a page for modifying the list of acceptable browsers values for each project. The entire modification took no more than 30 minutes, which is a testament to a nice, clean, simple-to-use design. (Bravo!)

The task depends upon
ID Project Summary Priority Severity Assigned To Progress
744 Flyspray  FS#744 - Look and Feel: Task list column editor  Very Low Low
The task blocks these from closing
ID Project Summary Priority Severity Assigned To Progress
157 Flyspray  FS#157 - estimated time field  Very Low Low macnewbold
392 Flyspray  FS#392 - Add Start date  Very Low Low Floele
1090 Flyspray  FS#1090 - Hide some fields and add a javascript link to show theses hiden   Very Low Low
1174 Flyspray  FS#1174 - TODO List for 1.0  Very Low Medium
Closed by  peterdd
17.10.2015 04:45
Reason for closing:  Deferred

By the way, I'm not sure if this is the same as task  FS#156  I intepreted that one as suggesting the ability to NOT include certain *known* fields from the task forms.

Anonymous Submitter commented on 28.04.2004 05:33

Task #156 is indeed different. The requester seems to want the ability to define which existing fields to show in the task listing on the Flyspray front page. I understand that this task requests the ability to add/remove custom fields from the task details page.

Your interpretation of this task is correct.

Sorry for submiting a duplicate task. I thought I had seen over all feature requests. Obviously not. But as the date of this comment show, this request has been done some while ago. Has it been implemented in the 0.9.7 version or in devel version now? Or will it be in the near future ?

Anonymous Submitter commented on 29.04.2005 11:58

It has not yet been implemented. I probably won’t get to it anytime soon, but I accept help and patches.

Despite the code and the database being easy to modify to add fields, maintainance then becomes a nightmare. Every time you upgrade your flyspray, you’d have to at a minimum re-incorporate and re-test your modifications. And your custom changes may conflict with other changes to the source, which may mean you can’t even get them to work in a newer version.

If the ability to make custom fields for tasks isn’t coming soon, I’d at least like to see the static addition of the browser field, since it is a very common one in many projects. In the meantime, I’ve customized my OS list to include browsers, though it would be nice to be able to choose OS _and_ browser, since the same browser doesn’t do everything the same on every OS.

If it’s any easier, I’d be as happy to have the ability to hide some of the static fields. That way we could have a bigger list of fields, and not clutter up the page any further with fields that people don’t always need.

Anonymous Submitter commented on 08.06.2005 03:08

Someone again requested  FS#536  on the mailing list, so this task came to mind again. I was thinking about the standard set of fields we should have, and I think that all of them except ‘operating system’ are useful for any type of project. For upgrades, the ‘operating system’ field would be moved to the ‘custom’ area, and a suitable query in the upgrade script provided to make it work.

What does everyone else think? Are the rest of the fields useful for any type of project?

I think so, yes. There are some I don’t use, because one of my projects is self-managed so there’s nobody to assign anything to but me – but that’s clearly a corner case, and not the common use of this product.

After that, I’d agree that OS is important in *most* projects, but probably not all. I’ll also take this time to second Mac’s comments, in that browser would go into the same category of “most important after those that apply to all projects”. So if you wanted to have some examples of “custom” fields out of the box, those would be the two to pick, imho. (Or, if you prefer to spread it out: OS type, OS version, browser type, and browser version.)

As time passes, this enhancement is feeling more and more important. I think this would meet a lot of people’s needs for customization, by allowing them to decide what fields there are, and what values there are. I think the hardest part of doing this will be encoding the special behaviors of certain fields. For example, for the task status field, you have to encode which ones are open or closed (or “active” per  FS#276 ). If severity can be customized, then you’ve got to put some of the style data into the database (so they can set the colors for the various levels), or put a cap on the number of severity levels, so they never exceed the number of colors defined in a theme’s style sheet.

If we do this, I think the other thing that would make a lot of sense is to allow field types other than dropdowns. Checkboxes and small text fields would be my top two. Allowing textareas could be nice, but not critical, IMO. A numeric or integer type of field might come in handy as well. This may even be a way to incorporate a time or date type, like  FS#157  or  FS#293  would require. There really are a lot of tasks that this would address, like  FS#496  for example.

Another difficulty might be the database setup. Right now each field in a task is a column in the database, so adding columns would require the flyspray code to dynamically modify the structure of that table. As long as we don’t allow them to delete fields, but only add and rename fields, or make active/inactive, this could work quite nicely, in fact.

Another complication is this: If we had this feature, I’d want to be able to do it globally as a default, but on a per-project basis, be able to override the global settings, adding or inactivating fields above what the global set uses. One way to do this would be to have one global set of fields for all projects, and active/inactive (and maybe other) settings for each field for each project. Then we could allow admins to control the global settings and which fields are active by default, and project managers could add fields if needed, but when added to the global list, they would default to inactive for all the other projects.

Sorry for the brain-dump style that this comment has taken. I guess I’m somewhat “thinking out loud” about how this could happen.

Do you think it should be global or project related?

Anonymous Submitter commented on 04.09.2005 05:04

Both, but I’m sure that will be difficult, and increase complexity a hundred times.

Not if we think about it in the planning phase :)

See also  FS#744  which seems to be a duplicate of this one, or at least a very similar related issue.

It would seem that the due date needs to be adjusted, as October passed a while ago.

This one would seem to be a high priority if we’re going to do it for 0.9.9, because it ought to get tested very thoroughly.

wondering what the current status of this item is. It would really help to make Flyspray feature-complete.

Worth bearing in mind that sometimes you don’t just want to choose a single option. If I were designing this, things like the OS and Affected Version fields would be (capable of) multiple selects, and that should be possible for any custom field as well. More primitive types like Boolean and Integer should also be available, as should free-form text, and all those types should have configurable min and max length limits. To give you an idea, here’s the column type setup screen of tableau which is a configurable CSV↔HTML table editor that has been used as a basic bug tracker. When type is ‘opt’, only one option can be chosen (and if there are only 2 to choose from they are shown as radio buttons instead of a selectbox). When type is ‘multi’, any ‘n’ options can be chosen where ‘n’ is between min and max if specified. If there are only 2 options on a multi, checkboxes are used instead of a selectbox. This all helps usability.

Anyway, the subject at hand. Here’s one possible implementation:

Table flyspray_list_customfield:

  • customfield_id
  • project_id
  • customfield_name
  • list_position
  • show_in_list
  • type

[where type is enum(’bool’,’int’,’float’,’text’,’option_single’,’option_multiple’)]

For option_* fields, the available options are added to table flyspray_list_customfield_option:

  • customfield_option_id
  • customfield_id
  • customfield_option_name
  • list_position
  • show_in_list

Then for each task where the custom field is set, add a row to table flyspray_task_customfield_value

  • task_id
  • customfield_id
  • value

value would have to be a text field in order to cope with all the different possible data types (type checking would be done by the program, not the db). In the case of options the value would actually be an integer corresponding to a customfield_option_id. For multiple options, you could either add multiple rows, or (perhaps simpler) a single row whose value is a comma-separated list of the chosen option_ids. If the latter is chosen, SQL REPLACE can be used on this table irrespective of whether it’s a single or multiple choice, and single-choice fields can be trivially changed to multi-choice.

Hope that all makes sense! Would be good to know if any progress has been made on this already, and whether it’s likely to be in 1.0 – if not I may go ahead and do my own implementation which of course I’ll share with you.

Apologies for bad formatting...

I don’t see a vote button for this task. I would like to vote on it =)


Note to self: Possible option could be to determine a value per field which is selected by default on task creation.


Small status update: I have finished the first version of this feature to a great extend, expect a commit during the upcoming week. The first version will only offer two field types (list and date), but we should focus on ruling out bugs before we add more stuff since quite a lot of changes were necessary. So everyone who is interested in this task should help testing the new feature once arrives.


Available keyboard shortcuts


Task Details

Task Editing