docs: remove attributes. in SavedObjectsFindOptions.fields example

[joshuali925]

Description

Corrects the example in the comment for SavedObjectsFindOptions. The comment is misleading because it includes attributes, which will be a field in the response

{
  "id": "my-pattern",
  "type": "index-pattern",
  "version": 1,
  "attributes": {
    "title": "my-pattern-*"
  }
}

But the raw document does not include attributes field, saved object client will put fields under saved object type in the raw document as the attributes field.

OpenSearch-Dashboards/src/core/server/saved_objects/serialization/serializer.ts

Line 89 in 471877f

attributes: _source[type],

Raw document sample:

      {
        "_index": ".kibana_92668751_admin_5",
        "_id": "custom-type:185348a0-3239-11ee-b9f0-0fc7f32be0b4",
        "_seq_no": 106,
        "_primary_term": 2,
        "_score": null,
        "_source": {
          "custom-type": {
            "title": "custom title",
            "version": 1,
            "createdTimeMs": 1691093129770,
          },
          "type": "custom-type",
          "references": [],
          "updated_at": "2023-08-03T20:05:29.770Z"
        }
      },

So including attributes.<field> (e.g. attributes.title) in find options will not give correct results. Using <field> (e.g. title) is enough because the type will be prepended.

OpenSearch-Dashboards/src/core/server/saved_objects/service/lib/included_fields.ts

Line 48 in 471877f

return [...acc, ...sourceFields.map((f) => `${t}.${f}`)];

Issues Resolved

Screenshot

Testing the changes

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 66.50%. Comparing base (46d7c2d) to head (86d131b).
Report is 307 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4695   +/-   ##
=======================================
  Coverage   66.50%   66.50%           
=======================================
  Files        3403     3403           
  Lines       65026    65026           
  Branches    10401    10401           
=======================================
+ Hits        43243    43245    +2     
+ Misses      19214    19213    -1     
+ Partials     2569     2568    -1     

Flag	Coverage Δ
Linux_1	34.82% <ø> (ø)
Linux_2	55.31% <ø> (ø)
Linux_3	44.61% <ø> (+<0.01%)	⬆️
Linux_4	34.89% <ø> (ø)
Windows_1	34.83% <ø> (ø)
Windows_2	55.27% <ø> (ø)
Windows_3	44.61% <ø> (ø)
Windows_4	34.89% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[joshuali925]

+ Coverage 66.10% 66.14% +0.03%

why does coverage change when the commit only changes a comment?

[joshuarrrr]

+ Coverage 66.10% 66.14% +0.03%

why does coverage change when the commit only changes a comment?

CodeCov has some margin of error - we often see diffs for changes that have no test changes at all. Don't worry about it.

[joshuarrrr]

LGTM

[kavilla]

@joshuali925 do you think there is a potential for some recent change to have modified this behavior or is it a potential weird behavior in the current client?

Was playing around with the import saved objects API and attempting to hit that endpoint with a POST without attributes actually got rejected explicitly telling me i need to include attributes.

If I was to implement an OpenSearch Dashboards client I would probably ensure that the usage is consistent so users don't have to modify data to include specific keys that we already map in another endpoint.

To be honest your point makes more sense but it makes me question if something off is happening somewhere.

[joshuali925]

@kavilla I'm not sure why the rest API and saved object js client are inconsistent, I've not used the rest API much. But I don't think it's a recent change on the client, the related code I posted has not changed for more than 4 years

side question, where is the documentation for saved object rest API? I couldn't find them in https://opensearch.org/docs/latest/dashboards/index/

[joshuarrrr]

side question, where is the documentation for saved object rest API? I couldn't find them in https://opensearch.org/docs/latest/dashboards/index/

opensearch-project/documentation-website#3799 😢

[kavilla]

side question, where is the documentation for saved object rest API? I couldn't find them in https://opensearch.org/docs/latest/dashboards/index/

Yeah as @joshuarrrr commented it is to be added. I can try to scrap something together today.

[joshuarrrr]

@kavilla Assigning to you to either finish the final review or provide updated docs and close.

[kavilla]

@joshuali925, could this be the result of the type of dashboard is a container of other saved objects and so it is has different fields whereas the index pattern is a little bit more simplified?

If so then perhaps we can update this PR so that it references both examples

[joshuali925]

@kavilla to be honest i don't remember the details or i didn't test on all types of saved objects, but based on the code i don't see the serialization logic changing for different object types.

[kavilla]

im currently looking into this area so I'm going to move it to 2.15 and add it to the the saved objects OE.