Hi,
I'm afraid that I couldn't bring myself to wait for next week. I think I
worked out why we ended up with products using the full name. It is to
do with the way that Trac's main ticket fields use the name field to
specify the resources from other tables. We could of course change the
schema to respect this convention but, as we might consider other
changes to immutable fields, we could introduce a change like this to
core Trac:
Index: trac/trac/ticket/api.py
===================================================================
--- trac/trac/ticket/api.py (revision 1404839)
+++ trac/trac/ticket/api.py (working copy)
@@ -165,6 +165,7 @@
(rank, field)
where field is a dictionary that defines:
* name: the field name
+ * pk: the primary key of the field table
* label: the label to display, preferably wrapped with
N_()
* cls: the model describing the field
the following keys can also usefully be defined:
@@ -344,7 +345,9 @@
for rank, field in selects:
cls = field['cls']
name = field['name']
- options = [val.name for val in cls.select(self.env, db=db)]
+ pk_field = field.get('pk', 'name')
+ options = [getattr(val, pk_field)
+ for val in cls.select(self.env, db=db)]
if not options:
# Fields without possible values are treated as if
they didn't
# exist
I believe that the above is an area that we are already patching to
allow another way of playing with ticket fields. Anyway, with the above
we can subsequently add the appropriate extra part of the specification
and we start using a different key:
Index: bloodhound_multiproduct/multiproduct/api.py
===================================================================
--- bloodhound_multiproduct/multiproduct/api.py (revision 1404839)
+++ bloodhound_multiproduct/multiproduct/api.py (working copy)
@@ -122,7 +122,7 @@
def get_select_fields(self):
"""Product select fields"""
return [(35, {'name': 'product', 'label': N_('Product'),
- 'cls': Product, 'optional': True})]
+ 'cls': Product, 'pk': 'prefix','optional':
True})]
def get_radio_fields(self):
"""Product radio fields"""
and any update of tickets reduces to a problem of informing that the
event has happened which, until we consider this general problem in
greater depth can simply be the following change:
Index: bloodhound_multiproduct/multiproduct/model.py
===================================================================
--- bloodhound_multiproduct/multiproduct/model.py (revision 1404839)
+++ bloodhound_multiproduct/multiproduct/model.py (working copy)
@@ -273,9 +273,8 @@
now = datetime.now(utc)
comment = 'Product %s renamed to %s' % (old_name, new_name)
if old_name != new_name:
- for t in Product.get_tickets(self._env, old_name):
+ for t in Product.get_tickets(self._env,
self._data['prefix']):
ticket = Ticket(self._env, t['id'], db)
- ticket['product'] = new_name
ticket.save_changes(author, comment, now)
@classmethod
I have ignored the issue of how information is displayed so this is not
really enough for to adapting other resources to use immutable keys. Any
thoughts on these changes?
Cheers,
Gary
On 30/10/12 05:52, Peter Koz(elj wrote:
Ok, I think we agree on most points. I do no see going away from Trac
in short term compelling either. It is just something to think about.
For products we have a couple of enhancements in mind; I would defer
the discussion until then (next week hopefully). Peter
