Community
Participate
Working Groups
After bootstrapping on the latest head I do not see the target milestone field on Eclipse.org bugs any longer. I had to toggle the option to suppress the field in the repository preferences to make the field appear. There are two problems with that: * Users will perceive this as a regression since the target milestone field simply disappears on synchronization of a task. * The state displayed in the repository properties dialog does not actually reflect the behavior of the task editor (i.e. the target milestone was not checked, still the field was not displayed in the editor) I also see a Classification field now that was not there before. I would strongly suggest that we maintain the Mylyn 3.4 behavior for backwards compatibility, i.e. suppress Classification and show Target Milestone by default.
Steffen, sorry for this. You can fix this by open the Eclipse.org Tatsk Repository Properties. I think we must define an other parameter that tell use if we use the new parameter. If this parameter did not exists we fall back th the old way. Do you think that is OK?
Created attachment 177049 [details] patch Steffen, can you please verify that this fix the problem? Thanks.
Created attachment 177050 [details] mylyn/context/zip
The idea of this patch looks right to me. I would prefer though if property accessors were encapsulated in a utility class to avoid code duplication between BugzillaRepositorySettingsPage and BugzillaClient, e.g. BugzillaUtil { public static boolean getUseTargetMilestone(Repository) { String useParam = taskRepository.getProperty(IBugzillaConstants.BUGZILLA_PARAM_USETARGETMILESTONE); return useParam == null || Boolean.parseBoolean(useParam); } }
Created attachment 177162 [details] commited patch
Created attachment 177163 [details] mylyn/context/zip
patch is in HEAD
Thanks Frank. There is still some duplication in regard to handling properties and I wonder if the template handling might throw NPEs. Let's do another review once Rob gets back from vacation.
As far as I can tell the logic that determines whether an attribute has been configured or if the default is to be used is duplicated in several places. Frank, I firmly believe that we should extract that into a utility methods so there is a single place where the policy for the default is defined (comment 8). Can you consider doing that?
Created attachment 178004 [details] commited patch V3 here is what I commit to HEAD. Steffen is this what you requested in comment#9 ?
Created attachment 178005 [details] mylyn/context/zip
Steffe, if you think there is some open work please reopen this bug.
*** Bug 334413 has been marked as a duplicate of this bug. ***
