Default value for text area not long enough

SuiteCRM Forum - English Language Developer Collaboration
1

Hi,
I am creating a ‘terms and conditions’ text area box to be used in an invoice/contract.
I want to it to have the default terms and conditions loaded as standard, but anyone can go in and change them as desired, but by default they are the basic terms.

I understand this can be solved by just the ‘default value’ field but this is too short and cuts off half the text.
Is there any way to solve this issue and achieve my aim through a different method?
Thanks

2

Hi,

You can change the default size of the text area by changing the Rows and Columns setting in the field declaration. Larger values for these will make the text area large enough to fit the T&Cs.

Thanks,
Jim

3

I tried that but still doesn’t work.
The default text is still cut off at the same limit of characters.

4

What is the limit you are seeing? What database are you using? In MySQL the limit for a TEXT field is 65535 (single byte) characters. Could you be approaching this limit?

Thanks,
Jim

5

I’m using MYSQL, the word count is 2953.
The limit is about 255 characters.

Where is the default value for a field stored?

6

Can you confirm the type of the field and the type that is in the database? 255 characters is very low for a text area.

The default value for a field is stored both in the database (as the default for the db field) and as the ‘default’ key in the appropriate vardef.

7

It’s definitely a text area, I don’t know where to find the fields in the database?
I have looked at the vardefs and they don’t say anything about a default field?

8

In

SuiteRoot/custom/Extension/modules/YourModule/Ext/Vardefs/sugarfield_yourfield.php

you can find the default value.

9

Yeah I’ve already looked there and it says nothing about a default field, it still shows up in studio though.

10

Sorry,

It’s just occurred that you are creating a custom field. This will be stored in the default_value column of fields_meta_data in the database. Looking at this column shows that it is a varchar(255). A workaround for the moment would be to increase the size of this field.

Thanks,
Jim

11

Yeah that’s what you originally said up there /\ and I did that but it still didn’t work. Will not go further than 255

12

In what way didn’t it work? I’m suggesting you increase the size of the fields_meta_data.default_value field in the database. I.e. by performing:

ALTER TABLE fields_meta_data MODIFY COLUMN default_value TEXT;

Please make sure you do any changes on a backup to test and not on a live instance of SuiteCRM.

13

WAHOOOO!!! It worked!!!

Thank you so much!

14

I am having the very same problem here. The size of this database field (varchar (255)) is simply not enough when you use custom created text area fields.
I have implemented Jim’s solution and altered database column to varchar (max). Now everything is working properly except that I just lost upgrade safety! And I want to be able to upgrade when needed. And also I have this irritating error every time I do Repair and Rebuild:
[FATAL] Executing repair query: Query Failed:ALTER TABLE fields_meta_data ALTER COLUMN [default_value] nvarchar(255) NULL::: [Microsoft][ODBC Driver 13 for SQL Server][SQL Server]String or binary data would be truncated.
It is trying to alter field back to nvarchar(255) but fails when squeezing my text into it.

I am not sure if this field should have limited size but 255 is just too small for large text like Terms&Conditions or Warranty options or EULA etc.
I know that this texts could be added as an additional document aside but it is a lot more flexible if someone wants to change some parts of this text.

Use case for custom text area fields bigger than 255 is like when creating Quotes/Contracts with slightly different T&C and you want a user to be able to make this changes easily. The other way around is to make as many templates as you have possible differences in terms but this is not practical or to have as many 255 fields as needed chained one after another instead of one, again not practical.

Is there a way to vote for this change to be implemented in the future releases? Let’s say varchar(2000)…(who really need’s (max))?

15

The solution is in the following file:
modules/DynamicFields/vardefs.php
What I did was: change line 57:
by:
‘default_value’=>array(‘name’ =>‘default_value’, ‘type’ =>‘text’, ‘length’=>‘65500’, ),
and in the phpmyadmin, in the table fields_meta_data change the data type to text
then i repaired

this worked for me

In the same way, I think that only changing the vardef and repairing it reaches