Limited Number of Custom Fields per Project

[Michael D.]

Good day,

We recently Upgraded to 2.26.2.

Since the upgrade, we have found that our projects that exceed 42 custom fields now do not save the fields that exceed the 42nd field. (ie. fields 1 through 42 update, but 43 and onward do not update).
I have tested it across 3 different projects and two instances of MantisBT with the same results.

May we please have some guidance on how to fix this issue if others have experienced it? Or if there is a parameter somewhere in the code that we may not know of?

Thank you for your time and input,
Michael

[atrol]

We recently Upgraded to 2.26.2.

Which version did you run before?

I did not have a deeper look, but I am not aware there is a limitation for that.
Do you see any errors or warnings in browser console?
Do you see any errors or warnings in web server / PHP logs?
Do you see any errors or warnings in database logs?

[Michael D.]

Hi Atrol!

I believe we were running a 2.25.x version if I remember correctly.

There are no errors that appear when attempting to update an issue.
If you may assist me, where can I find the logs that you mentioned so I can try get some of that info?

Thank you very much,
Michael

[atrol]

Before coming back to the previous questions:
Did you run <yourMantisURL>/admin/check/index.php and fixed any errors and/or warnings you might have seen?
Did you change any source code of MantisBT?
Did you install any 3rd party plugins?
Which operating system do you use?
Which PHP version do you use?
Which database / database version do you use?

[Michael D.]

Hi Atrol.

1. Test /admin/check/index.php was run with 4 fails. 3 of which are related to the event log. 1 related to "Database default collation is UTF-8".

2. Historically, some code was changed for date formats and adding custom statuses, but as far as I recall, nothing core to Mantis itself. Also nothing in recent months.

3. We do have 3rd party plugins. None of which are returning errors on the Plugins page, and none that are new.

4. The server is running Linux.

5. PHP Version: 7.3.33

6. MySQL Version: 10.2.36-MariaDB

[atrol]

1. Test /admin/check/index.php was run with 4 fails. 3 of which are related to the event log. 1 related to "Database default collation is UTF-8".

What do you mean with "related to the event log"?
I didn't find such checks.

3. We do have 3rd party plugins. None of which are returning errors on the Plugins page, and none that are new.

Is the source code of these plugins available as open source?
If yes, where is it stored?
Are you able to reproduce the issue without having activated these plugins?

[Michael D.]

Hi atrol!
My apologies for the delayed response.

On the /admin/check/index.php check, I have corrected the fails (they were relating to the collation of the database). This had no impact on the limit to the amount of fields (henceforth known as threshold).

I tested the threshold again once removing every plugin and it remained limited.

I tested if the datatype has an effect, to which I created a test project with 60 fields with the same datatype. I found that of the ones I tested (Date, textarea, string, checkbox, radio button), they all had a threshold of 57, except for date fields which were limited to 28.

I also found that the issue persists into clones and that you can populate fields past the threshold by importing records, however even once said data is populated, records past the threshold cannot be further edited normally.

Lastly, I tried to test what would happen if I started from the bottom instead of the top of the field list. I found that (Given threshold=57)
Starting from 60, inputs worked until reaching 57 fields used, where each field used thereafter would shift the threshold one position higher, preventing the lower fields past 57 from being edited, however, their value remains.

Thank you for your assistance,
Michael