2 - 3 : Indeed configuration per structure level (on Edit Structure) : *this* structure is available to <list of types>.

4 : Only nice to have : but if cookie implementation remains in the future then you could add logic that changes cookie info for
* changing the order of the structures in the "select" box
* to indicate this is the default structure for the current issue type
* to indicate this is the default filter for the current structure
But only nice to have.

Walter, thanks for the great ideas! Here are my comments:

1: Agree

2: I can see the value in this, however the good implementation would require not only limiting the structure per-type, but also per-project-per-type, which increases administration complexity (already quite high, given the synchronizers feature). I suppose we will come to implementing this, but probably not soon - unless we have more feedback about this.

3. Oh... In (2), did you mean define available issue types on the per-structure level, or as a global configuration? "*this* structure is available to: <list of types>" or "Structure plugin is available for: <list of types>"?

4: How would this work? Right now you have your "current" structure, remembered as a cookie in the browser, and it is selected every time unless you change it.

1. When no structure is available for the user (e.g. no view rights are defined for his role) => do not show the 'structure section' (as this can be confusing). This the follows the same logic as subtasks/links where the sections are not visible if no subtasks/links are available.

2. Define for which issuetype the structure is available/not available.
As you can now create multiple structures (which is great btw!) you can start linking structures to certain issue types

3. Define which issuetypes shows the 'structure' section and which don't.
(can be implemented by the combining the above 2 features)

4. Define the default structure for an issue (when multiple structures can be consulted)