opendevstack / ods-provisioning-app

Provisioning app, which triggers project and component provisions (including Jira / Confluence / BitBucket and OCP resource creation)
Apache License 2.0
15 stars 20 forks source link

Remove global cd user and make project specific cd user default #577

Closed sino92 closed 3 years ago

sino92 commented 4 years ago

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.

clemensutschig commented 4 years ago

@sino92 - what is this, a doc issue, or?

sino92 commented 4 years ago

Actual implementation/enhancement. We can also discourage the use of global cd user in docs of major ODS releases.

michaelsauter commented 4 years ago

I'd start with making the project specific user the default option in the UI in ODS 4.

sino92 commented 4 years ago

@netzartist maybe you can give us a hand removing it from the new UI for ODS 4? I can do the backend refactoring.

michaelsauter commented 4 years ago

@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.

sino92 commented 4 years ago

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?

netzartist commented 4 years ago

@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.

stitakis commented 4 years ago

@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?

michaelsauter commented 4 years ago

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 ...

sino92 commented 4 years ago

@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

netzartist commented 3 years ago

@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?

michaelsauter commented 3 years ago

@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.