Bug 1782695
| Summary: | Redirection for config map is not happening correctly | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Aditya Deshpande <adeshpan> |
| Component: | Management Console | Assignee: | Jakub Hadvig <jhadvig> |
| Status: | CLOSED ERRATA | QA Contact: | Yadan Pei <yapei> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.11.0 | CC: | agawand, agudi, annelson, aos-bugs, aprajapa, apurty, aygarg, bpeterse, ckoep, fnieto, hgomes, jhadvig, jokerman, mbagga, mdhanve, mtaru, paolo.frusone, pchavan, pkanthal, pkhaire, rkcarter, spadgett, sparpate, tkimura, vwalek, whearn, xiaocwan |
| Target Milestone: | --- | ||
| Target Release: | 3.11.z | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause: Since we started to retrieving the PartialObjectMetadateList for ConfigMap list page, we need to tell to the navigateResourceURL filter explicitly that we need URL for configmap resource, since the resourceURL service function is aware about first-class resource, not the PartialObjectMetadate that is used.
Consequence: Redirect to the console page, instead of ConfigMap details page.
Fix: Supply the navigateResourceURL filter with kind and name space in the ConfigMap list page.
Result: Redirect will happen to details page of picked ConfigMap.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-02-19 19:53:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Aditya Deshpande
2019-12-12 07:14:57 UTC
Not really sure about the reproduction steps and their meaning. Could you please provide step by step actions, since the one in the description are not clear to me. Thanks! 1. Go to any project having configmaps as follows:
Select-project ==> Resources ==> Config Maps ==> get the list of configmaps.
2. Click on any configmap and it will show you the respective yaml file.
3. Go back to configmap list
Click on "Config Maps" written in left upper corner.
4. Click again on any configmap, it will redirect to the main console page.
Before clicking on any configmp, do right click and check the copy link location:
This will give you URL as https://openshift.test.com/console/
So, the problem here is that clicking on configmap(second-time) is not redirecting to the correct page showing the yaml instead it is redirecting to the console page.
I am attaching the screenshots.
*** Bug 1787185 has been marked as a duplicate of this bug. *** *** Bug 1785752 has been marked as a duplicate of this bug. *** *** Bug 1789136 has been marked as a duplicate of this bug. *** Follow steps by https://bugzilla.redhat.com/show_bug.cgi?id=1782695#c3 The step "4. Click again on any configmap" takes user to the configmap detail page which is expected. Verified on OpenShift Master / Web Console: v3.11.165 *** Bug 1795409 has been marked as a duplicate of this bug. *** *** Bug 1795738 has been marked as a duplicate of this bug. *** Hi Vladislav, we tried the strategy indicated by you but it still doesn't work. However, we have found a workaround which is to manually add the name of the configmap to be edited at the end of the configmap homepage link. In this way we are able to edit the CM from a WEB console (so we think it may be a simple problem of redirecting Hyperlinks). Regards Paolo Hey Paolo, that was for XiaochuanWang to test the behavior. Still checking update from Engineering about that. Thx Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0402 *** Bug 1804957 has been marked as a duplicate of this bug. *** The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days |