Adding a product type doesnt allow me to change/add fields

Hmm, I'm not experiencing this behavior. I just added a new product type called Test and it immediately had the links available:

Are you using any modules besides the core Commerce modules? And what version of Drupal are you using? Any contribs that might interfere with a cache reset?

In fact, based on #1190404: Notice: Undefined index: instance in insert_form_field_ui_field_edit_form_alter, I'm wondering if you get the same problem if you disable the Insert module. I don't know why that would interfere with this, but you never know.

I'm still not getting any problems here, and I'm not really sure what would cause the lag. If you can narrow it down, feel free to reopen this issue with steps to reproduce.

I have the same issue. Clearing the cache twice helped.

I have the following modules enabled, in case that helps to reproduce:
commerce_features, devel, features, filefield_paths, i18n, i18nviews, l10n_client, l10n_update, references, taxonomy_menu, token, transliteration, variable, vbo, admin_menu and the modules coming with commerce_kickstart.

Nothing in there seems fishy to me. Let's close this again until we can provide steps to reproduce the error on a clean install with the latest dev code, no extra modules enabled. Only then would we be able to isolate it to a bug in the Commerce modules.

I have the same issue with Commerce 1.2 and 1.x (27-jan-2012) on Drupal 7.10: the last product type in the list only allows edit / delete, the fields cannot be managed.

It seems to be a permissions caching issue: if I create a Product Book and a Product Toys, I can open (as admin) the page ../commerce/products/types/product-books/fields, but product-toys/fields gives me "Access denied, you are not authorized to access this page".

If I look on admin/people/permissions, admin hasn't got any permission on neither Product Book nor Product Toys (but admin has all permissions on the "* any product type")

Lots of modules enabled (including i18n, devel ...), so I'll have to reinstall it with a lot less modules to figure out what causes this problem.

Ok, tested it with latest Commerce (git) on Drupal 7.10, PostgreSQL 9, no special caching enabled in the Performance section of Drupal.

I can enable a bunch of modules (commerce extras, views, variable, entity, search api etc etc, I've attached a PDF-print of the Modules page just to be complete) without any problem, but it seems to be related to i18n.

More specifically with the Field translation API (v1.3) module: enabling this module (+ clearing cache and creating a new Product Type) triggers the behavior, even when there is no additional language installed and no translation options are set on the Product type (or any other content for that matter).
Disabling Field translation (and clearing Drupal's caches) and adding a new Product Type works as expected again.

I can confirm this issue - clearing caches helps. I'll try to isolate it over the coming days.

Possible solutions to try, in case it is a cache clear problem:

1) Update Drupal to 7.12, it has a related fix.
2) Open commerce_product.module, find the function commerce_product_types_reset() (around line 370), at the end of it add "entity_info_cache_clear()" so that it looks like this:

function commerce_product_types_reset() {
  $product_types = &drupal_static('commerce_product_types');
  $product_types = NULL;
  entity_info_cache_clear();
}

What I'm curious about is why Field Translation causes it (and how that's even possible).

Hmz, still the same issue in Drupal 7.12 with i18n Field Translation 1.4.

However, the second suggestion (adding entity_info_cache_clear) does the trick.

This seems like a commerce bug unrelated to Field Translation (enabling that module just triggers the bug).

When creating a new product type (bundle), commerce_product_ui_product_type_save() calls commerce_product_types_reset(). However, some modules rely on entity & bundle information as returned by entity_get_info().

With Field Translation enabled, the newly created product bundle is missing from entity_get_info(), and field_ui_menu() and i18n_field_menu() will not generate menu paths for fields management (Without Field Translation, a call to entity_get_info() will include the newly created bundle). Erroneously, commerce_product_ui_menu_alter() tries to alter the field management paths (by adding a ['context'] attribute to the non-existing paths, resulting in an almost empty menu item with access callback "0", which I think is causing the access denied issues reported here (the missing operations are caused by "access: FALSE" for the menu router item).

While I haven't been able to proof this, my guess is that this bug is caused by Field Translation calling entity_get_info() before the product type is added, thus caching the entity information. Once commerce creates a new product, it does not clear the entity cache, and there now is a discrepancy between information returned from commerce_product_types() and the stale cached result from entity_get_info() used to build the field management links.

This also explains why …

• clearing the cache
• rebuilding the menu
• adding another product type

… fixes this issue: in each of these cases, the entity cache is fresh (since it's a new request), entity_get_info() returns with the new bundle, and the *_menu() and *_menu_alter() implementations have all the information to build the field management paths.

In any case, it seems to me clearing the entity cache as explained in #10 is the right thing to do when adding or removing a product type. Is there any reason we should not call entity_cache_clear_info() at that time?

When in doubt, clear cache.

Test bot likes it. bojanz likes it. I like it. Best of all - it works!

Thanks for tracking that down, Ivo. I'm betting there are other areas where we could use this, like in the Commerce Customizable Products module where we add new line item bundles. I'll have to check it out in a follow-up there. : )

Actually, nothing to do there. I just added the same entity info cache clear to commerce_line_item_types_reset(). I also added in a commerce_customer_profile_types_reset() function with coordinating code for customer profile types. Payment transactions and Orders don't really support bundles or have a real API for supporting new bundles at the moment, so no worries there.

Hey guys opening the issue again. The problem is still persisting. Checked all the above mentioned ideas but it is not working. pls help.

the problem gets solved at night and gets again in the morning IST

Clear your cache and the menu items will appear. See comments #12 / 13.

I'm seeing the same problem shown in the screenshot in #17. I have tried clearing the cache via the performance page, drush cc all, creating and deleting new product types, saving changes to other product types, etc.

I rebuilt the menu as explained here: http://drupal.stackexchange.com/questions/58618/how-do-i-call-the-menu-r...

I have also done drush dev 'entity_cache_clear_info();'

No matter what I do, I can't create a fifth product type because the Manage Fields and Manage Display links don't appear, and if I try to visit the URLs where these pages would normally appear, I get access denied.

I don't run into this in all my sites and I assume this would not happen in a fresh install since not many people are reporting it.

I'd be fine with a brute force solution, if there is one.

Running cron fixed this. Initially cron wouldn't run and I was getting "attempting to re-run cron" errors. I had to restart cron via the command line and then run cron at admin/config/system/cron, which took an incredibly long time. Server having a bad day.

I also ran into this in the 2x branch of userpoints, so this does not appear to be commerce-specific. When userpoints is installed, the Transaction Types tab sometimes does not appear initially at admin/config/people/userpoints. Repeatedly clearing the cache, running cron, and re-installing userpoints eventually made the tab appear. In any case, it seems unlikely this is a commerce bug, and I doubt it would be possible to repro this on a fresh install. I won't even try. In my case it may be due to problems in other contributed or custom modules that define entities. I am seeing this in sites that have a lot of custom and contributed modules installed. This should probably be tagged with some project besides Drupal Commerce but I'm not sure which project.

I think the best possible solution would be to search the core issue queue for pertinent issues. If it transcends any one module, it's likely a core issue or else an issue with some contributed module both projects depend on (Views menu items perhaps?). If you can't find an existing issue, I'd start a new one, as the issues you're reporting aren't really related to the original post here which has already been patched in Commerce.