Redmine

Dear all,

For the past few months I've known that there would come a moment rather sooner than later that I have to temporarily stop my Redmine participations almost completely for an undetermined period of time. Now it looks like it is going to happen...
My personal rough estimate is that it'll take about three to six months or so. During this time I'll only try to keep following the Redmine development (as in Activity -> Changesets), I won't triage incoming issues and I won't collaborate on forum-messages.
I have completed most of my outstanding things-to-do related to Redmine. Three things I didn't finish:

• I was working on a pull-request for improvements to the Redmine Spent Time Column plugin by Plan.io in my fork of the plugin (@ https://github.com/MischaTheEvil/redmine_spent_time_column). I completed most of what I was expecting to do. Though, there remains a pull-request to be merged and some small other things needs to be wrapped up before I were able to propose it (again, since I pulled-back my earlier pull-request on this matter).
  During this all JPL has implemented the initial feature of the plugin (with r8073 for #971), and more specifically - since I was working on providing a way to disable other plugin features - made all this useless once Redmine 1.4.0 is out. What remains? I think I'll try to complete my pull-request over time. I'm not even sure it'll be accepted or not, but I think it'll be good if the plugin can be completed in an improved state for users who are still using current Redmine 1.2.x and 1.3.x versions.
• I had a list of things that occurred to me while I was working with Redmine over the last few weeks. I still had to do some more research on them before submitting them here at redmine.org, but as remaining time is running out, I decided to paste in the raw content of the file for referencing purposes. Besides that, maybe even someone takes over and creates a correct issue for some of them. Whenever I have some ad-hoc time available I'll try to look into them after all.
  

  > FILED AS #9849 (Defect 1) - issue custom field values of several custom field formats don't get set/updated properly during email issue creation/reply:
  
        Wrong behavior with version-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index but:
            1. during next issue edit, the field isn't pre-filled with the current value.
            2. on the issuelist the custom field filter doesn't catch the issues with the custom value "set" via email
  
        Wrong behavior with user-format icf without default value and enabled as an issue filter:
          * value set by mail is not displayed on issues/show nor in columns on issues/index, besides:
            1. during next issue edit, the field isn't pre-filled with the current value.
            2. on the issuelist the custom field filter doesn't catch the issues with the custom value "set" via email
  
        Wrong behavior with boolean-format icf without default value and enabled as an issue filter:
          * value set by mail is not displayed on issues/show nor in columns on issues/index, besides:
            1. during next issue edit, the field isn't pre-filled with the current value.
            2. on the issuelist the custom field filter doesn't catch the issues with the custom value "set" via email
  
        Good behavior with list-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        Good behavior with date-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        Good behavior with text-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        Good behavior with long text-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        Good behavior with integer-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        Good behavior with float-format icf without default value and enabled as an issue filter:
          * value set by mail is displayed correctly on issues/show and in columns on issues/index, and:
            1. during next issue edit, the field IS pre-filled with the current value.
            2. on the issuelist the custom field filter does catch the issues with the custom value "set" via email
  
        At first I though it was affecting version/user format icf's only, but then I included all the other formats in my tests and noticed incorrect behavior with the boolean format too.
        In all of the above situations the keywords and their values were correctly stripped (thus recognized) and more importantly, the CORRECT values were/are written into the @custom_values@ table.
        Note: to be sure I tested this bahavior for the other (native) issue attributes but these don't seem affected.
  > FILED AS #9850 (Feature 2) - Differenciate available shared versions in version-format custom fields drop-downs by prepending its project name (like the target version attribute drop-downs)
  > (Defect? 3) - Due to the fact that shared versions are recently included in version-format custom fields values, it is possible that we have
        duplicate values. As long as we can seperate them through the UI (see (2)) that is ok.
        Though, while testing for [[RedmineReceivingEmails]], I came around the situation that I can (should be able, see (1)) provide
        a value for a version-format custom field. For email-receiving this is done by providing the value, using a keyword, by its name. 
        The above leads to a possible error since I don't know if the duplicated values are distincted in any way. Which value will be
        used in such case? Does this also affect the Redmine REST Api?
  > (Feature 4) - Change query-parameter in issuelist link in reminder email to include the due date column in the issuelist
  > (Feature? 5) - The parameter allow_override= values tracker, priority & category are the only ones that are required to set the tracker, priority and category by using keywords in the email
  > (Defect? 6) - Additions/removals of lines containing only whitespace are ignored in a wikipage version diff
  > (Defect 7) - Using {{macro_list}} macro in wikipage breaks TOC before heading containing actual macro (see e.g. http://www.redmine.org/projects/redmine/wiki/RedmineTextFormatting)
  > (Feature 8) - Add per query setting for including subprojects' issues or not on the issues lists (like currently already done in ChiliProject: https://www.chiliproject.org/issues/672)
  > FILED AS #9851 (Feature 9) - Equalize the way how available shared versions are differenciated in target version drop-downs (they differ between issues/new and issues/index)
  

• I have several issues assigned to me. Some of them are easy things to document other things requires coding a complete new plugin. I'll keep these assigned as these things are probably easy to do in some ad-hoc moments of spare time during the upcoming period. Unless no one completes them completely before I can I am still planning on completing them myself whenever available time lets me do it.

For now I'd like to thank the whole community for their continued support for Redmine which I've seen during my involvement in the Redmine project over the last three years or so. I've seen the numbers of users grow extensively and still believe JPL and the still-growing community can improve the application even more to becoming more flexible and user-friendly at the same time, while retaining and improving its robustness.

At last, I would like to take a moment to wish everyone happy holidays and a healthy and positive new year. Take care of your loved ones...

 
Kind regards,

Mischa The Evil.