Feature #3335
closedmultiple database schemas
0%
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.
Updated by Jean-Philippe Lang almost 16 years ago
- Status changed from New to Closed
Request is too vague.
Updated by Matt Schifter almost 16 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
Updated by Marius BÄ‚LTEANU about 6 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.