@nicholash thanks for reporting the issue. I don't know you but are you in a position to provide a fix? As you probably know CiviCRM is open source and maintained by a community of dedicated and enthusiastic volunteers

Hi, sorry I don't thing I can help with the fix. I took a quick look but was not able to make heads or tails of it.

Okay. No problem.

I also forgot to mention but I tried to test the issue on https://d10-master.demo.civicrm.org/ but the demo user did not have the permission to close batches and I don't think that is something I could change.

Flagging as a regression as we have a site which cannot close batches on 5.78.4 as well. I haven't investigated that site but assuming it is the same issue.

I just got confirmation that it was working before we ran the update to 5.78.4 so it was indeed working in version 5.74.5.

I just tried and failed to replicate this on dmaster (locally) - I wonder what the difference is - the backtrace you displayed looks like it would be reachable at this url

civicrm/batchtransaction

Hmm, I am not sure what the difference is but the backtrace was indeed from the civicrm/batchtransaction:

Location	https://site.ca/civicrm/batchtransaction
Referrer	https://site.ca/civicrm/batchtransaction?reset=1&bid=571

I just want to check in to ask how likely it is that this will get fixed sometime soon? We do use this feature and it seems to be a confirmed issue for other people as well, from a comment above, but I do not know what kind of timeline to expect.

@nicholash typically regressions are fixed within the same release cycle, typically a week or two.

Ok, great. Thanks for the response.

I am not able to replicate the issue on dmaster. Here's demo:

I just want to check because it does not seem to say anywhere but what is the versions of CiviCRM and Drupal on the dmaster site? I though at least the CiviCRM version would be at the bottom but it was not there.

And I was assuming that the normal dmaster site was Drupal 7 since there is a https://d10-master.demo.civicrm.org/ site. And the issue is happening, for me at least, on Drupal 9 and 10, I have not checked on a Drupal 7 site.

I have checked the d10 demo site and I can see the CiviCRM version below: and I cannot replicate the issue on this site.

Although I cannot tell the D10 version of it. So I checked the issue in my local setup which is running on D11.04 / CiviCRM 5.81.alpha1 but still can't replicate :

And yes dmaster is a d7 site.

I will try to replicate on given D10/Civi5.78.4 version.

Nope I wasn't able to replicate the same on D10/Civi5.78.4

Just to test it I upgraded my staging site to CiviCRM 5.80.1 and am still getting the error. Will anything more be done here to investigate this issue?

Also @mattwire do you still get this error or happen to look into the issue you are having at all?

I don't know anything about this use-case, but reading the backtrace, the failure looks right.

(1) The QF controller and state-machine should be initialized around here:

#5 /home/account/site/vendor/civicrm/civicrm-core/CRM/Core/Page/Basic.php(364): CRM_Core_Controller->run()
#6 /home/account/site/vendor/civicrm/civicrm-core/CRM/Financial/Page/BatchTransaction.php(109): CRM_Core_Page_Basic->edit()
#7 /home/account/site/vendor/civicrm/civicrm-core/CRM/Core/Invoke.php(338): CRM_Financial_Page_BatchTransaction->run()

(2) CRM_Core_Page_Basic makes a new CRM_Core_Controller_Simple(...). The __construct() method then makes a vanilla state-machine:

  public function __construct(...) {
    ...
    $this->_stateMachine = new CRM_Core_StateMachine($this);

(3) In fact, the vanilla CRM_Core_StateMachine does not define getTaskFormName(). That method is only defined in subclasses. (It's a real mix -- 60/40 -- with subclasses that do and don't implement the method.)

(4) It sounds like conundrum is: "Why doesn't it reproduce?" Follow-up question... when trying to reproduce, can you get it to execute the relevant line?

    if ($buttonName == $this->_actionButtonName) {
      // check actionName and if next, then do not repeat a search, since we are going to the next page

      // hack, make sure we reset the task values
      $stateMachine = $this->controller->getStateMachine();
      $formName = $stateMachine->getTaskFormName(); ## The failing line
      $this->controller->resetPage($formName);
      return;
    }

You may find it throught-provoking to determine whether:

• You can run this line -- and it executes successfully.
• Versus...
• You never get to this line at all (some prior conditional causes it to skip).