Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Use camel-case names for auto-generated refIds, only use counter value if needed

Description

I'm not sure if this is a bug. Maybe I just don't understand what the refId field for custom fields is used for. Is it supposed to be the name of the JSON property that you use in the customFields property? I.e. If I define the following custom field,

do, I use the following JSON when setting the value when inserting/updating a user?

If so, the - and _ characters could be problematic. I think underscore would be fine, but, dash is problematic because the developer who is generating the JSON, may be using a language where - isn't a valid character for an identifier. For example, I'm using C# and I usually define my JSON as an object graph of dynamic objects. Then, I serialize the object to a string.

I'm just guessing that refId is used as the JSON property name. I'm running a version of FOLIO that doesn't yet have full support for custom fields. So, I am guessing.

Nonetheless, it would be helpful if there was an indication as to what the property names should be.

Also, if it is used for JSON property names, it would be nice if the _1 counter variable at the end of the identifier was only used when needed (when there is already a field with the same name).

Environment

None

Potential Workaround

None

defines

Checklist

hide

TestRail: Results

Activity

Show:

Jon Miller November 17, 2020 at 7:28 PM

I'm in the process of testing this on our system. From what I've seen so far, everything looks great. No more counter values and in camel case. Thanks for fixing this. Will report back if I run into any problems, but, from what I've seen so far, it seems to be working.

Ann-Marie Breaux July 13, 2020 at 4:15 PM

Hi - looks like this is in Spitfire's current sprint, so should be worked on soon

Jon Miller June 24, 2020 at 7:28 AM

Regarding the counter values (_1 at the end of the identifiers). I'm wondering if that would ever be necessary. Shouldn't there be a check that disallows two different fields with the same display name? I'm not sure why anyone would ever want to do that.

Jon Miller June 24, 2020 at 6:50 AM

I just tested updating a user with a custom field and sure enough it's using refId for the JSON property name. Can you please at least substitute underscores for dashes? As I mentioned above, I think it would be better if you used camel-case names, as in "studentId" instead. I'm pretty sure camel-case identifiers is what JavaScript normally uses. With the way it stands now, I am unable to define the JSON as a dynamic object in C# and serialize it properly because dash isn't a valid character for a C# identifier. It's invalid in Java also and in C. Not sure about other languages.

Done

Details

Assignee

Reporter

Labels

Priority

Story Points

Sprint

Development Team

Spitfire

Fix versions

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created June 24, 2020 at 6:30 AM
Updated November 17, 2020 at 7:28 PM
Resolved July 23, 2020 at 2:13 PM
TestRail: Cases
TestRail: Runs