SuiteCRM 8.7.1 - System Inaccessible After Creating Task-Activity Relationship

đź’¬ General Discussion
1

Hello SuiteCRM Community,

I’m experiencing a critical issue with my SuiteCRM 8.7.1 installation. After creating a relationship between Tasks and Activities modules using Studio, I can no longer access my SuiteCRM instance through the web interface.

Current Situation:

  • When trying to access the system, I only get an “Error occurred while fetching metadata” message
  • The screen remains blank after the error message
  • This happened immediately after creating the Task-Activity relationship through Studio

Technical Details:

  • SuiteCRM Version: 8.7.1
  • Relationship was created using the Studio tool
  • The issue affects the entire system access
  • No error logs available from the web interface

Questions:

  • How can I recover access to my system?
  • Is there a way to revert the relationship creation through database or file system
  • Are there any specific Studio-related configuration files I should check?
  • Are there any specific logs I should check to identify the root cause?

Any help or guidance would be greatly appreciated. This is a production system and I need to restore access as soon as possible.

Thank you in advance!

2

You can check logs prod.log in /logs/prod/ and sugarcrm at /public/legacy/ folder.

3

@rsp There is no phperror in the public legacy folder. There is a suitecrm.log, but I cant find anything related there.

5

Fixed login issues by removing problematic relationships between Tasks and Activities:

  1. Database Cleanup
  • deleted all the registers from relationships table where relationship_name began with tasks_activities_1_*
  1. File System Cleanup
  • Removed all files containing tasks_activities_1_* in their names
  1. Quick Repair and Rebuild (CLI alternative)
sudo -u www-data php bin/console suitecrm:app:upgrade
sudo -u www-data php bin/console suitecrm:app:upgrade-finalize
  1. Clear Cache
sudo -u www-data php bin/console cache:clear
sudo -u www-data php bin/console cache:warmup

After these steps, the system was accessible again and login functionality was restored. The system seem to be working fine

Note: I’m not sure if step 3 is the CLI equivalent to performing Quick Repair and Rebuild from the admin panel. I did it because it was suggested by anthropic/claude-3.5-sonet