Is there a Limit on Modules in a package

I have recently started to use Suite CRM. I had a good deal of hope at first but am now about at the end of my proverbial rope. Is this product really thing buggy.

I am creating custom modules. My earlier experience was that every time I created a second module in the same package the system crashed, I was able to get past it by commenting out some lines in the table defs file.

Now I have created a custom module, added three fields, all integer fields when I try to save a record it says unable to save record then another box says I am not authorized to view that page.
I have rebuilt several times, redeployed the package several times, Cursed numerous times, took a walk to cool down, trid all that again. Refreshed everything all, no love.

I don’t see anywhere where there is a limit on packages or modules within My other two packages seem to be fine, each has just one module. Can I expect this? I am precariously close to tossing the entire things and moving on to custom coding, which given the problems might be quicker

Hi,
I think there is no limit for number of modules in a package, definitely it should not crash during 2nd module creation. I think there is something wrong with your installation.

Hello,

I usually try to keep it to one module in one package.
It’s not a technical limit, but some architectural design benefits - check out these guidelines:
https://support.sugarcrm.com/knowledge_base/studio_and_module_builder/best_practices_when_building_custom_modules/
It’s just guidelines though, no rules.

What you describe sounds as if there are other issues as well.
Did you do any code customization?
Does everything else work without any issues?
What are the messages inside your log files? (suitecrm.log and your php log)
And I assume, your installation is completely inside a compatible system?

In general:
You’ve posted in the dev help. There is no need for any development for many custom modules.
Check out this video, maybe you find any hints or differences?

It did this twice on an almost new install. I think that it had to do with a path that was over long. The message was that a file listed in a config did not exist. I commented out the offending line and all was well. New install has a shorter path.

Thank you

I will stick to one per package, even though they are closely related modules.

As mentioned above, I think it had to so with path length in the first install, though not sure.

There is not custom code, yet, I am exploring that option though this occurred before I got there. In any case , although I don’t mind writing code I hope to keep it to a minimum, I think i can arrive at most of what I need with just a few custom modules and some work in the studio

1 Like

So, after learning that there should only ne one module per package, and given the trouble I deleted one module. This cause even more problems. Now, whenever I deploy, either a new package or via the studio I get a system crash again. I thought back and yep, in the earlier setup I had deleted something as well. Apperently that is not allowed. Seems like a fairly significant bug

This carash report references a line in the tabledefs file. When I delete this line in that file all is well, until i make any change in the modules then same error same line in file same reference to the a relationship in the deleted file .

So, I exported the modules and created a fresh install when I try to load them I get told it is an invalid package. So, start from scratch I guess. Perhaps this product is not ready for prime time. I am not even pushing the thing

It seems as if there are some issues when you make big changes in the module builder (e.g. deleting a module from a package) after deploying a module already and then try to re-deploy.

In a recent project I found that out as well but haven’t been able to replicate it - a smaller test with just one custom test field in a test module worked just fine.

Over all, this no code module creation is super easy, however, it has some issues here and there - which usually don’t reveal themselves in “easy” or straight forward setups / approaches.