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

UI - identity details #4502

Merged
merged 27 commits into from
May 24, 2018
Merged

UI - identity details #4502

merged 27 commits into from
May 24, 2018

Conversation

meirish
Copy link
Contributor

@meirish meirish commented May 3, 2018

This adds a lot more inline-editing for the various bits of identity (entities, groups, and their associated aliases).

We also added support for disabling entities, and added a number of acceptance tests that we didn't have time to do on the first pass.

This flushed out a few bugs with our front end list caching - which we've added to the internal backlog of tech debt to get rid of / simplify.

identity-details

@meirish meirish requested review from a team May 3, 2018 17:13
const { attr, hasMany } = DS;

export default IdentityModel.extend({
formFields: ['name', 'policies', 'metadata'],
formFields: ['name', 'policies', 'metadata', 'disabled'],
Copy link
Contributor

Choose a reason for hiding this comment

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

What do you think about moving disabled to after name? I've been trying to keep the list builders at the bottom so the other fields don't get lost

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh yep, we can do that, the spacing just felt a little strange but I totally forgot about list builders haha. I'll update it!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

screen shot 2018-05-03 at 1 49 48 pm

Updated in the latest!

joshuaogle
joshuaogle previously approved these changes May 3, 2018
Copy link
Contributor

@joshuaogle joshuaogle left a comment

Choose a reason for hiding this comment

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

I took this for a spin. Aside from those very minor suggestions, looks good from the design side 👍


{{#if (and (eq mode "edit") model.canDelete)}}
{{#confirm-action
buttonClasses="button is-link is-outlined is-inverted"
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we just do buttonClasses="button is-ghost" here? I think that's basically what you were going for

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(sorry for the late response!) ooo yes, that's much nicer - should we also add has-text-black or is the blue text ok?

Copy link
Contributor

Choose a reason for hiding this comment

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

Blue text is preferred really. Some places we use black anyway if blue just doesn't look right, but this one needs help making it clear it's an action

Copy link
Contributor Author

@meirish meirish May 8, 2018

Choose a reason for hiding this comment

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

Oh! Ha, I'll update the policy edit pages then too. 👌(probably some others that need updating too)

Copy link

@DingoEatingFuzz DingoEatingFuzz left a comment

Choose a reason for hiding this comment

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

Looks good!

Generally thinking here: a lot of the model and popup code is repetitive. It's probably worth giving this some more thought so future popups and modeling is easier/faster to implement.

@@ -16,6 +16,7 @@ export default Ember.Component.extend({
class={{buttonClasses}}
type="button"
disabled={{disabled}}
data-test-confirm-action-trigger=true

Choose a reason for hiding this comment

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

Was there a particular motivation for assigning true rather than assigning it nothing?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh ha, just habit from components 😬


memberId: computed('params', function() {
return this.get('params').objectAt(2);
}),

Choose a reason for hiding this comment

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

In the event that params is not an ember array (most likely null) this will blow up.

},
'id',
'identityType'
),

Choose a reason for hiding this comment

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

These ten lines can be refactored as a computed property macro, making something like

updatePath: queryCapabilities('identifyType', 'id'),

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the nudge on this 🙌 - I was able to generalize the pattern we've used across the codebase with a computed macro + the use of a tagged template function to properly interpolate the paths with the named keys. This particular one can even be curried once since the path patterns are the same for all of the identity models ✨. I'll go back in another PR and use it throughout the codebase, but already it's cut down on a lot of code:

feba7a9

this.controller.get('model').reload();
});
}
},

Choose a reason for hiding this comment

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

Another way to do this, not sure if it's better or not, is to never provide a model to link-to. Instead, only give IDs. Then the route will always go through the model hook. The downside is you have to trust all templates to use link-to as expected.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah we were doing that and refreshing on every tab and I felt like it was overkill, but maybe it's not a terrible thing...

background-color: darken($orange, 5%);
border-color: darken($orange, 5%);
}
}

Choose a reason for hiding this comment

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

$orange isn't in the colors array?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No 😭 - only the colors associated with states - primary, warning, etc.

aliasIndexPage.flashMessage.latestMessage.startsWith('Successfully deleted', `${itemType}: shows flash message`);
});


Choose a reason for hiding this comment

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

Extra lines hangin' out.

createItemPage.createItem(itemType, 'external');
} else {
createItemPage.createItem(itemType);
}

Choose a reason for hiding this comment

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

This isn't so bad, but I always get nervous putting control flow in test helpers. It makes them brittle and can be really hard to trace values to.

disabled: true,
canEdit: true
});
sinon.spy(model, 'save');

Choose a reason for hiding this comment

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

Spies ❤️

sinon.spy(model, 'save');
this.set('model', model);
this.render(hbs`{{identity/item-details model=model}}`);
assert.dom('[data-test-disabled-warning]').exists();

Choose a reason for hiding this comment

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

QUnit DOM looks really helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's been really nice where we don't want / need / already have a full ember-cli-page object.

`${testCase.identityType} ${testCase.mode}: cancel link is correct`
);
});
});

Choose a reason for hiding this comment

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

What are your thoughts on putting the test in the forEach, so each test gets its own line in the test runner?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, going to change this - did it in a different PR and it's much nicer IMO (though you can't user arrow functions for the outer one anymore) .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed in f317154

@joshuaogle
Copy link
Contributor

@meirish Can we change those success banners to be the "toaster" type of alerts that float in the lower left? We should use those for alerts that don't require you to do anything (probably all success, sometimes some others)

@jefferai jefferai added this to the 0.10.2 milestone May 22, 2018
@meirish meirish merged commit 3bc90ac into master May 24, 2018
@meirish meirish deleted the ui-identity-details branch May 24, 2018 03:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants