Bug #2752
closed
J1.7: usergroup mapping from user object and not from api
Description
The usergroup mapping is from direct user object, which is fine if a user is logged in as the user object actually exists. However, for users not logged in they do not exist and direct data from object is direct data from database which for a user not logged in that data doesn't exist. Instead of ->groups the function getAuthorisedGroups needs to be used for proper usergroup construction.
:ORIGINAL BODY:
When viewing a profile with known articles as a public user none of those articles are displayed. They DO display if you're a registered user however. This appears to be an issue with the database query in regards to checking Access to that article.
Files
Updated by krileon over 13 years ago
- File cb.tables.patch added
- File plugin.foundation.patch added
- Subject changed from J1.7: Articles tab not showing articles to public users to J1.7: usergroup mapping from user object and not from api
- Status changed from New to Resolved
- Assignee set to beat
- Priority changed from Normal to High
- Target version set to CB 1.7.1
- % Done changed from 0 to 100
Updated by krileon over 13 years ago
- Status changed from Resolved to Assigned
- Assignee changed from beat to krileon
- % Done changed from 100 to 80
Applying cb.tables.patch appears to cause a bug when editing a user the usergroup selection is lost.
Updated by krileon over 13 years ago
- File cb.tables.patch cb.tables.patch added
- File plugin.foundation.patch plugin.foundation.patch added
- Status changed from Assigned to Resolved
- Assignee changed from krileon to beat
- % Done changed from 80 to 100
Previous patches provided integer formatted array while everything was === to strings. New patches grab the IDs without recurse (we only want the IDs that are directly mapped to the user) then converts it to string values where needed.
Updated by beat about 13 years ago
- Status changed from Resolved to Closed
- Estimated time set to 5:00 h
Fixed in r1576 .
Thank you Kyle.