[Fixed v1.5.1] Product types Admin Access

Apologies if this has been addressed elsewhere. I have had a look and can't find it.

Do product types work with admin profiles?

Here's what I did.

1. Create a custom product type as normal.
2. Realise that a user other than superuser can't edit that product type because product_custom.php is no registered as an admin page.
3. So, I thought I'd just make an admin page for it ( as there is one for product.php)
4. That was fine.
5. But when I try and check/uncheck it in an admin profile it has no effect.
6. When I enter the row into the admin_pages_to_profiles table then the user can use the custom product. So it all works fine except the checking and uncheckng of that particular page but relies on putting the row in by hand.

However, I went back and see that the same thing happens if I use, for example, product_music.

Once again is there something I am missing?

This may be what you're looking for:

http://www.zen-cart.com/forum/showthread.php?t=190594

Thanks -- but that is a different issue. Which I know about now that Dr Byte enlightened me :- ) And that fix is already in place on the install that I am working on.

The issue in that thread results in a return to the main page of admin. This results in a 'you do not have .....' error.

This has to do with product types rather than registered admin pages.

Basically the question is what the correct method of registering a page for a custom product type is. My way is to create a separate admin page for this custom product type. Is that the best way of doing it? And if so why I am I still seeing strangeness with the checkboxes even with that fix in place.

The next question is whether, for instance, product_music works out of the box. By which I mean whether one can edit a product_music type product in a profile other than superuser in a default install.

In my case I do not seem to be able to which is somewhat strange. But I have not tried this on a completely clean install yet. So....

OK. Regarding the second issue.

On a clean install:

1. create a second admin profile and call it 'profile 2'

2. create a new user and add them to profile 2

3. log out

4. log in as the new user

That user cannot edit Product-Music type products. Or in fact any products that are not Product-General.

Okay okay.. I admit it.. I'm stalking you niccol!!:laugh::laugh: J/K..

I have nothing to add only that I'll be following this as I have a membership management and event modules which use custom product types too, and I need to convert these mods to v1.5 too..

@Diva

:smile:

Perhaps you can say if you are seeing the same behaviour?

niccol:

@Diva

:smile:

Perhaps you can say if you are seeing the same behaviour?
No where NEAR installing these on v1.5 to say what behavior I see yet.. Still going through the painstaking process of comparing the core files to v1.5 to make sure that I merge in all the changes.. Your post caught my eye because my mods have custom product types.. I am assuming that since you are seeing this behavior, that I will see the same as you since both of my mods use custom product types.Of course if I get to the point where I have something more substantive to say on the matter, I will indeed share..:smile:

well, I am supposing that the correct thing to do with custom product types is to create an admin page for them. but to be honest this seems a bit odd.

And that lead me to experiment with the default product types and I had issues there too. So, I think there is something amiss and I will wait to hear from Kuroi or Dr. Byte probably.

What you could do though is just try :

On a cleanish install:

1. create a second admin profile and call it 'profile 2'

2. create a new user and add them to profile 2

3. log out

4. log in as the new user

5. see if the new user can edit or create product music type products.

that would at least prove that what I am seeing is not my madness.

That I can totally do!!!:smile: Will let you know what I discover..

OK.

well I think that this is definitely a bug.

If I write a change to the security function check_page() then it works the way I think it should ( almost ).

Basically, I have a query that returns all the product type handlers. Then if the variable $page is in that array I change the variable $page to 'product'. So, a 'product_music' page is verified by check_page() as if it was a 'product' page.

Which means that if someone has access to editing one product type then they have access to editing them all. Which is a stop-gap solution for me. I am not really keen to post that code as messing around with core security functions doesn't strike me as a stroke of genius. But it does show me that what I believe is true. At the moment the current admin access functions do not deal with product types at all.

Moving this thread to the Bug Reports section so it can be investigated further at a later date.
No ETA at this time.

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

  } 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

It just means that if a user has access to editing products then they have access to edit any product type.

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..

@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.

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..:blush: (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..:smartalec:

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..

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:

 define('FILENAME_PRODUCT_MUSIC', 'product_music');

2. Edit admin/includes/languages/english/extra_definitions/product_music.php by adding the following definition:

define('BOX_CATALOG_PRODUCT_MUSIC', 'Product Music');

3. Back up your database and then run the following sql using your database manager (phpMyAdmin).

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');

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.

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

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.

badarac:

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.
Different problem.. requires a different solution.. the issue being discussed here is custom product_types..