TYPO3 Core

I suspect the reason is that in the table "be_users", "db_mountpoints" is "varchar(40)". With ten items, nine characters would be taken by a comma (or other separator), leaving you with 31 characters for the page-IDs... so I guess your page IDs are probably largely three-digited (31 div 10).

Work-around fix: change the 40 (of varchar(40)) to something larger, e.g. 255. It'll still be finite, but it should let you add more, assuming Typo3 doesn't have that value hardcoded into the script somewhere.

EDIT -

Unfortunately, it seems I'm wrong. Even with VARCHAR and/or shorter page IDs, the issue persists. Shame. I'll see if I can find the time in the next few days to dig into the guts of T3 and figure out a semblance of a fix.

(Of course, any real fix would have to re-map the n:m relation on the database level.)

The db mounts are not stored on the be_users table, it is the field sys_workspaces.db_mountpoints which is already varchar 255

If you want to be able to add more than 10 you must modify the following TCA setting:

$TCA['sys_workspace']['columns']['db_mountpoints']['config']['maxitems'] = 10;

Pardon me, I was looking at BE users in my musings, not actually directly at workspaces - since conveniently, the issue is the same for both. Somewhen in my comment posting I guess I forgot the reported bug is about workspaces! Oops. You're right, of course. It's a completely mirrored situation for be_users, though.

Anyway, the real issue remains even with your fix, and even with VARCHAR, though thank you most, most kindly for providing that line of code -- I'm sure it will be a heavensent for the person who submitted this issue. =)

The issue being that this is an n:m relationship, squeezed into a single column (whether in be_users or sys_workspaces, in fact). With three-digited page IDs, you hit the limit of that form of storage at about 60 pages. Granted, adding 60 mount points to any account seems unlikely - but until I'd seen this bug, I'd thought adding 10 mount points was so unlikely it'd be statistically irrelevant... so I'm completely unsure just what the merit of my "it seems unlikely" is, and I would appeal to the developers of Typo3 not assume merit in such assumptions, either.

[Of course, I'm a bit of a database purist regardless, so seeing an n:m relationship squeezed into a 1:n variant screams "Fix me, please!" regardless of actual practical value.]

I agree with what you're saying, using a single column for this isn't the best way, it must at the very least put some strain on performance, but this is not unique to db mountpoints, it goes for groups/filemounts as well.

Changing to a text field instead of varchar would increase capacity further however I think varchar 255 is adequate as if you have that many mountpoints you might want to spread these mountpoints across user groups. We run a couple of large sites with 100+ users on and I only found a problem with one user who required 10+ db mounts.

FYI our 4.1.1 installation has varchar 255 for all these fields not 40, perhaps you should consider upgrading or running the database analyser?

After brief investigation:

In 4.1.1, all mountpoints (whether pages or files) are indeed varchar(255), regardless which table.

For the sake of completion: in 4.0.2, for example, be_users and be_groups still have "varchar(40)". For sys_workspace: "db_mountpoints tinytext NOT NULL". You've got a mirrored situation for file mountpoints... sys_workspace's is a tinytext, the other two tables have varchar(40).

(And 3.8.0 doesn't have a sys_workspace I could check on - which pretty much exhausts the versions I come across.)

So basically in the latest version there is not anything functionally wrong, it's just not good database design. :]

Unfortunately my knowledge of the system is not deep enough to know the implications of fixing this, I would imagine it would have an effect on a great deal of extensions.

This can be closed, I think.

As pointed out, the field has maxitems=10. If need more, you can adjust the TCA. If you need even more and the length of the comma-separated list would exceed 255 chars, you might change the database scheme.
Of course, mm-relations would have advantages (and disadvantages) compared to comma-separated fields.