Are the status of those problematic sub albums, clearly written as public in the databse or that's the permissions which don't follow?
Offline
I have encountered both problems. sometimes we have "private album / public sub-album" sometimes we have "private album / private sub-album" but user X can access sub-album and not the album.
I think the problem is when you move an album, I mean when you change the parent album.
Offline
One possible bug in move_categories
$subcats = get_subcat_ids(array($cat_id)); foreach ($tables as $table => $field) { $query = ' SELECT '.$field.' FROM '.$table.' WHERE cat_id = '.$cat_id.' ;'; $category_access = array_from_query($query, $field); $query = ' SELECT '.$field.' FROM '.$table.' WHERE cat_id = '.$new_parent.' ;'; $parent_access = array_from_query($query, $field); $to_delete = array_diff($category_access, $parent_access);
The problem is when moving an album with children we don't look for all children accesses.
- the first query that generate category_access should be WHERE cat_id IN $subcats
- also there is no reason to make these changes in the foreach ($categories as $cat_id => $category) loop. we should loop $categories, build a unique list of all $subcats and work with those ...
Offline
Thx
I'm reviewing the code and don't see what's wrong here since nothing changed for the implied functions. move_categories is called then set_cat_status then an array_diff
the only chnage comes in create_virtual_category
ps after rvelices: weird that old code bug
Last edited by flop25 (2014-03-11 11:42:58)
Offline
Also same issue in category permissions
Suppose I put an album as private without any permission. Children are not checked for existing permissions.
Offline
plg wrote:
Petter, with PhpMyAdmin execute this query:
Code:
update piwigo_user_cache ser forbidden_categories='35,126,134,139,141,147,168,169,175,176,178,184,190,195,215,7,31,41,56,112,200,236,240,241,242' where user_id=2;Then log in, go to admin, install/activate [extension by rvelices] RV DB Integrity and perform action "check database integrity" on [Administration > Tools > Maintenance] and tell us the result.
Hi, some thing is wrong with the syntax:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'forbidden_categories='35,126,134,139,141,147,168,169,175,176,178,184,190,195,215' at line 1
I'm sure i did it right, but....
Offline
it's "set" and not "ser"
(I updated plg message)
Offline
Hi, sql worked. (We love you all!!) Plugin is installed, and here is the output.
I guess the problem is with album 41 and 112, these are albums we have in a private area, just for the closest family members, not public.
What do i need to change?
Output:
Test Result
#piwigo_images.id (7 references) 2 FAILED
1 error references; #piwigo_image_category.image_id referring to #piwigo_images.id
Offending image_id 2287
1 error references; #piwigo_image_tag.image_id referring to #piwigo_images.id
Offending image_id 5552
#piwigo_categories.id (7 references) 1 FAILED
1 error references; #piwigo_user_cache_categories.cat_id referring to #piwigo_categories.id
Offending cat_id 0
#piwigo_tags.id (1 references) 1 FAILED
1 error references; #piwigo_image_tag.tag_id referring to #piwigo_tags.id
Offending tag_id 0
#piwigo_groups.id (2 references) Passed
Pemalinks (1 references) Passed
Album status/visibility (1 references) Passed
Permissions (1 references) 2 FAILED
Album 41 Silje og venner too many users permissions 2
Album 112 Stians 17 års dag, 25.desember 2011 too many users permissions 2
#images(id,storage_category_id) in #image_category (1 references) Passed
Offline
Hi, i found the reason to the error. User Guest was in the allowed users of a private album. Deleted the Guest, and the error is gone.
Now the output looks like this:
Test Result
#piwigo_images.id (7 references) 2 FAILED
1 error references; #piwigo_image_category.image_id referring to #piwigo_images.id
Offending image_id 2287
1 error references; #piwigo_image_tag.image_id referring to #piwigo_images.id
Offending image_id 5552
#piwigo_categories.id (7 references) Passed
#piwigo_tags.id (1 references) 1 FAILED
1 error references; #piwigo_image_tag.tag_id referring to #piwigo_tags.id
Offending tag_id 0
#piwigo_groups.id (2 references) Passed
Pemalinks (1 references) Passed
Album status/visibility (1 references) Passed
Permissions (1 references) Passed
#images(id,storage_category_id) in #image_category (1 references) Passed
Offline
So those albums were public before?
Offline
No, they've probably been so for a long time. Is it possible that the latest version allows fewer such errors?
Do I need to do something with the other "errors" that failed on the test?
Offline
I have been testing moving a public album into a private album. On Piwigo 2.4, 2.5 and 2.6. Each time the moved album became private, as expected. The Piwigo that had this problem was created on version 2.4 (then upgraded to 2.5 then 2.6). I don't understand how the sub-album can be public in a private album.
The permission issue makes me think about [Bugtracker] ticket 2977 : my current state of mind is that the problem is Piwigo doesn't remove permissions when album becomes public. It should avoid this kind of problem later.
Offline
The incoherences are not new. They may have been generated a long time ago. The difference now is that Piwigo 2.6 crashes when this kind of incoherence occurs.
Of course we have to find a way to avoid incoherences but we should also make Piwigo 2.6 more tolerant to avoid crash.
Offline
Thanks guys, I let things remain the way it does now, and hope that the other error messages will not be critical in the future.
Again, many thanks for the incredible good help!!
Offline
Offline