For some reason it seems the ‘Create Your Account’ button no longer works in the sign up dialog for my forum - clicking it after all user fields are completed (as far as I can see correctly) elicits no response (not even an error message).
The dialog does not close, and no email verification message is sent.
Not seeing any obvious problems with the content of user fields during sign up - all are completed, and none show errors.
Tested under Chrome version 117.0.5938.134 (Official Build), and Edge version 118.0.2088.33 (Official build).
Clearing browser cache seems to have no effect.
The manual ‘test email’ function sends a message to the affected user’s address just fine.
The forum mail-list functionality for existing users works just fine.
I can also log in and out to the forum web site just fine.
I am not aware of any recent changes made to forum settings (other than software updates), but not sure if there even is a setting for ‘ignore user input’
My intending user has tried to sign up a few times and I have tried from my end as well, and can verify the issue.
Currently running latest Discourse version (updated to 3.2.0.beta2-dev build in hopes of solving the problem)
I am not sure when this started happening, as we haven’t had any new signups in a while (perhaps now I know why!)
Assuming the Multi-select plugin is the cause of the issue, it should be fairly straightforward to migrate the old ‘multiselect-dropdown’ fields to new Discourse ‘multiselect’ fields. Someone from the Discourse community should be able to help you with that.
Hi - yes, the plugin does seem to be superseded, so is unlikely to be updated - but the problem is with migrating the plugin generated user data to corresponding core user data fields, so that the plugin can be safely removed.
Simply uninstalling the plugin also seems to delete the associated data (or at least it is no longer visible when looking at user profiles)
Assuming I am not the only plugin user, if would be great if the plugin was given a final update, to include a ‘migrate’ function!
I’m not seeing anything in the plugin that would cause the user fields created through it to be removed from the database when the plugin is removed from a site. What I’d expect to find is that from the Rails console, running:
will return the list of multiselect-dropdown fields you have created on your site.
The values set for the id of each of those fields can be used to find the options that each user on your site has selected for the field. For example, if the ids that are returned are [1, 2, 3], there will be corresponding UserCustomField entries with the names "user_field_1", "user_field_2", and "user_field_3". Assuming this is all correct, that will be enough information for someone to migrate the old fields to new fields from your site’s Rails console.
If the plugin’s author isn’t going to deal with this, you’ll likely have to hire someone for the work. Note, I’m not trying to get work here, I’d rather not do it
Before the migration is done, you should create new Discourse ‘multiselect’ fields that have options that match the values of your old multiselect-dropdown fields. To make the migration process easier, it would be good to use the same name for the new fields as you used for the old fields. That way, whoever performs the migration will know that (for example) multiselect-dropdown fields with the name “NZRAB number” should be migrated to the new ‘multiselect’ field that has the name “NZRAB number”.
I agree it would be best if the plugin’s author took care of this, but if that can’t happen, just go ahead and create new ‘multiselect’ fields and remove the plugin.
Just to check - should the core version of Multiselect dropdown allow multiple items from a single dropdown to be selected simultaneously by a user, in the same way as the old plugin did?
When tried adding a new user field of type ‘Multiselect dropdown’, there is only one ‘Multiselect dropdown’ option to chose (I might have expected two, if the plugin version is distinct from the core version).
Now if I chose that Multiselect dropdown field type, and try to add data to a user profile with it, it only accepts a single user selection, not multiple selections at once - so it seems either like the core version of multiselect drop down field type has reduced functionality and has displaced the plugin field type version, or there is some interaction with the plugin version that is crippling whichever version I am seeing?
It’s possible that the UI is different than what the plugin was doing, but hopefully the results are the same.
Can you confirm that with the plugin installed, you are able to see the values that users have entered for the fields created with the plugin if you visit their profile page?
Edit: @Paul_King, I’m realizing I may have been overly optimistic about migrating the data. Without accessing your site’s Rails console, the easiest way to get a sense of what’s going on would be to check how the old fields have been saved by running a Data Explorer query. If you don’t have that plugin installed on your site, it might be worth adding it.
If the Data Explorer plugin is installed on your site, try running the following query:
SELECT * FROM user_fields
Hopefully that query will return some results with their field_type set to “multiselect-dropdown”. If it does, migrating the data should be fairly straightforward.
Your example showing operation of multi-select dropdown matches they way mine used to work, which seems promising in terms of restoring original functionality.
Currently it seems neither the old plugin or new version core functionality are working correctly - the whole field does not now appear at all in the ser profile editing screen, though values that user originally entered using old plugin do appear for a user clicking on another user’s avatar but with the original data showing square brackets and quote marks either side.
Yes that query does return that field type . Is it possible that confusion is arising due to old plugin name and the discourse core name for their respective versions of a multi-select user field type being identical?
That’s not surprising. What it means is that the data necessary for the migration is in the data base, but it seems likely that it’s in a form that won’t make the migration as easy as I hoped.
To confirm that, try running the following Data Explorer query:
SELECT * FROM user_custom_fields
WHERE name = 'user_field_1'
ORDER BY user_id
The useful information from that query’s results will be what is set in the value column. Ideally the results would look similar to this, with a separate entry for each option a user has selected:
I suspect that what you will find is that the values for each option a user has selected will exist in the same row. For example, [this, that] or "[this, that]". If that is correct, can you post a few of the value entries?
It might take a bit of trial and error to figure out how to parse the values into the form that Discourse expects to find.
I suppose an export of the user file will provide all the data that’s needed, and it can be cleaned up to make ready for import using something like this:
It looks like that would work. Jay, or someone similar would probably need to be hired to do the work.
It should also be technically possible to make the changes from the Rails console. The difficulty of that approach will depend on how the value fields are being set for the old “multiselect-dropdown” UserCustomFields. If there’s one option stored per row, it would be straightfoward to generate new UserCustomField entries from the old ones. If multiple options are stored in each row, it could get kind of tricky.
The data format was interesting - it was in two different forms which changed one day. They started out as:
this
that
And one day they suddenly changed to
this,that
I did some ugly spreadsheet wizardry to transform the data into how the new multiselect fields are (as above). Unfortunately, the script can’t (yet) handle multiselect. PR anyone?
Although I can workaround / hack it to do the job I reckon:
1st pass: all users with a single entry using the existing script
2nd pass: all users with multiple entries using a hacked script which forces new rows.
later…
My cunning plan worked.
This is the hacked script for the 2nd pass:
# frozen_string_literal: true
require "csv"
desc "Import user fields"
task "multi_user_fields:import_csv", [:filename] => [:environment] do |_, args|
puts "Filename: #{args[:filename]}"
data = CSV.read(args[:filename], headers: true );
data.each_entry do |row|
puts "doing row."
row.to_h.each do |x|
user_id = row['user_id']
if x.first == 'user_id'
u = User.find(user_id)
puts "Got user: #{u.username}"
else
name = x.first
val = row[x.first]
ucf = UserCustomField.find_by(user_id: row['user_id'], name: name)
if val
puts "Creating UCF: #{row['user_id']} Name: #{name}, value: #{val}"
UserCustomField.create(user_id: user_id, name: name, value: val)
end
end
end
end
end
@pfaffman - how easy would it be to update the actual script to handle multi-select fields for others who mess with UCFs in the future?
From my end I am very happy to report Nathan and his process (hacks and all) absolutely did the trick.
I have confirmed that the sign up dialog is now working, intending users can again select multiple answers from the drop down options, and can view and edit these again as approved users, and the old multi-select plugin was successfully removed.
Thank you to @nathank, @omarfilip, @simon and @RGJ for taking the time to consider this issue and share your knowledge and insights - more proof, as if any needed, of how great this community is!
.