Unable to "Edit" activity/task directly from Opportunity

maverickws · 20 November 2023 13:48

When on an opportunity I am, while in my user, able to add an “Activity” to an Opportunity, under the Opportunity - Activities - Actions:

Create Task
Schedule Meeting
Log Call
Send Email

The description of an event where the issue is replicable:

Adding a “Log Call” action when in the Opportunity. I enter all the details and Save
Let’s say I forgot to change the call to “Held” and instead “Planned” got selected, so I need to edit it
I select “Edit” from the Opportunity/Activity Menu
Error: Access Denied
I leave this view and go to “Tasks”
I am able to edit the activity just fine.

pgr · 20 November 2023 13:50

This might be related to Security roles and security groups.

The quickest way to test this is to see if the Admin user gets access. If he does, and the problem only occurs for other users, then you know that you should be looking into security groups configuration.

If Admin also has the problem then it’s more likely a bug…

maverickws · 20 November 2023 13:54

Oh fun.

Was going to say that there are no security groups configured and assigned as of yet, but testingI also get access denied with the admin user.

pgr · 20 November 2023 19:20

If you haven’t created and edited Security Roles and groups, and this is happening by default (which it is, since I can reproduce it in my test system) I would say that this is a bug.

I see that this call is checking for a bean in a module called “activities”, when it should be “calls”:

github.com

salesagility/SuiteCRM-Core/blob/master/core/backend/Process/DataPersister/ProcessDataPersister.php#L174


      
                  if ($hasAccess === false) {
                      return false;
                  }
          
          
        if (empty($record) && empty($ids)) {
                      $hasAccess &= $this->acl->checkAccess($module, $action, true, 'module', true);
                      continue;
                  }
          
          
        if (!empty($record)) {
                      $hasAccess &= $this->acl->checkRecordAccess($module, $action, $record);
                      continue;
                  }
          
          
        if (!empty($ids)) {
                      $hasAccess &= $this->checkRecordsAccess($ids, $module, $action);
                  }
              }
          }
          
          
return $hasAccess;

I’ll have a look tomorrow to see if I can fix it

pgr · 20 November 2023 19:34

If you want you can try this simple fix, tell me if it worked and I can create a PR

→ Comparing salesagility:hotfix...pgorod:patch-1 · salesagility/SuiteCRM-Core · GitHub

maverickws · 22 November 2023 10:02

@pgr thank you, sorry I wasn’t around yesterday will apply this today and let you know.

maverickws · 22 November 2023 10:32

@pgr the fix works great so far. Great job, thanks! You may open a PR!

pgr · 24 November 2023 16:19

For reference:

Issue: Access denied editing records from aggregated subpanels (Activities, History) · Issue #401 · salesagility/SuiteCRM-Core · GitHub

PR: Fix #401 ACL Check recordModule instead of Module, if available by pgorod · Pull Request #402 · salesagility/SuiteCRM-Core · GitHub

pgr · 22 January 2024 13:26

The fix was merged today and will likely be part of the upcoming 8.5.1. release.