Setup/Settings Page

[chirino]

Right now we have a bit of a mess with where projects get save in github. It get saved under the last user that published the integration. If 2 different users save the integration, then it will be save in two different git repos. I think all integrations should get saved under the same github organization regardless of the user.

We should have a setup or settings page where users configure:

1. The github organization that integration projects get created under
2. The OpenShift namespace that the project get deployed into

At this point we might want to trigger oauth flows to collect offline tokens which the system then uses when working with github/openshift.

[gashcrumb]

+1 at the very least the current behavior is undesirable. Wonder though, this would generally be more of an administrative thing, is more of a background configuration item or does it need each user to set it up, or should we cater for both?

Also does it make sense to allow for overrides on a per-integration basis? In which case then we might need a settings page for an integration as well possibly?

[gashcrumb]

Also, wonder if we want to also be able to work against non-github repositories how would this work?

[chirino]

Another thing that we might want to configure in this settings page is oauth client secrets for connectors like Twitter and Salesforce.

[gashcrumb]

Seems like that should be a separate thing stored with a connection? Otherwise this settings page will have a potentially a lot of oauth settings as we add connectors, wouldn't it?

[chirino]

This is true. But I think it's the right area to do it. Another point to make is we should NOT show connectors to users if the system level oauth setting are configured for it.

[gashcrumb]

So thinking about this more we mostly need a page that lists oauth2 endpoints that lets you create a new entry for that list, each entry could then be an open-ended map of key/value pairs basically. Then it's a matter of mapping these list entries to a connector during the create connection wizard.

[gashcrumb]

Ideally we'd want to be able to discover what oauth2 endpoints could potentially need configuring, and then an endpoint to load/save/manage these settings.

[gashcrumb]

Also if we know required settings for a given oauth2 endpoint we can then create a form, otherwise fall back on a more generic 'add key/value pairs' interface.

[gashcrumb]

Another point to make is we should NOT show connectors to users if the system level oauth setting are configured for it.

Like the settings? Or the connection? I'm not sure I understand.

[chirino]

So when we create a new connect we get to pick from a list of connectors. We should not show connectors that we don't have configured client id/secrets for since we would not be able to do a proper oauth flow for them.

[gashcrumb]

That'd be doable, we'd need to have a way of identifying if a connector needs oauth or not and then a way to correlate a connector to it's available setting. But yeah, that totally makes sense to me.

Kinda starting to wonder if we should have a separate 'Authorizations' nav item? As really, a user that's starting off with a new install would have to start there, wouldn't they?

[chirino]

I think settings nav item makes more sense to me with perhaps a Authorizations tab. But whatevs.

[gashcrumb]

Yeah, agreed. Though it's like, if you don't have any oauth settings set up, you can't connect anything except http. So we have to guide the user to get that set up first really. Could maybe punt 'em over to the oauth settings page I guess, or maybe in-place add the oauth setting from within the create connection wizard, and then we'd continue to show all connectors. on the first page of the wizard.

[chirino]

Yeah initial setup flow is an interesting UXD exercise on how to collect all that data keeping in mind that the user needs to go out to Twitter and Salesforce to go create those client id/secrets so it might take a while to get it all setup and we might have to guide then on how to use those external systems.

[gashcrumb]

@sjcox-rh @dongniwang thoughts on this one?

[dongniwang]

Sorry that we're late to the conversation! For some reason this thread is not showing up in my filter.

Actually @sjcox-rh and I will have an initial UX conversation with several other UX folks who have done some work in OAuth Flow. After that, let's get together and have a discussion about this. In addition, we have also started on brainstorming the user onboarding process. So very timely to hear everyone's thoughts and ideas.

And just to understand the problem that we're dealing with:

• We'll be surfacing configuration/setting of connection and integration to users.
  • Users need to configure some basic things when they first use the application.
  • Users need to revisit the configuration/settings in the future
• Multiple users could potentially be accessing the same connection, and the same integration.
  • This gets into the user roles issue. A way to configure things at the organization level vs. individual level. We might need to provide different levels of access for admin and citizen users.
  • When creating a new connection or a new integration, do users have the choice to configure if the connection/integration is accessible to creator only vs. everyone in the same org.?

Currently, we already have connection details page, and integration details page is in the process of being updated.

@sjcox-rh, please add your thoughts as well.

[sjcox-rh]

Would it be possible to have the user go through the oauth flow within the create a connection flow? As in, when a user creates a Twitter connection for the first time, they would have to go through the oauth flow then (whether via a popup, external page, etc.) and once it's successfully connected to their Twitter account, they can finish setting up the connection.

Or are we saying all connections that require an oauth flow would be done via a settings page?

[gashcrumb]

I think the idea is that the user would go through the oauth flow on the create connection page, but to do that in most cases you need to have a client ID and app token with the target site to start that flow. So the settings page would be where a system administrator would set up those client IDs/secrets ahead of time so that we don't need to require that stuff in the create connection form.

[sjcox-rh]

Got it, thanks for clarifying @gashcrumb!

[kahboom]

I think that's why it kind of makes sense to have a separate "Accounts" section for this type of thing like Zapier does (it's almost like they don't have a Connections model).

Regards,

Rachel Yordán Senior Software Engineer Red Hat, Inc. | Middleware ryordan@redhat.com

On Wed, May 24, 2017 at 1:34 PM, Sarah Jane Cox notifications@github.com wrote:

Got it, thanks for clarifying @gashcrumb https://github.com/gashcrumb!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/syndesisio/syndesis-ui/issues/546#issuecomment-303796403, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqplsv87BBjLlrC7kAxwqoKUlHI-pEuks5r9Go3gaJpZM4NdwGi .

[rhuss]

Can we please revisit the story here and widen the scope a bit beyond ?

As briefly described in https://github.com/syndesisio/syndesis-project/issues/13 there are several global configuration options which needs to be configured in a separated section in the UI.

This section holds all configuration which are global and independent of concrete connections. The discussion about which configuration should go there initially should go to https://github.com/syndesisio/syndesis-project/issues/13.

wrt the UI I think we should start first to think about from where to branch off this UI section. I suggest adding this to the leftmost column as an extra point. The content of the section obviously dependent on the possible configuration options, but it can already be said that there will be a configuration section per connector (twitter, salesforce, ...) which is used during the creation of a connection. The OAuth dance itself, however, would happen during the creation of the connection. But @chirino said the client id and other global app secrets should go there.

[kahboom]

Do we need designs here @sjcox-rh @dongniwang ? @rhuss I'm assuming this isn't a priority for this sprint since the epic isn't assigned to one.

[rhuss]

@gashcrumb as we now have merged the PR #629 , can we close this issue ? Or is there still UI work to be done here ?

[gashcrumb]

@rhuss no, there's still work to complete this to do

[gashcrumb]

@rhuss so on this one I still have to get the form in the expansion part of the list and wire up the buttons, as well as then wire up the view to the backend. I'll maybe try and remember to include what's remaining on future PRs if that helps.

[rhuss]

That's fine for me. If there is something I can test early, let me know.

[jludvice]

Hi @gashcrumb, would it be possible to use angular components instead of <div><div><div><div><div> element tree ? It is really painful to write readable css selectors, especially if I have to some 3rd level nested element which contains string XY in body.

Wouldn't be components be better also from reusability point of view?

It would be awesome if I can type selector like this:

$('oauth-entry[name="Facebook"]')

[gashcrumb]

@jludvice I can work towards that, for sure.

[gashcrumb]

@jludvice one thing though, am using patternfly-ng + a patternfly list for this view now which does impose some restrictions as to the hierarchy of elements, otherwise the styles don't apply correctly. For example I gave it a go with the main content area in each list item and it breaks the formatting. But we could certainly go through and add specific classes/IDs to whatever elements you need, just let me know which ones...

[jludvice]

Just created issue #663 to discuss css selectors and IDs in for E2E in general.

@gashcrumb the Register button behavior seems suspicious. It's visible when the entry is collapsed - Salesforce entry in screenshot but it's hidden when entry is expanded - Twitter entry in screenshot

Shouldn't it be visible allways?

[gashcrumb]

@jludvice it's like that in the design -> https://github.com/syndesisio/syndesis-ux/blob/master/designs/global-settings-page/global_settings_page_overview.md

And really, once the form is open, the 'Register' button doesn't need to be there, does it?

I did find the 'Remove' button odd in general when implementing, also I kept the form after the user enters in the credentials and saves it rather than writing up another view without the form, but this is in a state where it's ready for use.