Moving this thread to the Bug Reports section so it can be investigated further at a later date.
No ETA at this time.
Moving this thread to the Bug Reports section so it can be investigated further at a later date.
No ETA at this time.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Well if anyone else is struggling with this here is my solution. I really can't see any security risk in this but treat it with caution because you are editing one of the main files in the new admin page security set up : admin/functions/admin_access.php
It just means that if a user has access to editing products then they have access to edit any product type.Code:} else { $page_params = ''; } // NICCOL FIX $sql = "SELECT type_handler FROM ".TABLE_PRODUCT_TYPES; $p_types = $db->Execute($sql); while(!$p_types->EOF) { $pt[] = $p_types->fields['type_handler']; $p_types->MoveNext(); } if(in_array($page,$pt)) $page = 'product'; // EOF NICCOL FIX $sql = "SELECT ap.main_page, ap.page_params
Nick
iszent.com
Thanks niccol.. I need to make this change for my events/membership management mods.. They make use of custom product types..
hideCategories which I have been working on an update for has an option file which uses a different product type to prevent folks from browsing through the hidden products.. I am not sure if I can submit it with this change though.. Hmmmmmmm..
My Site - Zen Cart & WordPress integration specialist
I don't answer support questions via PM. Post add-on support questions in the support thread. The question & the answer will benefit others with similar issues.
@diva
Well, I guess I wouldn't submit a mod that alters this particular file. You are right. But this fix is just intended as a stop-gap. It would be nice to separate out the product types so that they could have different access levels. But that involves a whole raft of extra changes.
The devs will get to it when they can, I am sure, and hopefully this will keep people from banging their heads until then. I like using custom product types a lot so it is important to me but I guess most users do not stray far from product_general, or only have one access level anyway.
Nick
iszent.com
My events and membership modules rely on custom product types as we treat paid events and memberships as being different from product_general.
For hideCategories using product types was the simplest way to provide a solution to prevent customers from browsing through hidden categories and potentially seeing other hidden products.. (we remove all the navigation elements, the "Customers Who Purchased", and anything else other than JUST the product information from the product page) I have clients who use hideCategories for custom products, and they do not want their customers seeing other client's custom products.. So using a product type other than product_general was the way to go..
Though truthfully for hideCategories I just hijacked the product_document product type.. (at the suggestion of another Zenner) and you are right most folks don't seem to stray too far from the product_general product type.. So this was a totally doable solution since a lot of folks don't use (or know it exists) product_document.. So it's been re-purposed..
I won't submit the updated version until I can get a sense that including this change won't cause the admins to reject hideCategories..
Last edited by DivaVocals; 13 Feb 2012 at 07:32 PM.
My Site - Zen Cart & WordPress integration specialist
I don't answer support questions via PM. Post add-on support questions in the support thread. The question & the answer will benefit others with similar issues.
I think the original issue raised in this thread was to do with access being denied in admin>catalog>categories/products to non superusers to create/edit products of custom product types. I found that I was having the same problem with the music product type which is a (sort of) core product type.
I tried the code change suggested by Niccol above but this did not work for me.
I have found a solution which I think gets to the root of the problem which is that the 'product_music' page is not registered as a valid Admin page. I upgraded from v1.39 to v1.5 so I'm not sure whether this is just an issue with upgrading or whether a clean new install will have the same issue.
This solution allows control of access to manage products by type via admin profiles. Although described for the music product type it should also work when applied to properly configured custom product types.
There are three steps to the solution:
1. Edit admin/include/extra_datafiles/music_type_filenames.php by adding the following definition:
2. Edit admin/includes/languages/english/extra_definitions/product_music.php by adding the following definition:Code:define('FILENAME_PRODUCT_MUSIC', 'product_music');
3. Back up your database and then run the following sql using your database manager (phpMyAdmin).Code:define('BOX_CATALOG_PRODUCT_MUSIC', 'Product Music');
Once you have completed these three steps go to Admin Access Management>Admin Profiles and click 'Edit' on one of your custom profiles. You should now see a tickbox labelled 'Product Music' in the 'Catalog' section which can be ticked or unticked to allow or deny access as required.Code:INSERT INTO `admin_pages` (`page_key`, `language_key`, `main_page`, `page_params`, `menu_key`, `display_on_menu`, `sort_order`) VALUES ('product_music', 'BOX_CATALOG_PRODUCT_MUSIC', 'FILENAME_PRODUCT_MUSIC', '', 'catalog', 'N', '18');
If you have a custom product type you need to ensure that files containing the appropriate 'filename' and 'box' definitions are placed in the appropriate folders and that you add an appropriate record to the admin_pages table.
Hope this helps.
Alan
Hi Alan,
Thanks for this solution. I notice nobody came back with a thanks, and I've just stumbled upon the thread after experiencing the same issue. Followed your steps and it works perfectly.
Cheers.
Fixed in v1.5.1
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
I'm having a similar problem with Diva's Super Orders V4. I installed it on my customers 1.5 system and it works fine for the superuser profile. I created a second admin profile and checked the boxes for batch form print and batch status update. They can access the menus but when they actually try and print or update they get the authorization message
"Sorry, your security clearance does not allow you to access this resource.
Please contact your site administrator if you believe this to be incorrect.
Sorry for any inconvenience."
Seems like it's a related issue.
My Site - Zen Cart & WordPress integration specialist
I don't answer support questions via PM. Post add-on support questions in the support thread. The question & the answer will benefit others with similar issues.
Bookmarks