CiviCRM Community Forums (archive)

what edit screen r u referring to?

is it edit contact?

lobo

hey dschafer:

can u try applying this patch:

svn diff CRM/Contact/Form/Contact.php
Index: CRM/Contact/Form/Contact.php
===================================================================
--- CRM/Contact/Form/Contact.php        (revision 27173)
+++ CRM/Contact/Form/Contact.php        (working copy)
@@ -178,7 +178,9 @@
                 
                 // check for permissions
                 require_once 'CRM/Contact/BAO/Contact/Permission.php';
-                if ( ! CRM_Contact_BAO_Contact_Permission::allow( $this->_contactId, CRM_Core_Permission::EDIT ) ) {
+                $session =& CRM_Core_Session::singleton( );
+                if ( $session->get( 'userID' ) != $this->_contactId ||
+                     ! CRM_Contact_BAO_Contact_Permission::allow( $this->_contactId, CRM_Core_Permission::EDIT ) ) {
                     CRM_Core_Error::statusBounce( ts('You do not have the necessary permission to edit this contact.') );
                 }

and see if it works

thanx

lobo

Did some additional digging.

Some background.
drupal_access_denied() appears to be encapsulated in utils/system/durpal/drupal.php  permissionedDenied()

It looks like in invoke.php there is some type of check to see it the user has access to the particular menu associated with the page.

If the user does not have access the permissionDenied() function is invoked.

Does this imply that the user needs access to the Contact menu as well?

I checked and the user can see the contacts menu.  The code in invoke.php is
v3.0.3  line 128
            // check that we are permissioned to access this page
            if ( ! CRM_Core_Permission::checkMenuItem( $item ) ) {
                CRM_Utils_System::permissionDenied( );
                return;
            }

Did some additional digging.

There appears to be a dependent relationship between the menu permissions and the level of access.

It appears that CRM_Core_Permission::checkMenuItem( $item ) is checking whether the user has the permission to access the menu option associated with the page.

Here is the $item object that is interrogated to determine the permissions. It seems it is being treated the same as "New Contact"
Array
(
    [id] => 93
    [domain_id] => 1
    [path] => civicrm/contact/add
    [title] => New Contact
    [access_callback] => Array
        (
            [0] => CRM_Core_Permission
            [1] => checkMenu
        )

    [access_arguments] => Array
        (
            [0] => Array
                (
                    [0] => access CiviCRM
                    [1] => add contacts
                )

            [1] => and
        )

    [page_callback] => CRM_Contact_Form_Contact
    [page_arguments] => addSequence=1
    [breadcrumb] => Array
        (
            [0] => Array
                (
                    [title] => CiviCRM
                    [url] => /civicrm?reset=1
                )

        )

    [is_ssl] => 0
    [weight] => 1
    [type] => 1
    [page_type] => 0
)
The way we have things setup only certain roles have the "edit all contacts" permission. Users that do not have this do not even see the Contacts menu, the idea is to lock them into their own record.  Our individual user has only "Access CiviCRM" so I believe that access is denied because they do not also have "add contacts"

It would be ok to enable the "edit all contacts" permission for these uses if we could suppress access to the Contacts menu.

Although as I read it, in order to access the contacts page for add/edit page you must have permission to the menu item associated with the page.

Hope this is helpful.

-- Dave

Hi,
Just following up.
Adding 'add contact' permssion resovled the issue for the contacts accessing their own record.

We added a form hook to essential only allow access to their own contact record and any contact records that were permissioned via relationship.

Thanks for your help.