Project

General

Profile

Actions

Feature #3335

closed

multiple database schemas

Added by Matt Schifter about 15 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-05-11
Due date:
% Done:

0%

Estimated time:
Resolution:
Wont fix

Description

It would be handy to be able to divide a cm template (source tree) into a multipurpose cm environment.

The implementation idea is to support a particular schema from a source tree downwards. This allows, for example, bitmaps to have one set of issue criteria, and code to have another set of issue criteria.

It would also allow for an informal test subfolder, and a formal test subfolder. We could also use a different schema for our tech support department, qa department, and electrical engineering department. Each department collaborates on the same project but performs different tasks.

Actions #1

Updated by Jean-Philippe Lang about 15 years ago

  • Status changed from New to Closed

Request is too vague.

Actions #2

Updated by Matt Schifter about 15 years ago

  • Status changed from Closed to Reopened

Mr. Lang,

When you closed this issue because it was too vague, I thought I would give it another shot at clarifying the idea -- you just might like this one.

Multiple project support is great.

But my team works within different areas of expertise on a single project:

1. Electrical engineers work on AutoCAD drawings, and they should have their own schema type to support their 4-state drawing approval process (working, issued, approved, , plus somewhat unique attributes (eg, whether an item is deliverable).

2. Mechanical engineers use SolidWORKS and they use their own cm system, but project planning and delivering has to be unified with the rest of the teams.

3. Software teams use an obviously different schema as you well know.

4. Just using Redmine as an issue/task database, our interactions with our customer and intra-team deserve their own schema. We are lifecycle driven, so these documents get attached and associated with their lifecycle components (eg., PDR or "Preliminary Design Review," CDR or "Critical Design Review," "Deployment"). Also, using standard attributes on documents , such as "SRR" ("Software requirements review"), this allows for custom, saved searches to locate, for example, all requirements documents.

Hope this helps,

Matt

Actions #3

Updated by Etienne Massip over 12 years ago

  • Category set to Database
Actions #4

Updated by Marius BÄ‚LTEANU over 5 years ago

  • Category deleted (Database)
  • Status changed from Reopened to Closed
  • Resolution set to Wont fix

I'm closing this because the issue is very old and if I've understood right, the request refers more to support different workflows which can be already obtained by configuring the workflow per tracker type and role.

Also, making the workflow (Trackers, Issue Statuses, Workflow, etc) configurable per project, not globally like now is tracked in #1853.

Actions

Also available in: Atom PDF