4

On fresh Install Civi 5.4, Core expect to have new option group called "Activity default assignee", but upgrade script not executed and not updated the option group table with "Activity default assignee" options.

which cause null result in "Default Assignee" drop down on New case type and "Save" button has disabled because angular validation error.

enter image description here

5

This is due to the change made in this PR - https://github.com/civicrm/civicrm-core/pull/11998.

I raised this on Mattermost some time ago. See https://chat.civicrm.org/civicrm/pl/d58c9nuowbfemeneizbe57cxqy. It says -

Seems default assignee is a required field on Case Type Form(as per this change). Was this intentional? I was unable to save https://dmaster.demo.civicrm.org/civicrm/a/#/caseType/1 until I filled out default assignees for all the activities listed under standard timeline 🤦‍♂️

But unfortunately haven't got any reply for the same.

To fix this -

  • Remove the required word from this line of the PR and the following element. You should be able to save case type without selecting any value in the default assignee.

OR

  • Add values to the default assignee for all the activities.
0

I created the feature.

How come the upgrader didn't run? Did something break? Do you have a specific error message available?

I didn't set the main select as required, but it seems that since the options are missing, then the required field that is supposed to be hidden shows up and stops you from saving the case type.

I'll create a new PR that will handle missing options for this field, but it would be good to understand why the options are not available in the first place.

Please feel free to message me with any details you may have.

  • Is the intention that these are Required before one is able to Create a new Case Type - or edit one of the default Case Types? I don't remember a discussion about making such a change. If it is not intended that these are now required then can this get fixed. If the decision is these are to be Required then can you pls figure out what should be done to ensure that folk get clear instructions both in Documentation and via Alerts/Warnings on the screen to avoid frustrations? – petednz - fuzion Sep 18 '18 at 12:14
  • commenting because I still observe this behaviour on dmaster – petednz - fuzion Sep 18 '18 at 12:15
  • oh - now reading that you are not intending it to be required - hopefully you can get the PR done soon to fix this – petednz - fuzion Sep 18 '18 at 12:20
0

Short answer: The problem affects new clean installs on 5.4/5.5 but shouldn't affect upgraded sites. To quickly fix a new site, you can run cv as follows:

cv ev 'CRM_Upgrade_Incremental_php_FiveFour::addActivityDefaultAssigneeOptions();'

Long answer: As Jitendra pointed out, the change stems from #11998, which updated both the code/UI and the database. Of course, the PR went through some testing and passed. What gives? The testing focused on taking an existing database (perhaps a real site; perhaps just a local dev site) and applying the change on top. The PR worked because it defined an upgrade procedure for the database. However, in a clean-install, the database doesn't use the upgrade procedure. As a quick-fix, you can manually update the database. As longer term, we should issue a new version which automatically updates the database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.