Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MMT-3409: publishDraft mutation for Collection/Service/Tool drafts, deleteTool mutation #73

Merged
merged 3 commits into from
Oct 25, 2023

Conversation

macrouch
Copy link
Contributor

Overview

What is the feature?

Adds publishDraft mutation to publish Collection/Service/Tool drafts.
Adds deleteTool mutation to delete Tools

What areas of the application does this impact?

Publishing drafts, deleting tools

Testing

Publishing a draft (needs a valid draft in CMR to publish)

    mutation PublishDraft(
      $draftConceptId: String!
      $nativeId: String!
      $ummVersion: String!
    ) {
      publishDraft(
        draftConceptId: $draftConceptId
        nativeId: $nativeId
        ummVersion: $ummVersion
      ) {
        conceptId
        revisionId
        warnings
        existingErrors
      }
    }

variables:

    {
      "draftConceptId": "TD1000000001-EXAMPLE",
      "nativeId": "tool-1",
      "ummVersion": "1.2.0"
    }

Deleting a Tool

    mutation DeleteTool(
      $providerId: String!
      $nativeId: String!
    ) {
      deleteTool(
        providerId: $providerId
        nativeId: $nativeId
      ) {
        conceptId
        revisionId
      }
    }

variables:

    {
      "providerId": "EXAMPLE",
      "nativeId": "tool-1"
    }

Checklist

  • I have added automated tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings


expect(draft.ingestPath).toEqual('providers/EDSC/bad-drafts')
expect(draft.publishPath).toEqual('publish/CD100000-EDSC')
expect(draft.metadataSpecification).toEqual({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this should throw an error instead of return bad data... Is the idea here that we send this to CMR and let them report the issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its really unreachable code. The conceptType in that switch statement is based off a graphql enum type, but I didn't want to write a ton of if statements so I wrote a switch. eslint expects a default case so this test handles the default. I can change it to throw an error, but it is still something we wouldn't see

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing all the tests I broke when I changed it to throw an error. When we call publishDraft it still uses this class, but conceptType is unimportant, so I just passed in Draft, which hits the default case in the switch. But the metadataSpecification isn't used when publishing a draft


import { pickIgnoringCase } from '../../utils/pickIgnoringCase'
import Concept from './concept'
import { mergeParams } from '../../utils/mergeParams'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean up import order :)

const {
providerId,
ummVersion
draftConceptId = '',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels like a required field, what is the purpose of defaulting it to an empty string versus throwing an error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the empty string came from an earlier attempt to work this where I was performing some action on the string, not needed anymore

let ummType
let ummName
let ummVersion
switch (conceptType) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't the sub classes just set/return these values instead of having a switch statement in the parent?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are no sub classes

publish(data, requestedKeys, providedHeaders) {
const { ummVersion } = data

// eslint-disable-next-line no-param-reassign
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this 6 times in the repo -- wouldn't it be better to create a new const and remove the eslint-disable?


process.env = { ...OLD_ENV }

process.env.cmrRootUrl = 'http://example.com'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been trying to be more specific in the URLs in tests to indicate what service its calling, example-cmr in this case -- it makes the testing a bit more specific and easier to read.


type ToolMutationResponse {
"The unique concept id assigned to the tool."
conceptId: String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is required in other types, should it be required here?

"The unique concept id assigned to the tool."
conceptId: String
"The revision of the tool."
revisionId: String
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is required in other types, should it be required here?

Base automatically changed from MMT-3408 to main October 23, 2023 22:35
@macrouch macrouch force-pushed the MMT-3409 branch 2 times, most recently from 1ab3ea5 to c233749 Compare October 24, 2023 12:48
@codecov
Copy link

codecov bot commented Oct 24, 2023

Codecov Report

Merging #73 (b435637) into main (03a1819) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #73   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           69        69           
  Lines         1446      1503   +57     
  Branches       202       208    +6     
=========================================
+ Hits          1446      1503   +57     
Files Coverage Δ
src/cmr/concepts/collectionDraftProposal.js 100.00% <100.00%> (ø)
src/cmr/concepts/concept.js 100.00% <100.00%> (ø)
src/cmr/concepts/draft.js 100.00% <100.00%> (ø)
src/cmr/concepts/draftConcept.js 100.00% <100.00%> (ø)
src/cmr/concepts/tool.js 100.00% <100.00%> (ø)
src/datasources/draft.js 100.00% <100.00%> (ø)
src/datasources/tool.js 100.00% <100.00%> (ø)
src/resolvers/collection.js 100.00% <100.00%> (ø)
src/resolvers/draft.js 100.00% <100.00%> (ø)
src/resolvers/tool.js 100.00% <100.00%> (ø)
... and 2 more

@macrouch macrouch merged commit 8cbba28 into main Oct 25, 2023
6 checks passed
@macrouch macrouch deleted the MMT-3409 branch October 25, 2023 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants