• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Minor Minor
    • core

      What incorrect behavior happened?

      If you disable global security and later try to enable it again or change the conf the security conf is not properly shown

      EDIT: To further clarify this issue does not report anything broken but some (IMHO) usability issues with the current UI

      • First, to be able to change or see the JNLP port I need to check the Enable security make the change, click save with the check enabled... to end in a UI that is not showing me my recent changes applied, i believe there is no point in hiding the JNLP port settings when security is not active
      • Second, if I have a state based control like a checkbox that says Enable security I expect checking it to have some impact on security settings. Unchecking it disables security, then why checking it does not enable anything? As you say there is a proper technical explanation, but from the end user perspective that control is misleading. When you have a checkbox that says Enable something you expect it to actually enable something, but in this case that is not true. What I am trying to say is that if this check is not enough to enable security the label should not be Enable Security . IMHO what this check really does when checked is to show the Security settings UI, so the label should reflect that. If you guys do not agree with this what about at least showing some kind of message when saving without selecting a security realm informing the user that security can not be enabled with the selected configuration??

      Environment

      • O.S.: Ubuntu 14.04.5 LTS
      • Jenkins Version: 2.32
      • Web browser: N/A
      • JDK version: JDK8

      What was the expected outcome?

      To be able to modify and configure security settings, with new data being shown

      What is the TestRail case or automated test filename where this bug was found?

      N/A

      Step by step to reproduce it

      1. Start 2.32 war in a clean home folder
      2. Disable Global security and save
      3. Try to enable it again. Set for example a fixed JNLP port on 50000, save without changing the security realm.
      4. Open security configuration again, it seems that security is not enabled (due to not using a security realm I believe) and the JNLP port is hidden

      Extra comments

      This is probably more a usability issue than a proper bug, so I created this issue only to inform and (if the team decides so) start a discussion

          [JENKINS-40228] Security config hides certain parts with 2.32

          Raul Arabaolaza created issue -

          Daniel Beck added a comment -

          Security cannot be enabled without selecting a security realm and authorization strategy. Check 'Jenkins user database' and 'anyone can do anything' and it should just work.

          Also, I recommend you actually set up security properly.

          Daniel Beck added a comment - Security cannot be enabled without selecting a security realm and authorization strategy. Check 'Jenkins user database' and 'anyone can do anything' and it should just work. Also, I recommend you actually set up security properly.

          danielbeck

          First of all thanks for your time.

          I am afraid I have explained myself poorly, the main point of this ticket is not reporting something that is not properly working but about two possible usability issues with the UI

          • First, to be able to change or see the JNLP port I need to check the Enable security make the change, click save with the check enabled... to end in a UI that is not showing me my recent changes applied, i believe there is no point in hiding the JNLP port settings when security is not active
          • Second, if I have a state based control like a checkbox that says Enable security I expect checking it to have some impact on security settings. Unchecking it disables security, then why checking it does not enable anything? As you say there is a proper technical explanation, but from the end user perspective that control is misleading. When you have a checkbox that says Enable something you expect it to actually enable something, but in this case that is not true. What I am trying to say is that if this check is not enough to enable security the label should not be Enable Security . IMHO what this check really does when checked is to show the Security settings UI, so the label should reflect that. If you guys do not agree with this what about at least showing some kind of message when saving without selecting a security realm informing the user that security can not be enabled with the selected configuration??

          Raul Arabaolaza added a comment - danielbeck First of all thanks for your time. I am afraid I have explained myself poorly, the main point of this ticket is not reporting something that is not properly working but about two possible usability issues with the UI First, to be able to change or see the JNLP port I need to check the Enable security make the change, click save with the check enabled... to end in a UI that is not showing me my recent changes applied, i believe there is no point in hiding the JNLP port settings when security is not active Second, if I have a state based control like a checkbox that says Enable security I expect checking it to have some impact on security settings. Unchecking it disables security, then why checking it does not enable anything? As you say there is a proper technical explanation, but from the end user perspective that control is misleading . When you have a checkbox that says Enable something you expect it to actually enable something, but in this case that is not true. What I am trying to say is that if this check is not enough to enable security the label should not be Enable Security . IMHO what this check really does when checked is to show the Security settings UI, so the label should reflect that. If you guys do not agree with this what about at least showing some kind of message when saving without selecting a security realm informing the user that security can not be enabled with the selected configuration??
          Raul Arabaolaza made changes -
          Description Original: h3. What incorrect behavior happened?

          If you disable global security and later try to enable it again or change the conf the security conf is not properly shown

          h3. Environment

          * O.S.: _Ubuntu 14.04.5 LTS_
          * Jenkins Version: _2.32_
          * Web browser: _N/A_
          * JDK version: _JDK8_

          h3. What was the expected outcome?

          To be able to modify and configure security settings, with new data being shown

          h3. What is the TestRail case or automated test filename where this bug was found?

          N/A

          h3. Step by step to reproduce it

          # Start 2.32 war in a clean home folder
          # Disable Global security and save
          # Try to enable it again. Set for example a fixed JNLP port on 50000, save without changing the security realm.
          # Open security configuration again, it seems that security is not enabled (due to not using a security realm I believe) and the JNLP port is hidden


          h3. Extra comments

          *This is probably more a usability issue than a proper bug, so I created this issue only to inform and (if the team decides so) start a discussion*
          New: h3. What incorrect behavior happened?

          If you disable global security and later try to enable it again or change the conf the security conf is not properly shown

          *EDIT: To further clarify this issue does not report anything broken but some (IMHO) usability issues with the current UI*

          * First, to be able to change or see the JNLP port I need to check the _Enable security_ make the change, click save with the check enabled... to end in a UI that is not showing me my recent changes applied, *i believe there is no point in hiding the JNLP port settings when security is not active*
          * Second, if I have a state based control like a checkbox that says _Enable security_ I expect checking it to have some impact on security settings. Unchecking it disables security, then why checking it does not enable anything? As you say there is a proper technical explanation, *but from the end user perspective that control is misleading*. When you have a checkbox that says _Enable something_ you expect it to actually enable something, but in this case that is not true. What I am trying to say is that if this check is not enough to enable security the label should not be _Enable Security_ . IMHO what this check really does when checked is to show the Security settings UI, so the label should reflect that. If you guys do not agree with this what about at least showing some kind of message when saving without selecting a security realm informing the user that security can not be enabled with the selected configuration??


          h3. Environment

          * O.S.: _Ubuntu 14.04.5 LTS_
          * Jenkins Version: _2.32_
          * Web browser: _N/A_
          * JDK version: _JDK8_

          h3. What was the expected outcome?

          To be able to modify and configure security settings, with new data being shown

          h3. What is the TestRail case or automated test filename where this bug was found?

          N/A

          h3. Step by step to reproduce it

          # Start 2.32 war in a clean home folder
          # Disable Global security and save
          # Try to enable it again. Set for example a fixed JNLP port on 50000, save without changing the security realm.
          # Open security configuration again, it seems that security is not enabled (due to not using a security realm I believe) and the JNLP port is hidden


          h3. Extra comments

          *This is probably more a usability issue than a proper bug, so I created this issue only to inform and (if the team decides so) start a discussion*
          Daniel Beck made changes -
          Labels New: usability

          Jesse Glick added a comment -

          I believe the fix for JENKINS-4478 addresses this?

          Jesse Glick added a comment - I believe the fix for JENKINS-4478 addresses this?
          Jesse Glick made changes -
          Link New: This issue duplicates JENKINS-4478 [ JENKINS-4478 ]

          jglick Yep, the fix for JENKINS-4478 solves this, closing as duplicate

          Raul Arabaolaza added a comment - jglick Yep, the fix for JENKINS-4478 solves this, closing as duplicate
          Raul Arabaolaza made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]
          CloudBees Inc. made changes -
          Remote Link New: This issue links to "CloudBees Internal OSS-1693 (Web Link)" [ 18609 ]

            Unassigned Unassigned
            rarabaolaza Raul Arabaolaza
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: