feature/extract-idm-scripts: Support exporting and importing idm scri…#73
feature/extract-idm-scripts: Support exporting and importing idm scri…#73skootrivir wants to merge 3 commits intomainfrom
Conversation
…pts from global/idm including mappings(sync) and managed objects schema config.
phalestrivir
force-pushed
the
feature/extract-idm-script-rework
branch
from
a84abfa to
8d63829
Compare
| false, | ||
| options.metadata | ||
| options.metadata, | ||
| false |
There was a problem hiding this comment.
This should be options.extract (it should be supported for individual objects). For example, if I want to export only alpha_user, alpha_user may have an onUpdate script, onCreate script, etc.
There was a problem hiding this comment.
This one is for -a, and I dont think we want to extract script for -a option
| const outcome = await exportMappingToFile( | ||
| options.mappingId, | ||
| options.file, | ||
| options.metadata, |
There was a problem hiding this comment.
We want to support adding options.extract here as well for the single mapping case
src/ops/IdmOps.ts
Outdated
|
|
||
| const parsed = JSON.parse(fileData); | ||
| const allEntities = Object.entries(parsed.idm) | ||
| .filter(([id]) => id !== 'meta') // ✅ "meta" 필터링 |
There was a problem hiding this comment.
Was this generated by ChatGPT? We don't need the comment there. Also, if you are just trying to filter out the Frodo metadata, it will never be in the idm object, it should look like this if metadata is there (so I don't even think you need to filter it):
{ idm: { ... }, meta: { ... } }
| } | ||
|
|
||
| /** | ||
| * Import all IDM configuration objects from working directory |
There was a problem hiding this comment.
I don't think we need this change, it should stay all caps
| } else { | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| Object.entries(obj).forEach(([id, value]: [string, any]) => { | ||
| if (type === 'idm') { |
There was a problem hiding this comment.
Everything inside this if statement is being repeated in IdmOps. We should have a helper function created that does this logic (put the helper function in IDM Ops, and call it something like writeIdmEntityToJson)
| "endpoint/oauthproxy": { | ||
| "_id": "endpoint/oauthproxy", | ||
| "context": "endpoint/oauthproxy", | ||
| "file": "oauthProxy.js", |
There was a problem hiding this comment.
Some of these endpoints are wrong (they shouldn't have a file parameter, just the source parameter)
There was a problem hiding this comment.
We've talked about this, but this is ForgeOps' default endpoints that don't exist.
| "endpoint/mappingDetails": { | ||
| "_id": "endpoint/mappingDetails", | ||
| "context": "endpoint/mappingDetails", | ||
| "file": "mappingDetails.js", |
There was a problem hiding this comment.
Some of these endpoints are wrong (they shouldn't have a file parameter, just the source parameter)
| "enabled": true, | ||
| "from": "", | ||
| "html": { | ||
| "en": "<html><body><p>Welcome to OpenIDM. Your username is '{{object.userName}}'.</p></body></html>" |
There was a problem hiding this comment.
I think we should export the HTML and CSS data into separate files like config-manager does
There was a problem hiding this comment.
I think instead of naming the directory ".managed.scripts", it should just be called "", since if you are extracting with -x then it's obvious that the directory of the corresponding object name has the scripts inside of it. The way it is currently named, it looks like a file and not a directory.
There was a problem hiding this comment.
The name of the file is taskscan_activate.invokeContext.tasks.script.script.js, I think it should be taskscan_activate.idm.js, since there should only ever be one script associated with a schedule
2 participants
…pts from global/idm including mappings(sync) and managed objects schema config.