Piwigo Bugtracker

Piwigo bug tracker has moved to Github

This bugtracker is kept to provide history on old issues.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000937Piwigoalbumspublic2009.03.10 13:582011.02.24 12:30
Assigned Toplg 
PlatformOSOS Version
Product Version2.0.0 
Target Version2.2.0RC1Fixed in Version2.2.0RC1 
Summary0000937: Image level not used in thumbmail associated category
DescriptionThumbmail associated to a category didn't take the level information. A user with lower level could see a "bad" representant of a category (image that he coul'nd see into the category)
Steps To ReproduceCreate 1 category with 2 images :
img1 --> level 4
img2 --> level 0
Create 1 user with level 0.

In admin, associate the img1 to the category.
Connect with the user with level 0.
Look at the thumbmail of the category : img1
Go into the category : only the img0 is present.
TagsNo tags attached.
Database engine and versionMySQL: 5.0.67
PHP versionPHP: 5.1.3RC4-dev
Web serverApache 1.3.x
Attached Files

- Relationships
has duplicate 0001125closedplg Photo visible with a higher privacy level 

-  Notes
plg (manager)
2010.04.14 17:51

That's OK to hide img1 only if img1 was not explicitely chosen as category representative photo => the category must have a random representative photo.
plg (manager)
2010.05.04 21:07

In fact, it works fine if you have $conf['allow_random_representative'] = true;
and not fixed a representative photo for a given category. But this is a very uncommon situation, simpy because by default $conf['allow_random_representative'] = false; (to reduce CPU load).

I investigate on what can be done (without too many damages on CPU load) when the representative photo is defined. The problem is that it can be defined by user explicitely or automatically when adding photos.

To avoid high CPU load (many queries), it would be better to have {category_id, privacy_level, representative_picture_id} and the corresponding user interface, but it's quite a huge job and certainly confusing for the vast majority of users.
plg (manager)
2010.05.04 22:19

Another solution is to add a column "representative_picture_id" in the user_cache_categories table and fill it only when needed, so that for a given category and a given user the representative photo must be found only once (as long as there is no user cache reset).

Adding this for Piwigo 2.1 is a bit too late, unfortunately :-/ 2.1.0RC3 is already available, and we're not supposed to modify the data model. And without modifying the data model, I don't know how to solve this problem efficiently.

I have to postpone to Piwigo 2.2 :-/
svn (reporter)
2011.01.20 14:32

[Subversion] r8802 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
bug 937 fixed: makes sure a user won't see the thumbnail of a photo that has a
higher privacy level than user privacy level.

For an acceptable solution at performance level, I have implemented a cache:
for a given user, each album has a representative_picture_id. This cache also
avoids to perform numerous "order by rand()" SQL queries which is the case
when $conf['allow_random_representative'] = true;
rvelices (developer)
2011.01.20 16:28

I have an issue with this commit for my config:
- $conf[allow_random_representative']=false
- some specific categories do not have representant because I want to search a representant of sub categories.

Now with this change, you will save once an id in user_repres* and that's it.
plg (manager)
2011.01.20 17:12

> Now with this change, you will save once an id in user_repres*
> and that's it.

Yes I know, this is the expected behavior. We lose a bit of randomness but it avoids numerous and heavy SQL requests.

Do you suggest another way to solve this problem?
plg (manager)
2011.01.20 17:21

We could not use the cache at all, but it is a nightmare at performance level in my opinion.

We could only store the user_repres* if the found repres* level is higher than user.level but if the user is in this situation once, he loses the randomness for futur page refresh.
plg (manager)
2011.01.20 21:13
edited on: 2011.01.20 21:19

I propose to keep this bug fixed (the bug itself is fixed) so that it appears as fixed for 2.2.0RC1. Please open a forum topic to discuss about the problem of the cache and the loss of randomness, we can change the algorithm for 2.2.0RC2 if we find a better solution.

rvelices (developer)
2011.01.20 21:33

ok. let me see how i feel a week from now... maybe i'll love it
plg (manager)
2011.01.20 21:35

You'll love the speed if you $conf['show_gt'] = true + $conf['show_queries'] = true

But I agree that randomness was pleasant.
svn (reporter)
2011.02.24 12:30

[Subversion] r9365 by plg on trunk

-----[Subversion commit log]----------------------------------------------------
bug 937: problem on empty albums (visible for admins) with a representative_picture_id defined.

- Issue History
Date Modified Username Field Change
2009.03.10 13:58 tiico New Issue
2009.03.10 13:58 tiico browser => Mozilla
2009.03.10 13:58 tiico MySQL version => MySQL: 5.0.67
2009.03.10 13:58 tiico PHP version => PHP: 5.1.3RC4-dev
2009.03.10 13:58 tiico Web server => Apache 1.3.x
2009.06.18 22:51 plg Assigned To => plg
2009.06.18 22:51 plg Status new => assigned
2009.06.18 22:51 plg Target Version => 2.0.3
2010.04.14 17:51 plg Note Added: 0003765
2010.04.14 17:51 plg Target Version 2.0.3 => 2.1.0RC3
2010.04.27 01:08 plg Target Version 2.1.0RC3 => 2.1.0
2010.05.04 21:07 plg Note Added: 0003834
2010.05.04 22:19 plg Note Added: 0003835
2010.05.04 22:21 plg Target Version 2.1.0 => 2.2
2011.01.18 15:52 plg Target Version 2.2.0RC1 => 2.2.0RC2
2011.01.20 14:32 svn Checkin
2011.01.20 14:32 svn Note Added: 0004678
2011.01.20 14:33 plg Status assigned => closed
2011.01.20 14:33 plg Resolution open => fixed
2011.01.20 14:33 plg Fixed in Version => 2.2.0RC1
2011.01.20 14:33 plg Target Version 2.2.0RC2 => 2.2.0RC1
2011.01.20 16:28 rvelices Note Added: 0004681
2011.01.20 16:28 rvelices Status closed => feedback
2011.01.20 16:28 rvelices Resolution fixed => reopened
2011.01.20 17:12 plg Note Added: 0004682
2011.01.20 17:21 plg Note Added: 0004683
2011.01.20 21:13 plg Note Added: 0004684
2011.01.20 21:19 plg Note Edited: 0004684
2011.01.20 21:33 rvelices Note Added: 0004685
2011.01.20 21:33 rvelices Status feedback => closed
2011.01.20 21:33 rvelices Resolution reopened => fixed
2011.01.20 21:35 plg Note Added: 0004686
2011.02.24 12:30 svn Checkin
2011.02.24 12:30 svn Note Added: 0004845
2011.05.02 15:40 plg Relationship added has duplicate 0001125

Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker