Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CDAP-13236] Allows editing of keytabURI of a namespace in UI #10006

Merged
merged 1 commit into from
Apr 6, 2018

Conversation

tonybach
Copy link
Contributor

@tonybach tonybach commented Apr 2, 2018

JIRA: https://issues.cask.co/browse/CDAP-13236

Backend PR: #9701

Allows editing of keytabURI property of a namespace in UI, from its Namespace Details page. Currently only keytabURI is editable since we don't have backend code to allow editing of principal yet.

<div className="namespace-details-section-label">
<strong>{T.translate(`${PREFIX}.label`)}</strong>
{
this.props.principal && this.props.keytabURI ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this check? I can't edit if the namespace initially created without these values?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes currently we can't edit the keytabURI if the namespace was created without keytabURI and principal properties.

@@ -24,7 +24,8 @@ export default function PreferencesStep() {

const mapStateToKeyValProps = (state) => {
return {
keyValues : state.preferences.keyValues
keyValues : state.preferences.keyValues,
disabled: state.editableFields.fields.indexOf('keyValues') === -1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't the field name be preferences?

Copy link
Contributor

@ajainarayanan ajainarayanan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor comments.

@@ -17,6 +17,7 @@
import {combineReducers, createStore, compose} from 'redux';
import AddNamespaceActions from 'services/WizardStores/AddNamespace/AddNamespaceActions';
import AddNamespaceWizardConfig from 'services/WizardConfigs/AddNamespaceWizardConfig';
import {convertMapToKeyValuePairsObj} from 'components/KeyValuePairs/KeyValueStoreActions';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: May be we should extract tis to services/helpers. We seem to be using this in a lot of places outside of KeyValuePairs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This conversion still has a lot of specific behavior for KeyValuePairs component, such as the unique id and also if it's empty, we want to set a default. So I don't think it should sit in helpers.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May be extract the functionality of converting a map to key, value? May be the function can accept another argument to add unique ids to each key value (since when we render key-value anywhere in the DOM we need a unique id)?
we want to set a default this is the part that becomes a little out of place for me. We seem to be using a default state of a component inside the store of another component. May be I am missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have extracted out the functionality of converting a map to a key-value pairs array.

@@ -60,6 +61,21 @@ const defaultPreferencesState = Object.assign({
}
}, skippableDefaultState);

const defaultEditableFieldsState = Object.assign({
fields: [
'name',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be,

Object.keys({
  ...defaultGeneralState,
  ...defaultSecurityState,
  ...defaultPreferencesState
})

I am afraid tomorrow we might add a field to one of the other objects and forget to add here. Removes the necessity to hard code the same property in two places.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also for simplicity can the editable fields be an array? do we need editableFields.fields?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still want it to be an object, since we want to pass the __complete: true property to it. This lets the Wizard component know that the step is complete, so the 'Finish' button can be enabled in the wizard. This is done in the checkRequiredSteps() method in the Wizard component.


static defaultProps = {
isEdit: false,
editableFields: [],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this default from the store?

if (this.props.isEdit) {
return editNamespaceProperties();
} else {
return this.createNamespace();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this use PublishNamespace from the namespace action creator?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Internally this.createNamespace() does use PublishNamespace(). Have renamed this.createNamespace() to this.publishNamespaceAndPreferences() to be more clear.

return publishOrEditNamespace(MyNamespaceApi.create);
};

const editNamespaceProperties = () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Should this be EditNamespaceProperties? to be consistent with PublishNamespace? Or change publishNamespace or createNamespace

Copy link
Contributor

@ajainarayanan ajainarayanan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments. Otherwise 👍 LGTM

return {
key: mapKey,
value: map[mapKey],
uniqueId: 'id-' + uuid()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this not be here? Also we can start to use Object.entries(map).map(([key, value]) => {...}) makes it simpler.

@@ -16,7 +16,15 @@
import AddNamespaceStore from 'services/WizardStores/AddNamespace/AddNamespaceStore';
import {MyNamespaceApi} from 'api/namespace';

const PublishNamespace = () => {
const publishNamespace = () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: May be just saveNamespace? and savePreferences? Don't know if we could say 'publish namespace' here.

@tonybach
Copy link
Contributor Author

tonybach commented Apr 6, 2018

Addressed comments, rebasing and merging.

- Adds Edit label, populates wizard when clicked on, and navigates to Security tab in wizard
- Adds api to edit namespace when user clicks Finish in the wizard
- Only allows editing of keytabURI if the specified some values for principal and keytabURI during namespace creation
- Resets namespace wizard after finishing edit
@tonybach tonybach force-pushed the feature/ui-cdap-13236-update-keytab-uri branch from 909bf19 to 1dd324d Compare April 6, 2018 22:58
@tonybach tonybach removed the On-hold label Apr 6, 2018
@tonybach tonybach merged commit c24c83f into develop Apr 6, 2018
@tonybach tonybach deleted the feature/ui-cdap-13236-update-keytab-uri branch April 6, 2018 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants