Permissions migration from G2; finding and adapting
mikeage
Joined: 2005-01-23
Posts: 138 |
Posted: Tue, 2013-01-01 19:45 |
I'm finally migrating my Gallery2 to a Gallery3 instance (after no less than 5 previous evaluations, since at least 2008 when I wrote a patch to make NGINX integration easiler ;) ), and I'm trying to make sure none of my permissions are lost. Obviously, the G3 permissions model is much simpler, and does not support per-item permissions. However, I obviously don't want to expose images that I was previously hiding. (1) Is there an alternative? I saw the hide module (http://codex.gallery2.org/Gallery3:Modules:hide), but it seems that this is a UI only implementation, and doesn't hide the image from direct access, or display via tags browsing or thumbnav (http://codex.gallery2.org/Gallery3:Modules:thumbnav). Is there anything else that might help? (2) If not, I assume the best thing to do is to move all the images into a subfolder and hide that. I want to make sure I don't miss any; is there an easy way to query G2 and find all items with non-default permissions? (I don't mind a DB query that will return an ID; I can work with that to create a list and then check each image manually, but I have ~13000 images, of which only about 20 are hidden; I can't look through all 13K!) Alternatively, is there any way to check in G3 which images were imported with a different permission model (I already ran the import, and it took about 15 hours, so adapting the g2_import module is probably not a feasible solution). Thanks in advance. |
|
Posts: 8339
Your G2 database would have a HiddenItemsMap
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 138
Thanks.
I think you may have been referring to g2_ItemHiddenMap, but that worked for the images that were actually "hidden".
For those that had permissions changed, I used the following query to return all items that did not the "[core] View item" permission set for "Everybody":
SELECT g_id, g_title FROM g2_Item, g2_AccessSubscriberMap WHERE g2_Item.g_id = g2_AccessSubscriberMap.g_itemId AND g_accessListId NOT IN (SELECT g_accessListId FROM g2_AccessMap WHERE g_userOrGroupId = 4 AND g_permission & 1)
[or a slightly more useful query:
SELECT orig.g_id, orig.g_title, parent.g_title FROM g2_Item as orig, g2_Item as parent, g2_ChildEntity, g2_AccessSubscriberMap WHERE orig.g_id = g2_ChildEntity.g_id and g2_ChildEntity.g_parentId = parent.g_id AND orig.g_id = g2_AccessSubscriberMap.g_itemId AND g_accessListId NOT IN (SELECT g_accessListId FROM g2_AccessMap WHERE g_userOrGroupId = 4 AND g_permission & 1) ORDER BY parent.g_title,orig.g_title;
]
While looking for this, I spent some time manually viewing g2_AccessSubscriberMap and g2_AccessMap; having seen the number of unique rows in g2_AccessMap, it was clear that while the G2 permission model was excellent in terms of flexibility, it certainly resulted in a lot of nearly identical but slightly different permission sets over the years...