Closed sino92 closed 3 years ago
@sino92 - what is this, a doc issue, or?
Actual implementation/enhancement. We can also discourage the use of global cd user in docs of major ODS releases.
I'd start with making the project specific user the default option in the UI in ODS 4.
@netzartist maybe you can give us a hand removing it from the new UI for ODS 4? I can do the backend refactoring.
@sino92 I think for now this would be UI only? Also keep in mind for some users "the UI" is a different frontend to the API than the one @netzartist created.
The change can be UI only, but wouldn't we eventually have to remove some conditionals to have a cleaner backend? Isn't ODS 4 will be fully new front end? Which users will have a different UI and why?
@sino92 The change in both javascript parts (old and new single page app) is just about making the project specific user input mandatory. I can do this.
I relate to User Interface as what you see in the browser. ODS 3 has the single page app UI as an optional feature so you can experiment and switch between them. ODS 4 will have the new single page app UI by default then.
@netzartist @sino92 please analyse from user experience point of view the case of projects created before ODS 4 that are not using a project specific cd_user. A warning could be displayed or anything similar to make users aware that the project need maintenance, in this case a project specific cd_user. Does this make sense?
Regarding https://github.com/opendevstack/ods-provisioning-app/issues/577#issuecomment-673514257:
Which users will have a different UI and why?
Users of the API (through integrations like ServiceNow etc.)
My suggestion is to keep the initial scope really small: Make the project specific user the default choice in the new UI, and no change to validation / backend / API ...
@michaelsauter Ah right, it makes sense considering the API is actively used. @stitakis There wouldn't be any usability issues unless the global cd user credentials are altered. From a security perspective though, yes a warning sign would be quite nice. @netzartist and I can take care of this
@sino92 Do you have an idea for a better explanation text in the corresponding tooltip of the CD user input? I guess the current text should be adapted when the field will be mandatory.
If you use a project specific CD user, the user has to exist in your identity management and has to be able to access Bitbucket. After project creation you will have to change the CD user password in the OpenShift webconsole of the created CD project.
Also: Validation: Which regex applies best for cdUser? For project name we use ([a-zA-Z][a-zA-Z_0-9]+)
limited to 2-80 chars via the maxlength-attribute in the <input>
. Same rule here?
@sino92 @netzartist and I discussed this. The new UI shows the "project specific cd user" field by default, so that is already the intended behaviour. The old UI should be phased out, so does not need to change. The backend API still accepts both inputs (no project specific user given, or a project specific user given). The API should not change at this point - in fact that would be a bigger change as cleanup in more places further down would be needed. We can pick that up when there is need for it.
Global cd user has two big downsides:
A reminder that with specific cd user, the user will have to modify Openshift project secret for cd user manually. A small effort for a bigger win.