Currently, we have views for the source tab. We can edit them.
For the coded lists, we have fixed pagination limits. And no way to reconfigure them.
Combined with the issue that we lack capabilities to persist selections through multiple pages, this is a severe UX issue.
For us, the most simple solution is to disable pagination and select in one single huge list.
Not my favorite situation. But we can live with it and it's a good start.
Something like this would fix our situation:
# drush vset tmgmt_page_limit 1000
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | handle-empty-node-types-list-2153597-10.patch | 1.06 KB | berdir |
Comments
Comment #1
berdirNote that large lists are quite a performance hog, it's often not just a single query but we need to load additional data or we load whole entities. Loading a 1000 nodes including translation medata is going to be quite a hit.
Comment #2
miro_dietikerPerfectly agree. That's why i'm not asking for such a default.
Comment #3
blueminds commentedSomething like this?
Comment #4
berdiryes, but I think this should be the default for those functions instead of specifying it explicitly when we use it.
I even hat the crazy idea what we could try to place the variable_get() in exported default views, might work but there's a relatively high chance of overriding it again when we change them.
Comment #5
berdirComment #6
miro_dietikerYou could write a test for it -- so we won't forget it. ;-)
Comment #7
blueminds commentedhere we go
Comment #8
miro_dietikerWonderful. Fixed it.
There's some strange debug output from Views though we should look into...
BTW: I wonder why we had less tests in january 2014 than in december 2013..?!
Comment #9
berdirAs discussed, re-open so that we don't forget to look into that debug thing.
Comment #10
berdirFound it.
Comment #11
miro_dietikerAdded "translatable" to the comment and committed it.