From: Lincoln M. <Lin...@qu...> - 2005-03-21 23:44:15
|
Hi all, Firstly I would like to apologise for the way each of my emails end up being longer than even quite a few English essays I wrote in school. My problem is that I do prefer to try and explain myself as fully as possible: I hope it does not put too many people off. Hey, print it out and read it on the train home tonight :) So with the (admittedly small amount of) feedback I got regarding support for a fixed in build field, I have gone the route of enabling the functionality through enhancing the custom fields. The beauty of using custom fields for this concept is that each project can decide on whether or not they want / need to use it. Following are the steps I took to implement this. Hopefully they are generic and useful enough to be checked in to the main branch. By default nothing changes and although related to build numbers specifically, there is no assumption about the actual custom fields that are associated with the build numbers. 1) Added an option on custom fields that allows us to have an enumeration but still allow users with a particular access level to add options to this enumeration 'on the fly'. When a user does not have the permission to do this they are presented with the dropdown (for example) as normal. When a user does have the permission, however, the first option is '[Create New]' and alongside this dropdown is a string 'with value:' then a normal input box. When the user selects to create a new value we take the text from the input box and use this, instead. Once this is done we add the input text to the actual list of selections so that it will actually be an option next time. In our case the select box is populated through a function call however a developer is still able to add a new build number to the list when necessary. 2) Created a function named 'helper_get_all_builds'. Firstly, this populates an array with the normal build numbers found in reported issues. Next, we look at a configuration variable ('fixed_in_build_list'). This array is a list of the names of each custom field that is used to represent fixed in build values. If the array is empty we obviously do nothing, otherwise we then cross reference those custom fields and get all of the values that are set within the appropriate custom fields in the appropriate projects. We then tie this 'helper_get_all_builds' function to the 'print_build_option_list' function so that now we see both 'found in build' and 'fixed in build' values in all build lists. In effect, we have tied the custom fields in with the normal build values. We also tie the 'helper_get_all_builds' function to the initial custom field/s that we are using to support the fixed in build solution. This now allows all possible build options to be shown when choosing a value for the custom field. 3) Finally we set a configuration flag ('changelog_fixed_in_build') that lets us show the changelog as a collection of issues with a common custom field value. Again, we use the 'fixed_in_build_list' array to determine what custom fields we should be grouping on. I am also considering changing the page even more so that it has the option to show the page as either a fixed in version changelog or a fixed in build changelog (so it won't be a hardcoded option). The three other features I have added (separate from the 'fixed in build' code) are: 4) Added the ability to only store the index of custom field selections. This basically allows the user to change the values of an enumeration and automatically change all instances of this value (imagine having a version list: A|B|C|D|E. After using this list for a few months, the decision to change the versions to 1|2|3|4|5 is made. By storing the index we haven't set the version values themselves within issues and so when we change the list the issues themselves don't need to be changed to reflect the new list). At the moment you are required to set this setting before actually using the field at all but I am looking into the best way to allow converting after you've started using it. 5) Custom field validation: The option to associate a custom field with a function that actually validates it in some way. For example, you could use this on an input box to ensure that it contains a telephone number. 6) 'create_new_build_threshold' and 'use_build_list' allows us to stop showing an input box for entering build numbers when reporting an issue. Like the create new threshold on custom fields we have a level of access required before allowing users to enter a new build number. This functionality uses the helper_get_all_builds function. I believe that (4) and (5) are useful options for everyone. (6) would be useful to quite a few people, too, as it encourages using the same values for build numbers and so makes it a lot easier to filter and so on. (1) would also be useful to a few people and finally (2) and (3) would be useful for anyone who uses the concept of fixed in build. So, which of these changes should I check in and which of them should I definitely not check in (obviously I believe there should not be a problem with all of them going in)? Also, with the impending 1.0 release, which of those that I should check in should be done before 1.0? Thanks for reading this far, Lincoln. |