Bug #29208
closedVersioned elements aren't listed if "limit to languages" is set.
100%
Description
As soon as I use "limit to languages" on an editor, this editor won't get anything listed in the workflow module. Of course I've checked, that there have been elements edited in the language, the editor is limited to. Could somebody try and confirm this problem?
Files
Updated by Michael Elzer about 13 years ago
Jan Wulff wrote:
As soon as I use "limit to languages" on an editor, this editor won't get anything listed in the workflow module. Of course I've checked, that there have been elements edited in the language, the editor is limited to. Could somebody try and confirm this problem?
I can confirm this problem. I've made a report in the old bugtracker by mistake (ID 001828) describing nearly the same problem. But i did not realize that "limit to language" forces into this problem (course all our translators using the workspaces are limited to their languange in our environment). I've updated to 4.5.6, disabled "limit to language" and all items are listed as before. 4.5.3 works as expected - all newer versions not.
Updated by Robert Heel about 13 years ago
I can confirm this issue, too. This happens if the editor hasn't access to the default language.
Updated by Robert Heel about 13 years ago
- File 29208_ws_no_default_language.diff 29208_ws_no_default_language.diff added
- % Done changed from 0 to 50
The record list contains no language field - I've added '*' to the field list (Patch attached), but would also be possible to add only the table's sys_language_uid field.
Updated by Robert Heel about 13 years ago
pages_language_overlay language detection also didn't work - needed some more lines of code.
Updated patch attached.
Updated by Andreas Kießling about 13 years ago
I also confirm the bug.
There will still be a problem with tables that have no language field. If such a record is in the workspace, the check against language 0 will be done.
I am somehow missing such a function to check the access for a record+language in class t3lib_userAuthGroup.
There is a checkFullLanguageAccess, that checks for access to ALL existing localizations, and the used checkLanguageAccess, that checks the passed value against the allowed_languages
Updated by Jozef Spisiak about 13 years ago
- File 29208_ws_no_default_language.diff 29208_ws_no_default_language.diff added
- % Done changed from 50 to 100
This should fix the issues mentioned in Andreas post. For me it works, but can anyone please test it?
The diff was done on latest version from repository, so you probably need to do the changes for 4.5 manually.
Updated by Christian Buelter about 13 years ago
+1 testing
I had the same Problem, patch 29208_ws_no_default_language.diff works for me.
Tested in 4.5.6
Updated by Mr. Jenkins about 13 years ago
Patch set 1 of change Id1f44f0e9708c76cfc859418206ed02bccc2d24a has been pushed to the review server.
It is available at http://review.typo3.org/6757
Updated by Stefan Neufeind about 13 years ago
- Status changed from New to Under Review
Patch v3 submitted for review.
Updated by Mr. Jenkins about 13 years ago
Patch set 2 of change Id1f44f0e9708c76cfc859418206ed02bccc2d24a has been pushed to the review server.
It is available at http://review.typo3.org/6757
Updated by Mr. Jenkins about 13 years ago
Patch set 1 of change Id1f44f0e9708c76cfc859418206ed02bccc2d24a has been pushed to the review server.
It is available at http://review.typo3.org/6807
Updated by Mr. Jenkins about 13 years ago
Patch set 1 of change I771241b38db2ab81a48892ed6b55b401dbf7b5f3 has been pushed to the review server.
It is available at http://review.typo3.org/6812
Updated by Stefan Neufeind about 13 years ago
- Status changed from Under Review to Resolved
- Assignee set to Stefan Neufeind
Updated by Michael Stucki almost 11 years ago
- Project changed from 624 to TYPO3 Core
- Category changed from Workspaces to Workspaces