| Title | Can't easily replicate by project |
| Status | closed |
| Priority | essential |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | It's hard to set the replicator to replicate only those issues in a particular project or group of projects. |
| Analysis | For TeamTrack, the administrator could do this by subclassing the teamtrack_case class and writing their own replication policy in the replicate_p method. But that is too hard for a configuration item that we expect many users to need. A similar solution would apply to Bugzilla, but there is an easier way, namely using MySQL to mark a set of bugs as modified (e.g. all open bugs for product 'foo'). I have added section 6.1 to the AG to illustrate this problem and suggest that solution for Bugzilla users. NB 2001-02-16. Actually replicate_p methods are not very hard. Put one in and mark it for advanced users only. NB 2001-02-16 |
| How found | inspection |
| Evidence | In the AG: "We must explain how to replicate just the cases belonging to a single project RB 2000-11-20". |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 9 |
| Created by | Gareth Rees |
| Created on | 2000-12-04 09:47:20 |
| Last modified by | Gareth Rees |
| Last modified on | 2001-12-10 19:08:09 |
| History | 2000-12-04 GDR Created. 2000-12-04 RB Improved description for end users. 2001-02-16 NB Make general, rather than tTrack-specific, and describe Bugzilla solution. 2001-02-16 NB Add note on replicate_p solution. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 8605 | closed | 2001-02-16 16:14:13 | Richard Brooksby | Documenting the replicate_p parameter. |
| 8602 | open | 2001-02-16 16:04:23 | Nick Barnes | Add replicate_p configuration parameter. |
| 8596 | open | 2001-02-16 14:35:57 | Nick Barnes | Add AG section 6.1, on migrating sets of issues. |