TYPO3 Core

Cool: can reproduce locally on my test system.

Method checkMod() of t3lib_loadmodules does this:

if (!$MCONF['shy'] && $this->checkModAccess($name, $MCONF) && $this->checkModWorkspace($name, $MCONF)) {

and checks fails (FALSE) within method checkModWorkspace:

function checkModWorkspace($name, $MCONF) {
    if ($this->observeWorkspaces) {
^^^^ this test is true ^^^^
        $status = TRUE;
        if ($MCONF['workspaces']) {
            // snipped
        } elseif ($this->BE_USER->workspace === -99) {
    ^^^^ this test is true as well ^^^^
            $status = FALSE;
        }
        return $status;
    } else {
        return TRUE;
    }
}

Additional information: sysext workspaces is not loaded

If I load sysext workspaces, and I try to log in again with that non-admin user, it now fails with

No such workspace defined

InvalidArgumentException thrown in file
/path/to/typo3/sysext/workspaces/Classes/Service/Workspaces.php in line 105.

Changing class.modulemenu.php, method __construct(), line 66 with:

$this->moduleLoader->observeWorkspaces = t3lib_extMgm::isLoaded('workspaces');

instead of

$this->moduleLoader->observeWorkspaces = TRUE;

solves the problem when sysext workspaces is not loaded but when loaded, the "non existing workspaces" error still occurs.

I tried to reproduce it without sucess. What I did:

1) Got the 4.5.6 Introduction package running (from the typo3.org downloads)
2) Logged in with "advanced_editor" - everything fine
3) Permitted access to the workspaces modules to the "advanced_editor" - everything fine
--- at this stage I've a nicly running system so the actual test starts now:

4) Changed to Core sourcefiles to 4.6 RC1
Repeated 2) and 3) -- everything fine

5) Ran through all upgrade wizards in the install toll
Repeated 2) and 3) -- everything fine

I missed something right?

I guess that the problem comes if you upgrade an install where workspaces NEVER was loaded nor used. This is my case at least for this install.

I cannot say how long it dates back but I'm 90% sure it first was a 4.4 install which got updated to 4.5 when it came out and now upgraded to 4.6 RC1. workspaces was never used.

Did the same thing starting with the 4.4.1 Introduction Package... same result, everything looks fine. Besides that I can't really see how installations differ if workspaces have or have not been installed before (other that the extList and couple of db tables.

Anyways keep me posted if there's a way to reproduce it with one of the intro-packages.

Don't know if it helps but the real problem in the case I experience is the workspace "-99", not the "checkWorkspace" variable (I guess).

A friend of mine who actually runs the production website I had a problem with told me he experienced this before letting me know about it and first tried to set the workspace to "0" for his backend users. The hack worked for a while but "suddenly" the workspace was set back to -99 and the whole broke again. I'd say "suddenly" is after some change in the user settings.

Anyway, if you analyze the code, it's clear that all the checks regarding workspaces should never return anything else than TRUE if workspaces are not used...

I just upgraded another website and do not have this problem, however this was a website that started with TYPO3 4.5. The 2 websites I had problems so far were older (4.4 for one of them, 4.3 or 4.4 for the other?) that were upgraded to 4.5 and now to 4.6.

From a grep:

./t3lib/class.t3lib_userauthgroup.php: var $workspace = -99; // User workspace. -99 is ERROR (none available), -1 is offline, 0 is online, >0 is custom workspaces.
./t3lib/class.t3lib_userauthgroup.php: * @return integer Default workspace id. If no workspace is available it will be "-99"
.

getDefaultWorkspace

This function does 3 things:
1) it checks wether Ws with id=0 exists and is allowed for user
2) it checks for WS with id=-1 and is allowed ( this is the old draft workspace, which was dropped, I think)
3) it checks wether the ws module is loaded and any other workspace is allowed.

if all checks fail, it returns -99.
So my guess is, that the problem can be reproduced if neiter WS 0 nor WS -1 are allowed for a user and the Workspace extension is not loaded.
Or for user who only had access to the old draft workspace and where not migrated to use the new workspace.

Actually, the upgrade wizard for workspace does create a new workspace for the old draft workspace, but does not change anything in be_users/be_groups to reflect this change.

And if you don't upgrade because you never used workspaces and as such do not run this upgrade wizard, then this old setting causes the aforementioned problem.

Patch set 1 of change I2f16a630a8f02bf1aa9a5bd61a340b53b6fd1365 has been pushed to the review server.
It is available at http://review.typo3.org/6063

Patch set 1 of change Ief4f030134359e9d2b27b82ae4c5de6a7b5b800e has been pushed to the review server.
It is available at http://review.typo3.org/6073

Patch set 2 of change I2f16a630a8f02bf1aa9a5bd61a340b53b6fd1365 has been pushed to the review server.
It is available at http://review.typo3.org/6063

Patch set 2 of change Ief4f030134359e9d2b27b82ae4c5de6a7b5b800e has been pushed to the review server.
It is available at http://review.typo3.org/6073