The number of items in the toolbar dropdowns is truncated to 15 items for all types of data (ie. Spaces, Sections, etc) except for Subspaces, all of which will be shown. In a Space with lots of Subspaces, this can make the list taller than the screen and since there is no scrolling, it can make important links like "Create new subspace" and "Create new section" impossible to get to.

I'll attach a patch in a moment to truncate the Subspaces list to 15 items just like the rest of the lists!

CommentFileSizeAuthor
#1 oa_toolbar-subspaces-truncate-2410477-1.patch502 bytesdsnopek

Comments

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented
Status: Active » Needs review
StatusFileSize
new oa_toolbar-subspaces-truncate-2410477-1.patch502 bytes

Attached patch works in my testing. Please let me know what you think!

mpotter’s picture

mpotter commented
Status: Needs review » Fixed

Committed to e794f20 of oa_toolbar

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
commented

Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Anonymous’s picture

Anonymous (not verified) commented
Status: Closed (fixed) » Needs work

Today I noticed with a customer that even the 15 limit was too much for his screen.
It would be nice if the 15 could be set in the Toolbar settings.

dpoletto’s picture

dpoletto commented

@joep.hendrix: that would be a Feature Request (let the the number of Sub-Spaces to be shown on the Toolbar dropdown list to be a Toolbar's setting instead of an arbitrary fixed value).

Anonymous’s picture

Anonymous (not verified) commented

Agreed (however it is still a minor bug for small screens where there is no workaround).

dpoletto’s picture

dpoletto commented

Don't know how much, as user, my opinion would worth...but +1 on that (I too have users with limited screen size - at present time this is a real paradox considering available wide screens - and a site with Space full of Sub-Spaces, still at present time less than 15 but who know what the future will be? ...so would be nice to have that number customizable through the Toolbar's settings).

Anonymous’s picture

Anonymous (not verified) commented

We tried to fix the height of the dropdown with css to be max. 75% of the viewport with scrolling but then the create new space submenu does not show up.

pommard’s picture

pommard commented

Hi,

having the opposite problem.

We use wide screens and we would like to see more than 15 items. Where do I have to change the code?

Thanks.

dpoletto’s picture

dpoletto commented

Looking at the patch committed above (incorporated 11 months ago):

http://cgit.drupalcode.org/oa_toolbar/commit/?id=e794f20019c46cc7836ff8d...

I think you can easily modify that fixed value accordingly (actually it is 15) to change the number of sub-spaces shown on the drop-down Toolbar's menu by your site (so, by playing with various values, you can verify which one value is good enough in your specific case).

As you can see the involved module is the oa_toolbar.module (that patch was committed against *that* module) and so you should be able to find that piece of code exactly watching at the file:

/profiles/openatrium/modules/apps/oa_toolbar/oa_toolbar.module

available on your web server's document root.

pommard’s picture

pommard commented

Yep,

that's it thanks

dpoletto’s picture

dpoletto commented

@joep.hendrix, @pommard: This was a Closed Bug...your requests fall more into a new little feature...so would be better, IMHO, to open a specific Feature Request on that if you consider that customizing/setting that value through the Toolbar's settings page (and doing so in a way or another) would be good. Isn't it?

Anonymous’s picture

Anonymous (not verified) commented

Not sure, for me the original bug is not fixed properly. There is no workaround for regular laptop screens (not the retina macbook pro's). That is the reason I reopened the issue but if it makes the maintainers' life easier, no problem to close it.

dpoletto’s picture

dpoletto commented

Yep, as far as I can understand it, the fix provided by that patch is to put (at code level) a threshold to the number of Sub-Spaces shown and not to provide a way to manage that threshold by mean of a user setting...(not sure) if the issue were created with a Feature Request's category instead of using a Bug's category (providing that there was a behaviour that needed to be corrected) probably the patching approach would have been a little bit different. Just my 2 Euro ;-) cents.