-
Notifications
You must be signed in to change notification settings - Fork 159
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
Improved: have profileMenuLocation (OFBIZ-12981) #106
Conversation
Profile screens are used in various components as portalpageportlets, and have references to various party menus. As menus in the various profile screens are parameterized to use ${parameters.mainMenuLocation} this generates errors in the components/applications where these screens are used as portal page elements. Having a context-param profileMenuLocation resolves this issue. modified: myportal-web.xml: have contex-param profileMenuLocation
fixing conflict
Quality Gate passedIssues Measures |
Thanks Pierre, the AssetMaint integration tests pass? |
HI @JacquesLeRoux, the AssetMaint integration aspect got accidentally in this, but is something you committed to the main branch 4 days ago via 21aff95 I apologize if some things got crossed. |
I meant: did you run |
I did not. As the changes in this are in the web.xml file, which only affect the UI side and not any tests. However, I just ran the test against the main branch (trunk, up tp date per 07:00 this morning) and it failed. So something before that moment must have gone wrong in FixedAssetMaintTests.groovy |
Did you run the test(s)? |
Hi Pierre,
Wrong you also modified FixedAssetMaintTests and it's different than locally.
|
With https://issues.apache.org/jira/browse/OFBIZ-12985 |
Closing this. Time for a do-over as it is giving to much headache. |
Profile screens are used in various components as portalpageportlets, and have references to various party menus. As menus in the various profile screens are parameterized to use ${parameters.mainMenuLocation} this generates errors in the components/applications where these screens are used as portal page elements. Having a context-param profileMenuLocation resolves this issue.
modified:
myportal-web.xml: have contex-param profileMenuLocation