[SOLVED!] Guest user shown lower "total items" count than a logged in user.
|
robotphotos
Joined: 2005-09-21
Posts: 111 |
Posted: Wed, 2005-09-21 03:55
|
|
I'm seeing some discrepancies in a sub-album between the total number of items reported to the guest user, and a logged in user (doesn't need to be an admin). At first glance, it appears that the subalbums aren't counted for guest, because in my example, I have 22 images and 4 subalbums. Guest sees 22 total items, wheras a logged in user sees 26. I've stumbled accross this while trying to troubleshoot a larger issue (a discrepancy of about 1,000 items at the top-level). Some of my images have specific permissions so Everybody can't view them, only certain users. I've noticed some funkiness with how my permissions have carried over after migrating from G1, and I'm slowly going through album-by-album to verify each sub-album. However, permissions don't seem to apply to this specific case, because both the guest and logged in users can see all of the photos and subalbums.
|
|
Posts: 388
I had been wondering about the same -- see Size summary description and Counters
Posts: 111
I think my thing is slightly different. If my understanding is correct, you have issue with the term items and to what that refers. I don't care about that. Well, I do, but not with respect to the problem at hand. Regardless of what it is that is being counted, my number for the total changes, solely based upon whether or not you are logged in -- and the guest (Everybody) user has all the view permissions of everyone else, in this case.
Posts: 3236
For my albums w/o hidden or restricted items, the numbers match spot on. I have about 2 albums where some things are hidden and the number changes by either the exact amount or very close to it (I didn't care enough to track it down to +/- 5). I suggest you double check that you haven't gotten any hidden or restricted items inside, though that might be akward to figure out. If an item was *hidden* in G1 during import, I think the perms get kinda funky on the item in G2.
Like Gallery? Appreciate my help? Think I'm an asshole? Make your point by donating to the Gallery project! Or maybe just visit my website.
Posts: 111
I thought the same thing, initially, since it coincided with some permissions funkiness I noticed. However, I've looked at each of the four sub-albums, the sub-album that contains them, and all the photos contained therein, and each of them has permissions assigned to the Everybody user for "[core] View item".
It is definitely possible that some of them were hidden in G1. However, I haven't been able to discern anything funky with the permissions for these 26 items.
Posts: 111
If anybody has any ideas, I still need help with this, please.
Posts: 32509
add remove add view all version permissions for the albums that contain the images for the everybody group, and check the count again.
Posts: 111
OK; I re-read that a few times and I think I understand it. Hang on, lemme give it a shot.
Posts: 32509
heh, sorry
Posts: 111
OK; I did that, and it showed the correct numbers. Then, I removed the "View Original" permission for the Everybody user, and it still shows the correct number.
So, it looks like the permissions got scrambled somehow, and I flushed that out by removing and rewriting them.
Do you know if there is a way to do this without having to do this for all the albums individually? Not all of my albums have the same permissions.
Posts: 32509
"[core] view item" is what counts, the other view permissions don't matter.
to fix this globally, you'd have to post a viewable tree change event that affects the whole gallery.
or just edit the db, and it's easy
table g2_DescendentCountsMap
truncate / delete all rows. it's just a cache.
then go to lib/support/ and delete the db cache.
Posts: 111
Interesting... I'm going to try this later, when I can be in front of the server. Thanks for your help!
Posts: 111
Well, I deleted the rows from g2_DescendentCountsMap, but in /lib/support, these are the only caches I see:
g2data/cache/cache/derivative (Contains thumbnails and resizes; expensive to rebuild)
g2data/cache/cache/entity
g2data/cache/cache/module
g2data/cache/cache/theme
g2data/cache/smarty/templates_c
Posts: 111
Hmm... I logged into my gallery and went to: Site Admin -> Maintenance and I see there an option for deleting the database caches that reads as follows (from my doing so previously):
Successfully deleted directory: /Library/WebServer/Documents/robotphotos.org/g2data/cache/entity
Successfully deleted directory: /Library/WebServer/Documents/robotphotos.org/g2data/cache/theme
Successfully deleted directory: /Library/WebServer/Documents/robotphotos.org/g2data/cache/module
So, I'm going back to /lib/support and deleting them.
Posts: 111
Those tasks have been completed. However, when noone is logged in, the total items shown still appear to be more than 1000 less than I saw in my G1 installation. So, I guess I need to go into all the sub-albums and rebuild the permissions. :-\
Posts: 32509
if you deleted all rows in the descendent count map table and went to /lib/support/ to delete the db cache too BEFORE you accessed g2 again, then all new item counts it shows in g2 are newly calculated = they must be correct.
Posts: 111
...unless there exist items whose permissions do not allow the Everyone user the permission "[core] view item"?
I deleted all the rows in g2_DescendentCountsMap and verified that they were deleted by selecting all the rows from g2_DescendentCountsMap and getting zero results back. I then deleted the db cache using Site Admin -> Maintenance, and then I deleted the entity, module, theme, and templates_c caches via /lib/support. Finally, I logged out of Gallery and looked at the total count on the main page.
Posts: 111
Let me tell you... it is one of the most tedious things in the world to go through 189 nested albums in G1, record the number of items (being certain to not mistakenly record the views count), and then compare it to the same nested 189 albums in G2, and subtracting the number of sub-albums an album contains from it's total count.
I hope I never have to do that again! ;-)
My problem was definitely with the permissions in about twenty of my nested albums. Fortunately, they were grouped into two clusters, so it was a relatively easy (and relieving) fix.
I did notice a quirk/anomoly that might be indicative of why this problem manifested itself in the first place, but I wasn't able to replicate it, so I'm not certain. When I tried to remove the "[core] View item" and "[core] View resized version(s)" permissions on one of the nested albums, I started with "[core] View resized version(s)" and after what seemed like approximately 20-30 seconds of waiting for the server to respond, I was redirected to [my domain]/main.php, but the page was all white and I didn't see any source code.
I can only guess that I reached either a time or memory limit in PHP and it quit abruptly. This did not happen again when I removed "[core] View item", or when I added those two permissions again. In all cases, I did not remove the (default) check in the box for applying the permissions modification to the sub-items.
Thank you for all your help, valiant. Although the process you had me go through didn't directly solve my problem, it helped me better understand the architecture of G2.
Posts: 32509
@time out:
if it redirected, it was finished with the task. don't know why it then showed a blank page.
however, we know that such massive operations should have a progress bar etc. there's much room for improvement in g2.