update/correct baseField shortcode on PUT?

[jmergy]

I'm sure I was the one that did this but is there a way through a baseField put to update the shortcode? We have one that has a bad shortcode and I just want to update it.

Example:

if the put could update it, that would be great.

[jmergy]

I've updated this to kind of take it out of the pool for now

{
  "label": "TBD",
  "category": "technical",
  "dataType": "string",
  "createdAt": "2025-07-31T14:37:45.611983+00:00",
  "shortCode": "oo",
  "description": "TBD",
  "localizations": {},
  "valueRelevanceHours": 4380,
  "sensitivityClassification": "forbidden"
}

[bickelj]

I could be mistaken but I don't think we have a rename capability yet.

[bickelj]

For those that can see it, here is a conversation about the capability.

For those that cannot, here is a summary from Devstral:

╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮                       
│  Based on the conversation, here are the key considerations, opinions, and potential issues regarding the mutability of the shortCode field:                        │                       
│                                                                                                                                                                     │                       
│   1. Current State & Technical Limitations:                                                                                                                         │                       
│      ● The shortCode is now used as a primary key for base fields.                                                                                                  │                       
│      ● Currently, updating the shortCode is not supported, which seems to be a technical limitation rather than an absolute rule.                                   │                       
│      ● Jesse Bickel suggested using PATCH with the old short code in the URL and new short code in the body, but noted this would require complex handling like     │                       
│        PostgreSQL cascading updates and 301 redirects.                                                                                                              │                       
│   2. Design Considerations & Intent:                                                                                                                                │                       
│      ● Justin Reese raised the question of whether editing short codes is intended to be supported eventually.                                                      │                       
│      ● Jesse Bickel agreed that if the API doesn't support editing now, neither should the UI suggest it does.                                                      │                       
│      ● Dan Schultz emphasized the REST API design challenges, but agreed mutability could be possible.                                                              │                       
│   3. Arguments for and Against Mutability:                                                                                                                          │                       
│      ● Against: Existing clients rely on specific short codes; changing a base field's meaning should result in deletion/creation rather than editing the short     │                       
│        code.                                                                                                                                                        │                       
│      ● For: Administrative consistency audits and typo corrections are valid use cases, aligning with the view that base fields are data, not schema.               │                       
│   4. UI Implications:                                                                                                                                               │                       
│      ● Regardless of mutability status, Justin Reese believes shortCode should remain in the "Caution Zone" during creation due to potential consequences.          │                       
│      ● If shortCode is immutable, it would be noted as such and kept disabled in edit mode UI.                                                                      │                       
│   5. Conclusion:                                                                                                                                                    │                       
│      ● The discussion remains open whether short codes will eventually support safe editing with proper mechanisms for handling changes (like cascading updates     │                       
│        and URL redirects).                                                                                                                                          │                       
│                                                                                                                                                                     │                   ▇▇  
│  This summary captures the main points of the conversation for a GitHub issue focused on the service/API aspect of shortCode mutability.                            │                       
│                                                                                                                                                                     │                       
│                                                                                                                                                                     │                       
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯                       

[slifty]

Yeah @bickelj sums it up -- when we moved short code to be a natural primary key instead of simply a metadata attribute part of the thinking there was that short codes should not generally be something that changes because changing the code has larger implications for any third party service that may have cached data that was relying on that natural key (e.g. storing cached application forms that have references to base fields, etc).

That said, we can implement support for it; we may want / need to think about redirects from the old short code(s) to the new URI from the new short code.

[jmergy]

@slifty @bickelj thanks for the backup here. I don't think there will be much need on this yet. So far, the issue is really more to inactivate or remove the field with an error - if we could do that, perhaps that could be okay. I understand the implications.

Also, could baseFields eventually have alternate shortcodes - I could see a use for that. But, in this case, I just want to get the baddie out of the pool here through repurpose or remove and it doesn't have any legacy data against it because it's not on any applicationForms or referenced in proposalVersions, etc.

[bickelj]

@jmergy FWIW I think it's worth doing, of course, balanced against other priorities.

Your use case makes me think perhaps there are cases where it needs no redirect, though there is some danger in that.

For example, at the moment of the rename, the service could look to see if the base field is used anywhere, how fresh it is, and/or some other criteria to determine whether it's safe to simply rename without adding a redirect.

The simpler and safer solution is to always do the same thing: add a redirect from the old to the new, update with cascade (sometimes this will update 0 other rows, sometimes N). In case it isn't clear: I think that redirects from old to new must be implemented with this capability to avoid breakage.

I like your stop-gap solution of marking it forbidden, nice!

[slifty]

Another thing to consider if / when this is implemented: if we redirect, that redirect will break if someone creates a new basefield with the old shortcode. This seems OK / expected to me and I believe it is how other services with editable natural keys handle it (e.g. in github it will redirect if you change repository location, but if you create a new repository in the old location that stops)

[jmergy]

@slifty I kind of don't want to go down the redirect path right now. I think the immediate use case is: new baseField and error made, so let's fix it or delete it to create a correct one.

If the baseField is created, has data against it, than later we want to do something like redirect or whatever, we can cross that bridge. Right now, I think just the error, fix stuff is top-of-mind. Survivorship paths will be more of a later type of deal I think.

[bickelj]

@slifty I was thinking the old one is forever ineligible for re-posting (400 bad request or something) but that comes with potentially worse problems.

@jmergy I am not keen on logging into the production database and tampering the data directly. Our migration path for the demo instance, however, allows a path forward for migration of prod data to the demo environment and then I'd be fine with doing it more safely in demo.

[jmergy]

@bickelj I think we need to do some cleanup in prod to a certain date but then after that, yeah, we stay away from mods in prod. Not sure if this warrants it. I'll come back with some more opinion here.