filter out data source object when export #6124
Conversation
Signed-off-by: yujin-emma <yujin.emma.work@gmail.com>
yujin-emma
requested review from
ananzh,
kavilla,
AMoo-Miki,
ashwin-pc,
joshuarrrr,
abbyhu2000,
zengyan-amazon,
kristenTian,
zhongnansu,
manasvinibs,
ZilongX,
Flyingliuhub,
BSFishy,
curq,
bandinib-amzn,
SuZhou-Joe,
ruanyl and
BionIT
as code owners
Signed-off-by: yujin-emma <yujin.emma.work@gmail.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6124 +/- ##
==========================================
- Coverage 67.15% 67.15% -0.01%
==========================================
Files 3326 3326
Lines 64400 64401 +1
Branches 10361 10361
==========================================
- Hits 43251 43250 -1
- Misses 18619 18620 +1
- Partials 2530 2531 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
| @@ -180,6 +180,7 @@ export async function exportSavedObjectsToStream({ | |||
| exportedObjects = sortObjects(rootObjects); | |||
| } | |||
|
|
|||
| exportedObjects = exportedObjects.filter((obj) => obj.type !== 'data-source'); | |||
There was a problem hiding this comment.
Instead of filtering the final results, shall we filter the types passed in before sending it to savedObjectsClient.find? Or maybe even throw error if export data-source is not allowed, like in fetchObjectsToExport we do validations for the export parameters.
There was a problem hiding this comment.
+1, I assume we are using the saved object find API and we can specify the object types there
There was a problem hiding this comment.
Sure, + 1 on using saved object find API and specifying the types; as for
Or maybe even throw error if export data-source is not allowed
partially agree, error can be some interruption on UX, not quite sure about the user experience, but we can have warning first, more discussion is here
| @@ -180,6 +180,7 @@ export async function exportSavedObjectsToStream({ | |||
| exportedObjects = sortObjects(rootObjects); | |||
| } | |||
|
|
|||
| exportedObjects = exportedObjects.filter((obj) => obj.type !== 'data-source'); | |||
| // redact attributes that should not be exported | |||
There was a problem hiding this comment.
Can we please add tests for this change as well?
|
Can we add context for this PR as well as what manual tests have been done? |
|
Maybe it is not a good time to ask such question but I'm thinking why don't we make data-source as a hidden type? Hidden type won't be export as allowed types in saved objects management and can not be performed CRUD operations on by a normal saved objects client. That meets what data source needs I suppose. |
We still need to list the data source object, but since it contains the auth information, we cannot import/export, more discussion is here |
|
If an index pattern depends on datasource, and we don't export datasource will that break the reference? If yes, the user experience is same, all dashboards/visualization will be broken. we might need remove the reference in index pattern as well when export. |
|
@yujin-emma will remove the 2.14 label as this in draft still. And have added the 2.15 label or if it needs to be closed feel free to do so. |
|
@yujin-emma Is this PR still being worked on, are we plan to fix in 2.15? |
|
Close this pull request since we do not plan to work on filter data source object when export, we are going to stop importing data source objects, and the code change already merged in main : #6395 |
Description
Issues Resolved
Screenshot
Testing the changes
Check List
yarn test:jestyarn test:jest_integration