Skip to content
This repository has been archived by the owner on Mar 17, 2021. It is now read-only.

Population of workspace github preferences using Keycloak & GitHub API #231

Closed
ibuziuk opened this issue Jul 27, 2017 · 15 comments
Closed

Comments

@ibuziuk
Copy link
Member

ibuziuk commented Jul 27, 2017

Need to implement the population of workspace github preferences using Keycloak & GitHub API.
Currently, che-starter uses wsmaster API for setting preferences, so first need to have mechanism in place for setting preferences per user or per workspace

@l0rd l0rd mentioned this issue Jul 27, 2017
28 tasks
@gorkem
Copy link
Contributor

gorkem commented Jul 27, 2017

@benoitf can you confirm that wsmaster API is in fact multi-tenant ready?

@benoitf
Copy link
Contributor

benoitf commented Jul 27, 2017

yes preferences API is multi tenant ready but there is no implementation of users/filters that manage different users in Che
Codenvy is using the same wsmaster API preferences implementation but has filters that assign current user

For example the token validator implementation in che is always providing "che"
https://github.com/eclipse/che/blob/8e5967613daddac84d9e3ea0ef47d53d08dbd11e/wsmaster/wsmaster-local/src/main/java/org/eclipse/che/api/local/DummyTokenValidator.java

while in codenvy there is
https://github.com/codenvy/codenvy/blob/ca5ba8d98e66351bf8b89df28e7d73ac7c06bbaa/wsmaster/codenvy-hosted-sso-server-organization/src/main/java/com/codenvy/auth/sso/server/BearerTokenValidator.java

@ibuziuk
Copy link
Member Author

ibuziuk commented Aug 7, 2017

yes preferences API is multi tenant ready but there is no implementation of users/filters that manage different users in Che

@benoitf @gorkem my understanding is that I can move the logic of population preferences from che-starter to rh-che right now by using the same /wsmaster/api/preferences endpoint and it will become multitenant automatically once keycloak support [1] will be in place with token validator in place. Does this sound right ?

[1] eclipse-che/che#5362

@skabashnyuk
Copy link
Collaborator

@ibuziuk what kind of "workspace github preferences" you would like to see?

@ibuziuk
Copy link
Member Author

ibuziuk commented Aug 7, 2017

@skabashnyuk committer name & email smth. that is set via POST /wsmaster/api/preferences

@skabashnyuk
Copy link
Collaborator

What is the user story? At what stage you want to set it? What is the flow?

@ibuziuk
Copy link
Member Author

ibuziuk commented Aug 7, 2017

@skabashnyuk preferences are already set on osio via che-starter. This task is about moving this functionality from che-starter to rh-che plugin. Preferences are set just after workspace creation the user story would be "As a osio user I want to create workspace and have git preferences configured automatically"
image

@skabashnyuk
Copy link
Collaborator

So in Multi-user, Multi-tenant Che it has to be done once, before first workspace usage? Am I correct?

@ibuziuk
Copy link
Member Author

ibuziuk commented Aug 7, 2017

@skabashnyuk yes, since committer preferences are per user and not per workspace

@ibuziuk
Copy link
Member Author

ibuziuk commented Aug 7, 2017

BTW, since multi-tenant Che will never be idled setting committer info could be even done on first login to osio

@l0rd l0rd mentioned this issue Aug 7, 2017
21 tasks
@gorkem
Copy link
Contributor

gorkem commented Aug 8, 2017

I think it is a good idea to refresh the setting per workspace create/launch in case it is updated. Users will have no idea that they need to change Che's preferences on OSIO.

@skabashnyuk
Copy link
Collaborator

Where do you want to store them? Why is Eclipse Che preferences not the main storage?

@l0rd
Copy link
Contributor

l0rd commented Aug 28, 2017

That will be needed when che-started will be deprecated. Deferring implementation.

@l0rd
Copy link
Contributor

l0rd commented Oct 10, 2017

We need to verify that eclipse-che/che#5943 will fix that

@ibuziuk
Copy link
Member Author

ibuziuk commented Jun 2, 2019

was implemented for Che 6. Closing

@ibuziuk ibuziuk closed this as completed Jun 2, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants