You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was touched on by an issue last year ( #47 ), but I think it is worth revisiting since simply manually changing the column type/size of the schema isn't really an ideal approach.
A very common use-case is "country" . There are almost 200 of them in existence, and obviously they aren't all going to fit into the validation column, even using 2-byte country codes.
There are probably several ways to solve this, but one fairly quick and easy method might be to create an auxiliary hasMany table called dropdown_values or something. It might look something like:
COLUMN
DATATYPE
id
INT
fof_masquerade_field_id
value
So basically, it would just map to whatever the dropdown field id is.
Most of that is under-the-hood work, and would be transparent to the admin/user, of course.
To make it even better, there could be a quick-and-dirty CSV import option as well, perhaps, but that isn't really the core issue. It's the storage.
Just a thought!
The text was updated successfully, but these errors were encountered:
That's definitely a limitation of the system that was chosen here.
Since the AnswerValidator extends the Flarum validator, you could use custom code to listen for Flarum's Validating event and alter the validation rules. That way you can load the rules from somewhere else that's not restricted by a database column, or even use Laravel validation rules that aren't available through Masquerade like database-based validation.
True, though that seems like an awful lot of work for something that seems as if should be ready-made, as it were.
Instead, perhaps a custom extension that would bring that functionality into the fold. Or, perhaps less work would be to just do a PR to add the functionality into masquerade proper.
Masquerade was never designed with dropdowns in mind.
Dropdowns are just a nice trick we introduced to make in: rules more user-friendly.
I don't really think we should be adding new features/tables to this extension at this time, we already have a hard time keeping up with maintaining the existing features 😅
This was touched on by an issue last year ( #47 ), but I think it is worth revisiting since simply manually changing the column type/size of the schema isn't really an ideal approach.
A very common use-case is "country" . There are almost 200 of them in existence, and obviously they aren't all going to fit into the
validation
column, even using 2-byte country codes.There are probably several ways to solve this, but one fairly quick and easy method might be to create an auxiliary
hasMany
table calleddropdown_values
or something. It might look something like:So basically, it would just map to whatever the dropdown field id is.
Most of that is under-the-hood work, and would be transparent to the admin/user, of course.
To make it even better, there could be a quick-and-dirty CSV import option as well, perhaps, but that isn't really the core issue. It's the storage.
Just a thought!
The text was updated successfully, but these errors were encountered: