Secondary groups don't seem to be working.

[donnoman]

I created a new group "special" I assigned a user to it, Log that user on, and not only does the user not see those items in the meta albums, they can't even see the album under the category its assigned.

Page generated in 0.272 seconds - 40 queries in 0.049 seconds - Album set : AND aid NOT IN ( AND aid IN (-1) ; Meta set: AND cpg14x_pictures.aid IN (-1) ;

[Tranz]

I created a new group "special" I assigned a user to it, Log that user on, and not only does the user not see those items in the meta albums, they can't even see the album under the category its assigned.

Page generated in 0.272 seconds - 40 queries in 0.049 seconds - Album set : AND aid NOT IN ( AND aid IN (-1) ; Meta set: AND cpg14x_pictures.aid IN (-1) ;

I was able to reproduce this on another install, so its not a result of my latest changes. I'm going to go ahead and commit my fixes.

I reproduced the new bug, too.

The original issue seems to have been fixed. When logged out, images from private albums do not show up in random meta album.

[donnoman]

Well for once, I'm reasonably certain this isn't something I broke.

I think there still may be issues with $META_ALBUM_SET, but $ALBUM_SET isn't correct right now either.

From what it looks like to me:

This line from functions.inc.php is part of the problem

Code Select Expand


       $sql = "SELECT aid FROM {$CONFIG['TABLE_ALBUMS']} WHERE visibility != '0' AND visibility !='".(FIRST_USER_CAT + USER_ID)."' AND visibility NOT IN ".USER_GROUP_SET;


USER_GROUP_SET  isn't getting the additional groups in "user_group_list".

ie:

This is the SQL line but this user is attached to 4 groups.

SELECT aid FROM cpg14x_albums WHERE visibility != '0' AND visibility !='10003' AND visibility NOT IN (2)

This is probably best addressed in the coppermine bridge file, I'd prefer a dev more familiar with bridging fool with it than me.  

[omniscientdeveloper]

Hmm


[edit]

Try the latest coppermine bridge, version 1.13.

[/edit]

[donnoman]

Using 1.13 still have the problem.

Album =  8 is assigned visibility = 5

My user Donnoman has user_group=5, user_group_list = 2,6,7

my group named "special" has an id of 5 and isn't shown.

album = 6 is shown, and does work and has visibility = 6

so slight improvement, but not fixed yet.

Code Select Expand


Page generated in 0.451 seconds - 94 queries in 0.156 seconds - Album set : AND aid NOT IN (8,36,37) ; Meta set: AND aid IN (6,38,39,7,1,2,3,4,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35) ;


[omniscientdeveloper]

OK. I know what the problem is.

[cryogenic]

I think I'm seeing the same bug? Basically I have two albums that are only viewable by administrators (myself and one other person) along with a special group of "friends" who are placed in the "friends" group. However, when a person from my friends group logs in, they cannot see the albums that I have allowed them to view. They cannot see anything that an unlogged in user can see when they should be able to. I just updated from CVS today thinking the problem might have been that my files were 4-5 weeks old, but it did not fix the problem.

[Tranz]

Has this been fixed? The special group I created now can see its assigned albums.

[donnoman]

Yes, this was related to another problem that was happening with the SMF bridge.

Omni and I addressed the coppermine.inc.php bridge and SMF, devs who work on the other bridges should read that thread, and check thier bridges.

http://forum.coppermine-gallery.net/index.php?topic=15067.0

[cryogenic]

Mine isn't bridged and I'm seeing that particular bug... is it a completely different issue or what?

Edit: updated the coppermine.inc.php file and it fixed the issue even though I don't have a bridged install.

[donnoman]

Coppermine 1.4 uses the coppermine.inc.php "bridge" for it's core user code. When you select a different bridge, it supplants Coppermine's native code.

The problem that you experienced while you believed yourself to be technically "un-bridged" was actually a problem in the coppermine bridge file.

So as you found out, updating the bridge solved your problem.

[Aditya Mooley]

Has this been fixed? The special group I created now can see its assigned albums.

Yes, but they can also see the albums which they are not supposed to see.
E.g. I am a member of "special" group only and I am also able to see the albums for "Registered Users".

[Tranz]

I confirmed that, and did uncheck the "registered" group from the user's profile. However, is "special" not just a subset of "registered"? As admin, if you allow an album to be seen by registered users, should they not be viewed by any registered user?

However, it is an issue when a user in the banned group can access special-access albums. :-\\ Actually, the banned group shouldn't be able to even access the album. I changed the setting for a user using the checkboxes and dropdown menu to "banned" and the user can still log in.

[Tarique Sani]

I confirmed that, and did uncheck the "registered" group from the user's profile. However, is "special" not just a subset of "registered"? As admin, if you allow an album to be seen by registered users, should they not be viewed by any registered user?

The name "registered"  is notional for a member being in a default group. If all groups are sub groups of registered then having album permissions does not make sense at all

[omniscientdeveloper]

The name "registered"  is notional for a member being in a default group. If all groups are sub groups of registered then having album permissions does not make sense at all

However, it is an issue when a user in the banned group can access special-access albums.

Actually, the banned group shouldn't be able to even access the album. I changed the setting for a user using the checkboxes and dropdown menu to "banned" and the user can still log in.

I don't understand what you guys want done. I was under the same impression as Tranz. Doesn't registered mean "registered"? It's natural that a user gets the highest privileges available to them, so if the user is a member of more than 1 group, the one with the most privileges is used. Basically they should merge.

If you guys notice, the default "registered" group is added to ALL accounts in all the bridges. This is probably just realized, since coppermine, itself, is now bridged. The IF statement says that if they're not an administrator (in an administrators group) and the user logged in then the user is a registered user, and it adds that group automatically.

[edit]

All that said, most likely, what's happening is that the login process isn't checking the group permissions correctly...meaning that it's not overiding the normal process of merging the groups. My plan, after the 1.4 release, is to clean up and redo the group process then let everyone test it out. Right now, it's kind of unstable...everything seems to be pieced together. Please explain what you guys want done. If you want the highest level to be default then it'll be all-inclusive; there's no way to prevent it. If you want lowest, then it'll also be all-inclusive.

On that note, what exactly does the banned group do that the ban column (I forgot the actual name) in the user's table don't do? I don't think there should be a group just for this. If it's done this way then it'll be cleaner and easier to program. The extra group messes it up, IMO.

[/edit]

[Tranz]

I don't think a banned user should be able to log in. As it is, a banned user is still able to log in, and access albums that are assigned to other groups.

[Casper]

I'm with omni and tranz on this.

surely registered is the basic group for membership, and albums viewable to 'registered only' should be viewable by all higher groups.  All members are part of the registered group, whether thay have other group membership or not.
That has always been the case.

If you want to restrict viewing of any album to certain members only, then you have them in a special group, and edit the album properties accordingly.

[donnoman]

IMO

The registered group should mean anybody who has an active user account that is not in the banned group.

Group rights should be merge, least restrictive wins.

banned should be like the "deny" right. It trumps all.  game over, do not pass go, do not collect $200.

[Casper]

much more clearly put that my post, but I agree entirely.

[omniscientdeveloper]

Yes, but they can also see the albums which they are not supposed to see.
E.g. I am a member of "special" group only and I am also able to see the albums for "Registered Users".

Now, we can remove the registered group from being automatically included, which is what the bridge files do, since it's possible for the admin to uncheck it in the user administrator. This may solve what you are talking about. I don't know what other problems it may cause though.

It may take me a couple days to test it out. I'll have to let someone else commit it though. Right now, my test computer can't get on the internet, since I'm away on a business trip.