Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-36315

Confusion on how to get form validation URLs in config.jelly

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • credentials-plugin
    • None

      Currently there are at least three types of it that a Credentials implementation can have its config.jelly invoked with:

      • CredentialsStoreAction.DomainWrapper when creating a new credential from the credential domain's screen
      • CredentialsStoreAction.CredentialsWrapper when updating an existing credential
      • CredentialsSelectHelper.WrappedCredentialsStore when performing an in-place Add from a job page.

      The last one is particularly problematic as there is no guaranteed way to get the backing context object from that.

      We should standardize on a single object type... it would seem that the CredentialsStore would be the ideal candidate.... leaving instance to be the existing Credential in the event of an update.

          [JENKINS-36315] Confusion on how to get form validation URLs in config.jelly

          Stephen Connolly created issue -
          Stephen Connolly made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Stephen Connolly made changes -
          Remote Link New: This issue links to "PR #62 (Web Link)" [ 14577 ]
          Jesse Glick made changes -
          Description Original: Currently there are at least three types of `it` that a {{Credentials}} implementation can have its {{config.jelly}} invoked with:

          * {{CredentialsStoreAction.DomainWrapper}} when creating a new credential from the credential domain's screen
          * {{CredentialsStoreAction.CredentialsWrapper}} when updating an existing credential
          * {{CredentialsSelectHelper.WrappedCredentialsStore}} when performing an in-place Add from a job page.

          The last one is particularly problematic as there is no guaranteed way to get the backing context object from that.

          We should standardize on a single object type... it would seem that the {{CredentialsStore}} would be the ideal candidate.... leaving {{instance}} to be the existing {{Credential}} in the event of an update.           		New: Currently there are at least three types of {{it}} that a {{Credentials}} implementation can have its {{config.jelly}} invoked with:

          * {{CredentialsStoreAction.DomainWrapper}} when creating a new credential from the credential domain's screen
          * {{CredentialsStoreAction.CredentialsWrapper}} when updating an existing credential
          * {{CredentialsSelectHelper.WrappedCredentialsStore}} when performing an in-place Add from a job page.

          The last one is particularly problematic as there is no guaranteed way to get the backing context object from that.

          We should standardize on a single object type... it would seem that the {{CredentialsStore}} would be the ideal candidate.... leaving {{instance}} to be the existing {{Credential}} in the event of an update.
          Jesse Glick made changes -
          Link New: This issue is related to JENKINS-19413 [ JENKINS-19413 ]
          Stephen Connolly made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 173014 ] New: JNJira + In-Review [ 199380 ]
          Stephen Connolly made changes -
          Status Original: Resolved [ 5 ] New: Closed [ 6 ]

            stephenconnolly Stephen Connolly
            stephenconnolly Stephen Connolly
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: