id widget

[magomimmo]

Is your feature request related to a problem? Please describe.

Whenever you model a collection you need an identifier field for its entries. Most of the time the collection does not have a natural identifier field (i.e. a primary key in RDBMS parlance). For this reason the community developed a range of custom widgets to fill this hole in the NetlifyCMS standard widget library, that does not offer such a basic widget.

Describe the solution you'd like

Create an id widget to generate an universal unique id code (i.e. UUID). This widget should also have a boolean hide option to allow the associated field to be hidden from the UI.

Describe alternatives you've considered

Use a community based custom widget, but none of them currently allows to hide the field from the UI.

Additional context

Anyone intending to migrate a three-tire web application to JAMstack architecture will need to model collections and collection relationship. And you can't do this without having an id widget resembling synthetic primary key in RDBMS parlance.

[erezrokah]

Thanks @magomimmo, will this be covered by implementing #1975 along with using the hidden widget https://www.netlifycms.org/docs/widgets/#hidden?

[magomimmo]

Thanks @magomimmo, will this be covered by implementing #1975 along with using the hidden widget https://www.netlifycms.org/docs/widgets/#hidden?

I'm using @d4rekanguok 's ncw-id and ncw-file-relation widgets. IMHO these two widgets, with few improvements, have to be part of the standard set of NetlifyCMS widgets

[erezrokah]

With the recent addition of being able to use string templates with the relation widget, I think the only missing feature is to target a specific file (correct me if I'm wrong).
Having two relation widgets might be confusing...
Regardless, there is a separate issue for that #800

As for the Id widget, the main use case for it is with the relation widget, which you can now set valueField: '{{slug}}' as a unique identifier (or even {{filename}}).
The main advantage of that approach is that you don't need an extra id field on the referenced collection.

I agree the CMS should supply a built in Id widget functionality and have an option to hide any widget.
Hiding widgets is covered in #1409 (comment).

Clarifying my suggestion - supporting a built in {{uuid}} template variable in default values might make an Id widget redundant, e.g. doing - {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"} should serve the same purpose.

Am I making sense here?

[beeFlaherty]

supporting a built in {{uuid}} template variable in default values might make an Id widget redundant, e.g. doing - {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"} should serve the same purpose.

This would make sense yes.

[magomimmo]

Having two relation widgets might be confusing...

Agree, but we should be able to unify the corresponding configuration options

As for the Id widget, the main use case for it is with the relation widget, which you can now set valueField: '{{slug}}' as a unique identifier (or even {{filename}}).
The main advantage of that approach is that you don't need an extra id field on the referenced collection.

It makes sense

Clarifying my suggestion - supporting a built in {{uuid}} template variable in default values might make an Id widget redundant, e.g. doing - {label: "Id", name: "id", widget: "hidden", default: "{{uuid}}"} should serve the same purpose.

Am I making sense here?

Yes, it makes a lot of sense.

[magomimmo]

Just adding the following note on the this discussion.

As said in a previous post I use ncw-id widget the identifier_field for all the collections not having a natural primary key.

While using the relation widget, this approach has the very bad effect of not allowing to use any field of the referenced collection in the slug or in the summary of the referencing collection.

Here is the minimal case:

  # Referenced folder colleciton
  - label: Referenced Folder collection
    name: referenced
    identifier_field: id
    folder: content/referenced
    create: true
    slug: '{{year}}{{month}}{{day}}{{hour}}{{minute}}{{second}}-{{last}}-{{first}}'
    summary: '{{last}}, {{first}}'
    editor:
      preview: false
    fields:

      - label: ID
        name: id
        widget: ncw-id

      - label: Last Name
        name: last
        widget: string
        
      - label: First Name
        name: first
        widget: string

  - label: Referencing Folder Collection
    name: referencing
    identifier_field: id
    folder: content/referencing
    create: true
    slug: '{{year}}{{month}}{{day}}{{hour}}{{minute}}{{second}}-{{referenced.last}}'
    summary: '{{referenced.last}}, {{referenced.first}}-{{referenced}}'
    editor:
      preview: false
    fields:

      - label: ID
        name: id
        widget: ncw-id
      - label: Referenced Entry
        name: referenced
        widget: relation
        collection: referenced
        searchFields: ['last', 'first']
        displayFields: ['{{last}}, {{first}}']
        valueField: id

As you can see in the attached screenshot, the summary of the referencing collection can only show the id of the referenced one.

HIH

[erezrokah]

Thanks @magomimmo, that's actually a though one. The CMS only stores the valueField in the referencing collection data file so you can't use the referenced collection fields in the referencing collection summary. For that to work the CMS would need to read and parse each referenced entry which it doesn't at the moment (it only does it when you open the editor).

[magomimmo]

Ugh. @erezrokah that's a pity. What about to save the summary of the referenced entry in the valueField? Does it has any drawback?

[erezrokah]

As long as you are sure the summary values won't change you can use:
valueField: '{{last}}, {{first}}' and then in the summary just use summary: {{referenced}}.

I actually think a better approach is to allow users to customise the cards #2868 (comment).
Then you could fetch any information you'd like.

[magomimmo]

Thanks @erezrokah

[vnourdin]

Hello @erezrokah 👋

If I read well your last message, it seems possible to use a template in the value_field of a relation widget, but I can't achieve to make it work.

My need is the same that this issue: I have a file collection with fields a and b (in a list) and I want to reference them from a relation widget, but it says "No options" if I use a template string.

value_field: 'a is {{mylist.*.a}} - and b {{mylist.*.b}}'
search_fields: ['mylist.*.a', 'mylist.*.b']

With the following, I have my items properly displayed:

value_field: 'mylist.*.a'
search_fields: ['mylist.*.a', 'mylist.*.b']

Did this feature disappear, or do I miss something?
Thanks a lot 🙏

[erezrokah]

Hi @vnourdin, this seems like a bug/something we missed when implementing the wildcard access pattern via *.

I suggest opening a new issue so we can look into it.

A better way to approach it is to create a uniquely identified field in mylist and use that as a reference for simplification.
If you need the reference field to be dependent on a and b maybe create a custom widget for it?

[vnourdin]

I open a new issue then.

I did that with the preSave event as a workaround, but it's probably a better approach indeed.