collectiveaccess
commented
4 months ago Thanks for catching this. There's a helper function, caConvertBundleNameToCode, in utilityHelpers for this sort of thing. It should have been added in getBundleAccessLevel(). I have just pushed a change to implement this. Can you let me know if it works ok for you?
amergelCGI
@collectiveaccess This Bug fix solves the problem I encountered while trying to save a change to a metadata field of one of our objects using a user account with sufficient permission (read & write / access level _CA_BUNDLE_ACCESSEDIT).
When Saving, the change was not taken into account, and when debugging I found out that the bundle access level was not properly interpreted. For our metadata bundle named "material_technique", the method getBundleAccessLevel() only checked the access level for bundle names "ca_attribute_material_technique" & "ca_attribute_ca_attribute_material_technique" (prefix caattribute repeated 2 times!) (ca_users.php lines 3532 to 3534 & lines 3537 to 3542) which resulted in not finding any access level while it did not check the access level for the bundle name "material_technique" without caattribute prefix.
However in CA 2.0, RolesController.php was modified so that the access level of bundles are no longer saved with the caattribute prefix (see preg_replace("!^caattribute!", "", $vs_bundle_name) in RolesController.php line 172)
That why I also introduced a preg_replace to remove any caattribute prefix from the bundle name before checking the access level and it solved the issue. With this fix, getBundleAccessLevel() checked the access level for bundles names "material_technique" and "ca_attribute_material_technique", with the first check returning the right result.