Increase metadata character limits

Hi,

I am heavily relying on the metadata from tasks to gather information through the API for external applications I am developing at my workplace.

The issue I have is that the field is limited to 255 characters which is too short for me.

Is there a workaround? I was thinking about artificially changing the field type/limit on the database directly but I suppose that must be rather dangerous to do it this way.

Thanks for the help !

I have the same / or nearly the same question. So i add it here:

How can one use userMetaDataModel or extra database Field with more than 255 Characters? 65536 e. g.?

Any hint is appreciated.

Thanks, Fx

Iā€™ve investigated that further. The problem ist that the field value in the table user_has_metadata is defined to 255 characters (default).

How would one fix this from within Kanboard without knowledge which database is in use?

  1. Copy table to a temp table (create table ā€¦ as select ā€¦)
  2. drop table
  3. recreate table with larger size for value (datatype TEXT) field
  4. Insert from temp table into the new one
  5. drop temp table

I can do that with sql statements but this would lead to database specific scriptsā€¦

Iā€™am aiming to fix this issue, because i want user specific css (bug here is the smal value field in the core):

Any other ideas to have custom css on a per user / profile basis from within Kanboard?

Cheers, Fx

i dont know, customizer has user specific themes/css, so im always meh on this topic.

CustomUserCSS ist not Customizer PlugIn. It has no theme or special theme needs.

That PlugIn adds a Metafield to the user. The user can add his own CSS in that field. But that field is limited to 255 chars which is far away from enough to do things with css.

Question is how can one add a field with lets say 65536 char lengt?

just because something is not one thing, does not mean its unrelated. you want more than 255 chars. with customizer, you can simply upload a css document, with no char limit. seems like one solution to a problem.

Youā€™re right.

Itā€™s a work around, but to complicated for a normal user.

I would have css in that field (screenshot) not an include to a file, where the user may modify some colors. Guided by comments in the css in his own profile with normal user rights.

well, your other option would be to make a plugin, include a schema that alters the value columns. id be wary of installing said plugin, as this could eventually have consequences down the road with migrations.

if you include a schema for all DB types, then the plugin would automatically use the appropriate schema, so you dont need knowledge of the DB type.

https://docs.kanboard.org/v1/plugins/schema_migrations/

1 Like

I think the best approach would be to expand metadatfields of type ā€œTextā€ to more than 255 character (65535 e. g.)

But this will lead to changes to the core.

SQLITE the datatype is ā€˜TEXTā€™
After testing, i can put way more than 255 chars into field no issue.
as far as i can tell, nothing in Kanboards Core is limiting this to 255 chars, for SQLITE.

FYI, 858330 was the max amount Chars I could have it save:
test4

Itā€™s MySql and postgress where 255 chars is clearly defined as the limit.

for a breif time, the settings table value was also defined as varchar(255), but was changed to type ā€˜Textā€™, most likely not long after the CustomCss option was added:

so, yes, you could do the same in the core for the user_has_metadata value, or you could include a schema with this plugin that makes the modification. There are other options, but it seems like we are hell bent on modifying databases, so there you go.

As for SQLITE, if you have a limit of 255, iā€™d say look at your setup and what you have going on, maybe you set a limit.

edit:
Iā€™ll include a couple other options that do not involve modifying the databse, because, wellā€¦why not:

1.) input css into the field, instead of saving directly to the DB, output a file with the css, and only save the filename into the user_has_metadata field.

2.) Donā€™t use that table, use the settings table, itā€™s already setup for you

Since this question is unrelated to the CustomUserCSS plugin, i would say you get a different answer, but its a vague question so, really you have 3 answers.

1.) use the settings table instead, not sure if that works for you though.

2.) use SQLITE, not sure if that works for you though

3.) Modify the tables you need. Is it dangerous? I donā€™t know, maybe. I think the real issue will come the day you upgrade kanboard after having modified the table, the migrations could fail. Possibly not tho.

Hi creecros,

thanks for your heavy investigation on that. Great.

And yes you are right: the database is a mySQL one. And i think this is an issue. We can define that it is not, but i think if we want to have an abstraction of the underlying db we should make sure that metadata should serve more than 255 chars for a text field if one is not able to define more without cirumevent the abstraction of the db.

And that is what the Author of CustomCSS did. He simply used the metadata text field, which ist the right thing to choose, but it does not help an he can not have more than that amount of chars per meta field.

Anyway. I think this should be changed in the core. Is it a bug? Depends. Maybe not. I accept all views on this. Personally i think: 255 chars for an abstracted database metafield of a type text is not sufficent. Even more when there is no ā€œlarge text fieldā€ option in the abstracxtion layer.

my2cents.

No complains! Iā€™am fine. And thanks to you again. Iā€™am impressed by our detailed, good and also absolut correct response and view on this one!

Cheers, Fx

I definately would not consider it a bug. Metadata is not intended to be data, necessarily, but is 255 chars enough? Maybe, maybe not, definately an opinionated question that will warrant different responses. As for the plugin ā€œCustomUserCSSā€, the author is using a table intended for ā€œMetadataā€ to store ā€œDataā€. The settings table is where I would save that, personally, as the table is most definately already setup to store ā€œDataā€.

Just to be clear though, iā€™m not advocating for or against altering the database in general, whether in the core or in a plugin. The OP wanted a workaround, via not altering the database, which is why I was offering outside the box solutions other than simply altering the database. I 100% agree, the easiest solution of all, is to simply alter the database, in the core.

Hi creecros,

i read we are aligned here :grin:

Regarding the settings table: is it possible to store data per user in that table? If so: do you have a hint to archvie that?

Thanks, Fx

yes.

use the user id in the key. i.e. [userid_customcss => value]

i can go into more detail if needed.

1 Like

I check that out as soon as possible und give feedback.

Thanks!

Cheers, Fx

you could actually use this as a decent guide. i did the same here, but used a unique color id instead.

metamagik does the same, but that code can be hard to follow.

1 Like

At the moment iā€™am trying to finalize a little theme iā€™ve made and sync my needs with some plugins (ColorManager, DueDate e.g.) but iā€™am still not happy enough to release it to my colleagues.

And documentationā€¦ :laughing:

When iā€™am done with that, i will have a closer look.

Could be a nice little project to dive deeper into php. Iā€™am not used to that programming language until now.ā€™

Happy new year to all of you!

Cheers, Fx

1 Like