[#37478] - [4.1] When loading a new menu item type, keep the session data and fallback to filter
- Fixed in Code Base
- 5 Apr 2022
- Medium
- Build: 4.1-dev
- # 37478
- Diff
- Digital-Peak:j4/menu/change-type
User tests: Successful: 2 coolcat-creations, simbus82 Unsuccessful: 0
Pull Request for Issue #22150.
Summary of Changes
When changing a menu item type for an unsaved menu item, then the session data should be used instead of the filter data or null. This pr puts the behavior from #6976 as fallback which is fine IMO.
Testing Instructions
- In backend menus, click "New"
- Enter a name, set an access level and other different attributes in the right sidebar
- Then click on the "select menu type" button
- Choose a different Menutype
Actual result BEFORE applying this Pull Request
The access level and other changed attributes values do get reverted.
Expected result AFTER applying this Pull Request
The access level and other changed attributes keep the previous defined values.
| Status | New | ⇒ | Pending |
| Labels |
Added:
?
|
||
joomla-cms-bot
- | Category | ⇒ | Administration com_menus |
| Title |
|
||||||
| Title |
|
||||||
@simbus82 can you post some screenshots how to reproduce the reverted behavior? When I retry your steps I still have the filter in the form set.
Same as @coolcat-creations has written, i have double checked and only the permission is not set by previous filters selection.
With the screenshots you do not see too much, but I had a video, only it is full of "private" data of the site used as a test.
Maybe the last row in your code need to be like others?
$data['parent_id'] = $data['parent_id'] ?? ($filters['parent_id'] ?? null);
$data['published'] = $data['published'] ?? ($filters['published'] ?? null);
$data['language'] = $data['language'] ?? ($filters['language'] ?? null);
$data['access'] = $data['access'] ?? ($filters['access'] ?? Factory::getApplication()->get('access')); /* THIS */
Can you guys test again? The access level should be unset now.
I have tested this item
Sure!
The access level and other changed attributes are keeping the previous defined values and the behaviour from #6976 is working!
Thanks a lot!
PS: maybe we can open a new feature request for extend the behaviour to the "parent item" field too.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37478.
I have tested this item
Tested successfully.
Me and other Joomla users waited for this bugfix for at least 4 years it's a day to celebrate for me because this was a very very annoying bug :-)
THANK YOU SO MUCH !!!!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37478.
THANK YOU SO MUCH !!!!
You worked for that too, just in the background
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37478.
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-04-05 14:24:11 |
| Closed_By | ⇒ | Quy | |
| Labels |
Added:
?
|
||
Thanks
I have tested this item? unsuccessfully on 0635d4e
Tested on Joomla 4.1.2.
The access level and other changed attributes are keeping the previous defined values after one or more changes of the menu type. This is really great.
The bad is that now the behaviour from #6976 is not working anymore.
If i do a filter selection in the menu manager, after creating a new menu item, i have no preselected values.
If the loss of this functionality was unintended, the test was unsuccessful for me.
Is it not possible to maintain both behaviors? I like this patch, it can save us a lot of time!
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37478.