Piwigo bug tracker has moved to Github
This bugtracker is kept to provide history on old issues.
Anonymous | Login | Signup for a new account | 2018.04.25 18:16 CEST | ![]() |
My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000937 | Piwigo | albums | public | 2009.03.10 13:58 | 2011.02.24 12:30 | ||||
Reporter | tiico | ||||||||
Assigned To | plg | ||||||||
Priority | normal | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | OS | OS Version | |||||||
Product Version | 2.0.0 | ||||||||
Target Version | 2.2.0RC1 | Fixed in Version | 2.2.0RC1 | ||||||
Summary | 0000937: Image level not used in thumbmail associated category | ||||||||
Description | Thumbmail 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 Reproduce | Create 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. | ||||||||
Tags | No tags attached. | ||||||||
browser | Mozilla | ||||||||
Database engine and version | MySQL: 5.0.67 | ||||||||
PHP version | PHP: 5.1.3RC4-dev | ||||||||
Web server | Apache 1.3.x | ||||||||
Attached Files | |||||||||
![]() |
|
(0003765) 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. |
(0003834) 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. |
(0003835) 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 :-/ |
(0004678) 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; |
(0004681) 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. |
(0004682) 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? |
(0004683) 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. |
(0004684) 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. |
(0004685) rvelices (developer) 2011.01.20 21:33 |
ok. let me see how i feel a week from now... maybe i'll love it |
(0004686) 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. |
(0004845) 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. |
![]() |
|||
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 - 2018 MantisBT Team Contact |