Bug 298697 - [api] provide reusable widgets for custom attribute mappings
Summary: [api] provide reusable widgets for custom attribute mappings
Status: CLOSED MOVED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Mylyn (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2010-01-01 04:15 EST by Andreas Höhmann CLA
Modified: 2010-07-08 20:23 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Höhmann CLA 2010-01-01 04:15:14 EST
Build Identifier: 

This feature request based on an email I wrote to the integrator-mailinglist:

I want add a legend for the qc-mylyn connector to the task list. I found the following code in the bugzilla connector:

 /**
  * Overrides getLegendElements.
  *
  * {@inheritDoc}
  * @see org.eclipse.mylyn.tasks.ui.AbstractRepositoryConnectorUi#getLegendElements()
  */
 @Override
 public List<LegendElement> getLegendElements() {
     List<LegendElement> legendItems = new ArrayList<LegendElement>();
     legendItems.add(LegendElement.createTask("blocker", BugzillaImages.OVERLAY_CRITICAL)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("critical", BugzillaImages.OVERLAY_CRITICAL)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("major", BugzillaImages.OVERLAY_CRITICAL)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("normal", null)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("minor", BugzillaImages.OVERLAY_MAJOR)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("enhancement", BugzillaImages.OVERLAY_ENHANCEMENT)); //$NON-NLS-1$
     legendItems.add(LegendElement.createTask("trivial", BugzillaImages.OVERLAY_TRIVIAL)); //$NON-NLS-1$
     return legendItems;
 }

This looks like a "hardcoded" severity-mapping ... but in Quality Center (QC) its possible to define the severities for each project, i.e.

1 == BLOCKER and 5 is TRIVIAL
or
1 == TRIVIAL and 5 == BLOCKER
and so on.

And the number of severities is not limited (i.e. it's possible to define 10 severity levels).

Now the question, how can we provide a nice legend for our connector?
What can we do to support a Legend for each configured qc-repository?
I created a "Serverity Mapping Section" on our repo-settingspage, but how can I access these mapping-informations in the getLegendElements()?

PS: the same problem exists for the priority ... in qc it's also possible to define multiple priorities

Then frank becker wrote:

in getTaskKindOverlay you can use

try {
BugzillaRepositoryConnector connector = (BugzillaRepositoryConnector) TasksUi.getRepositoryConnector(task.getConnectorKind());
TaskRepository repository1 = TasksUi.getRepositoryManager().getRepository(task.getConnectorKind(),
task.getRepositoryUrl());
IProgressMonitor monitor = null;
RepositoryConfiguration repositoryConfiguration = connector.getRepositoryConfiguration(repository1, false,
monitor);
} catch (CoreException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

but actual I see now way that you can extend the UILegendControl to show the values per repository or product level. I think that you should create a new view in your connector.

Then mik kersten wrote:

Rather than creating your own view for this, it would be great if you could contribute a patch to support a per-repository rendering of the legend.  If that seems like it will blow up the legend too much, consider contributing collapsible sections to it where you could put the per-repository rendering.

So here we are :)

What we need (pseudocode):

How can connectors provide the legend entries?
1a. each "RepositoryConnectorUi" can overwrite a new method 
   getLegendElements(repository)
1b. mylyn could provide a extension point for that
(this is a design decision - mik?)

2. the task list legend view must check each legend element "every time" the view become visible (I don't know if this is already implemented or if the current implementation read the legend element only one time ... but I have the sourcecode and I will find it out *g*)

3. the "new" ui layout of the legend view is currently not so clear for me ... imagine a connector supports dynamic legend entries (i.e. the qc-mylyn connector will do that) and a user configure 5 repositories ... then the legend view must have space for 5 blocks. At the moment each connector will produce only one block in the legend view. 

Maybe we can do that:
3a. if a connector doesn't support multiple legend blocks than the legend will be placed in the "common connector list"
3b. if a connect support multiple legends then a new block only for this connector will created (after the common block) and this block will contain a legend block for each (active) repository.

Please give me your feedback

Andreas

PS: And a happy new year!!! :D

Reproducible: Always
Comment 1 Andreas Höhmann CLA 2010-01-03 16:18:45 EST
I started the implementation. The implementation of support for dynamic severities (not priorities!) for each connector-repository should not be so hard, I can use getTaskKindOverlay + customized severity-icon per connector/repository + enhancement for the legend view.

But I see an other problem ... mylyn uses standard priorities (1..5). The legend dialog shows these priorities in the first row. 

I see two ways how we can handle "dynamic" priorities:
a) each connector can map the customized priorities to the 5 mylyn-priorities or
b) each connector can provide priorities as much as he want and mylyn must handle this
    I found 3 places in the mylyn code where the standard-priorities are hardcoded:
    org.eclipse.mylyn.internal.tasks.ui.views.PriorityDropDownAction.addActionsToMenu()
    org.eclipse.mylyn.internal.tasks.ui.dialogs.UiLegendControl.createPrioritiesSection(Composite)
    org.eclipse.mylyn.tasks.ui.TasksUiImages.getImageDescriptorForPriority(PriorityLevel)
Comment 2 Steffen Pingel CLA 2010-01-04 13:12:01 EST
The idea behind using the 5 pre-defined priority levels is to provide a recognizable icon set and unified user experience across connector for managing task priorities. It's easy to provide a custom chooser for the task editor using the attribute editor factory. I am not sure that I see sufficient incentive to provide additional customization beyond what's currently available. 

Andreas, could you post a more detailed example of a repository configuration to support your use case, i.e. a typical set of severity and priority levels supported by your repository?
Comment 3 Andreas Höhmann CLA 2010-01-06 13:32:33 EST
I understand and I'm 100% agree with you steffen ... the priorities should be a mylyn-core-definition and each connector must map the "external" to the default priorities. 

For the qc the story is a little bit more complex, because you can configure the number (and the order) of priorities (and severities) for each project. So I will must implement a customizable mapping for our qc-mylyn-connector. Maybe the code for mapping priorities (severities) on a connector-preferences-page is reusable for other connectors.

A example:

Project  Priority      Severity
----------------------------------
 A       1 - Very High 1 - Blocker
         2 - High      2 - High
         3 - Normal    3 - Normal
         4 - Low       4 - Feature
----------------------------------
 B       1 - Low       1 - Blocker
         2 - Normal    2 - High
         3 - High      3 - Normal
         4 - Very High 4 - Feature

... and all combinations you can imagine ;)

The number and the order of severity and priority is "free". I guess the value is only a string in qc.

So I will implement a priority mapping section for our settings-page:
- prio-mapping-section:
    * qc-prio-#1 -> selectbox (mylyn-priorities)
    * qc-prio-#2 -> selectbox (mylyn-priorities)
    * qc-prio-#3 -> selectbox (mylyn-priorities)
    * ...
    * qc-prio-#n -> selectbox (mylyn-priorities)

For severity I'm not sure if this makes really sense ... because then I must give the user a totaly free mapping section like this:
- severity-mapping-section:
    * qc-severity-#1 -> choose severity-image (file-open-dialog)
    * qc-severity-#2 -> choose severity-image (file-open-dialog)
    * qc-severity-#3 -> choose severity-image (file-open-dialog)
    * ...
    * qc-severity-#n -> choose severity-image (file-open-dialog)

Guys please give me some input :-D
Comment 4 Steffen Pingel CLA 2010-07-08 20:23:05 EDT
We have seen similar requirements for configuration UI of that sort for other connectors, as well e.g. to support custom workflows in Bugzilla. I have updated the summary accordingly.

While we don't have a strong enough driver within the Mylyn project at the moment we would be happy to consider adding this to the framework if anyone is interested in contributing it.
Comment 5 Eclipse Webmaster CLA 2022-11-15 11:45:08 EST
Mylyn has been restructured, and our issue tracking has moved to GitHub [1].

We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub.

[1] https://github.com/orgs/eclipse-mylyn