You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@allura.apache.org by Björn Kautler <Bj...@kautler.net> on 2015/06/10 00:48:04 UTC

[allura:tickets] #7895 You can add multiple custom fields that get the same internal ID



---

** [tickets:#7895] You can add multiple custom fields that get the same internal ID**

**Status:** open
**Milestone:** unreleased
**Created:** Tue Jun 09, 2015 10:48 PM UTC by Björn Kautler
**Last Updated:** Tue Jun 09, 2015 10:48 PM UTC
**Owner:** nobody

You can add multiple custom fields that get the same internal ID.

e. g. two with label "foo", or one with label "bar" and one with label "bar:" which both get the same internal ID "_bar".
This leads to major problems.

e. g. if you then edit a ticket and set "x" for bar and "y" for bar:, both save the value "[u'x', u'y']". If you then click on edit again, both fields show that value, then you save again without change and both fields get the value "[u"[u'x', u'y']", u"[u'x', u'y']"]".

Via API there is only one custom field shown with id _bar and that value.

You might say that it is unlikely that someone names two fields identical and I might be tempted to agree, but as the ID does not change and is not editable, this could well happen.

Imagine someone creates a custom field foo (gets internal ID _foo), then later decides to rename it to bar (internal ID stays same) and again later creates another field foo and bam, you're f***ed.

It should be prevented under all circumstances that two custom fields get the same internal ID. Maybe the internal ID should even be editable, so that the project admin can decide how the field is called, especially via the API. In jEdit e. g. we have a field Group that is called _milestone in the API, because the one who renamed it probably thought "oh, fine, there is a milestone field we don't need, let's rename it and edit the values to the new semantics". But now the semantic of the name via API is non-sense.


---

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.