| Title | P4DTI doesn't allow customizable jobspec |
| Status | closed |
| Priority | essential |
| Assigned user | Nick Barnes |
| Organization | Ravenbrook |
| Description | The P4DTI completely takes over the Perforce jobspec, in a very constrained way. The jobspec is entirely determined by the replicated_fields configuration item. Users want [1] to be able to customize this jobspec, at the very least to be able to rename and reorder the replicated fields. Ideally they want to be able to set their own jobspec, and prepare it for the P4DTI by adding some fields but not otherwise modifying it. This is requirement 122. |
| Analysis | The real question is, how easy does this have to be for the administrator? It is already possible, for a Python programmer prepared to rewrite configure_bugzilla.py. The cheapest way to meet this requirement is for the P4DTI to allow configuration of the jobspec and the "field map" (which defines how issue fields translate to job fields). These two items are currently generated by the P4DTI based on configuration parameters such as replicated_fields. Simplified versions of these two items could be exposed in the configuration file itself, for advanced administration. But that's tricky to administer and not very compatible with the existing configuration. The best way to set up a Perforce jobspec is by using Perforce itself. Then the P4DTI administrator needs a way to say "don't update the jobspec", combined with a way of checking the current jobspec against the P4DTI config, and with a way of adding required fields to the jobspec without changing anything else about it. Happily the P4DTI has no dependencies on job field numbering, so if we want a field called "Priority" and there is such a field in the jobspec already, we can just continue using that field. As far as configuration is concerned, we need compatibility, so replicated_fields has to keep doing the right thing. We can add omitted_fields, for administrators who don't want to replicate 'resolution' (say). And field_names, for administrators who don't like the names chosen by the replicator. See also job000830 (checking the jobspec) and job000831 (extending the jobspec) which go some way to addressing this problem. |
| How found | customer |
| Evidence | [1] <http://info.ravenbrook.com/mail/2003/01/20/21-57-01/0.txt> |
| Observed in | 1.5.3 |
| Created by | Nick Barnes |
| Created on | 2003-05-16 16:39:26 |
| Last modified by | Nick Barnes |
| Last modified on | 2003-12-13 16:16:02 |
| History | 2003-05-16 NB Created. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 68273 | closed | 2003-12-12 21:24:59 | Nick Barnes | field_map becomes field_names, and the names of some magic fields are configurable. |
| 68221 | closed | 2003-12-12 14:00:16 | Nick Barnes | Add config-jobspec functionality to the AG. |
| 68198 | closed | 2003-12-12 11:56:58 | Nick Barnes | Jobspec extension. |
| 67950 | closed | 2003-12-10 16:31:08 | Nick Barnes | Add keep_jobspec configuration parameter, and catalog entries to support check_jobspec function. Note that keep_jobspec is not wired up yet. |
| 67276 | closed | 2003-12-05 13:08:38 | Nick Barnes | Improve documentation and testing of configurable jobspec features. |
| 65836 | closed | 2003-11-25 13:33:25 | Nick Barnes | Add configuration items omitted_fields and field_map, to allow configurable jobspec. |