-
Notifications
You must be signed in to change notification settings - Fork 290
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
Fixes #22730: add manage manifest modal to subscriptions page. #7305
Conversation
Issues: #22730 |
@Rohoover, see above please. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, we have confirmation of a modal on modal use. This can be adapted for delete confirmation. Let me know what you think about this or if you want to see a mockup first.
As for a progress bar, here are a couple thoughts:
We can disable all table actions (except for Manage Manifest) and continue to show the progress bar in the manifest modal. We could also - if technically feasible - place a progress bar on the content area of the table. Perhaps the content is faded back, or replaced completely. I can mock this up too if think this is worth pursuing.
Do you have an screenshot of this from another application? That would suffice for me, I don't need a mockup of this particular page.
Well currently there is a "bug" that the manage manifest modal pops open every 3 seconds if you close it when the progress bar is updated. This could be a "feature" by just ensuring the modal is open when a task is ongoing and then just show the progress bar there. Just a thought. |
Yeah, true, I wasn't sold on it even when I proposed it. I think a progress bar on the subscriptions page itself would be a better way to go. Do you have a strong preference to put it in the table versus above it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put it above it, much like how the modal has a dimmed background, so users don't think the content was all blown away.
Oh, interesting, when I said above I meant in the content area above the table but I like this better. |
Does anyone care if I complete these items as follow on PRs? |
Tests added, would like to handle the rest of the todo items as separate PRs. Thoughts? |
http://projects.theforeman.org/issues/23283
http://projects.theforeman.org/issues/23284
http://projects.theforeman.org/issues/23285
|
TASK_BULK_SEARCH_FAILURE, | ||
} from './TaskConstants'; | ||
|
||
export const bulkSearch = (extendedParams = {}) => (dispatch) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These task related actions, reducers, and constants should probably be move to foreman (or at least the move_to_foreman
directory 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice @waldenraines !
I went through the code and did some testing. It works mostly fine. I added some questions and nitpicks inline. Given that this is still in the labs section, I agree it's fine to fix all of them as separate PRs as long as we track it somewhere. Maybe just saving the org to state could be fixed now.
Btw I noticed TypeError: deburr(...).replace is not a function
after both delete and upload manifest. Not sure what causes that.
} | ||
} | ||
|
||
export const foremanTasksApi = new ForemanTasksApi(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 nice!
|
||
const emptyStateData = () => ({ | ||
header: __('There is no Manifest History to display.'), | ||
description: __('Import a Manifest using the details tab.'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact the tab is called "Manifest", not "details".
url: 'http://redhat.com', | ||
}, | ||
action: { | ||
title: __('Upload Manifest'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This button has no effect. Can we just hide it?
|
||
case GET_ORGANIZATION_SUCCESS: | ||
case SAVE_ORGANIZATION_SUCCESS: { | ||
return Immutable({ loading: false }, ...action.response); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this should have been Immutable({ loading: false, ...action.response})
. Currently the fetched org data doesn't get stored in the state.
showModal: props.showModal, | ||
}; | ||
|
||
this.hideModal = this.hideModal.bind(this); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like https://github.com/patternfly/patternfly-react/blob/master/src/common/helpers.js#L3-L7 would be handy. But no need to add it in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, thanks, I didn't even know that existed!
|
||
<FormGroup> | ||
<ControlLabel className="col-sm-3 control-label" htmlFor="usmaFile"> | ||
{__('USMA')} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we're missing an info tooltip here (what is USMA? :))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, we should have a tooltip here that shows "Upstream Subscription Management Application".
library_id: 1, | ||
}); | ||
|
||
export const successState = Immutable({ loading: false }, ...requestSuccessResponse); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering why the tests don't fail:)
{ loading: false, ...requestSuccessResponse }
here too
componentDidMount() { | ||
this.loadData(); | ||
} | ||
|
||
loadData() { | ||
this.props.pollBulkSearch({ | ||
search_id: 'pollBulkSearch', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we use some more specific search_id? activeManifestTasksSearch
or something similar.
It should probably be a constant too.
webpack/scenes/Tasks/TaskReducer.js
Outdated
|
||
const initialState = Immutable({ loading: false, results: [] }); | ||
|
||
export default (state = initialState, action) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this reducer and state used anywhere or are you planning to use it anywhere? Or does it help debugging?
I'm just wondering if it makes sense to store results of any search in the generic state node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can probably just be removed. I was using it at first but then changed my implementation. I will remove.
I'd really prefer getting all of these large pieces in first and fixing these known issues after the fact if at all possible. |
|
NP, it's a simple issue, we can do it after |
@tstrachota updated. I believe I have fixed all of your comments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 let's merge this
...once the tests are green, of course 😃 |
[test katello] |
I'm fine with this being merged as-is, and I know you're aware of something the things I'm mentioning here, but here's my feedback:
|
@jturel did you test Walden's latest commit? I was experiencing some of the issues you're describing but they got fixed with the latest update. |
@tstrachota ah - nope. let me pull that down and take a look |
[test katello] |
Hmm, odd, was that right after you imported one?
I suppose we could look at not disabling the entire modal but just disabling the actions within the modal that cannot be done while an upload/delete/refresh is in progress.
@Rohoover thoughts on that?
There is now a tooltip that shows what it stands for.
It should be but I have not yet made it grab the latest organization upon successful save.
See above. |
[test katello] |
2 similar comments
[test katello] |
[test katello] |
Yes! Extra note:
ok, that helps but the acronym just feels out of place to me. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shaping up very nicely & left my thoughts. Thanks!
APJ
That came from the mockups, @Rohoover thoughts? |
Yeah, I think that's due to the lack of an organization refresh, I hope to fix that as part of http://projects.theforeman.org/issues/23283 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes on disabling buttons in modal.
Yes on an extra notification of completed refresh.
[test katello] |
1 similar comment
[test katello] |
[test katello] |
http://projects.theforeman.org/issues/22730
TODO:
Questions for UX: