Upload migration files from profile settings and start processing

[tclaus]

This is a new PR which is rebased on latest dev and a squash of the fixing commits.

[Flaburgan]

Hello! The button being disabled does not work locally, it's because I don't have sidekiq there right?

Can you also enable the message on the registration page by removing this if? https://github.com/diaspora/diaspora/blob/develop/app/views/registrations/_new.erb#L57

Thanks!

[tclaus]

@Flaburgan It should work, when a migration is completed. (This worked locally) BTW I have disabled the If to show the message on registration page.

[Flaburgan]

I just deployed this branch to diaspora-fr and tried to import my diasp.org account but it did not work. I submitted the dialog as I did locally, and the green message "Import is scheduled" but the Import button is still available in my settings. I don't know if the jobs was actually scheduled in sidekiq, I just realized that despite setting log = log/sidekiq.log in diaspora.toml, there actually is no log file for sidekiq there, only the production one.

Edit: maybe no sidekiq log file is due to the fact that I start it with systemd. I checked them with journalctl but no mention of import there.

Edit2: actually, the import worked! But so as I said, the blue import button is still available, and pressing ctrl R is allowing to resubmit the import, so I think we should not allow that.

[Flaburgan]

Another remark: after the import, I have been spammed by email notifications of all my imported contacts, that they have started sharing with me. I think we don't need to have a notification about this, as the user is triggering it.

[tclaus]

I just deployed this branch to diaspora-fr and tried to import my diasp.org account but it did not work. I submitted the dialog as I did locally, and the green message "Import is scheduled" but the Import button is still available in my settings. I don't know if the jobs was actually scheduled in sidekiq, I just realized that despite setting log = log/sidekiq.log in diaspora.toml, there actually is no log file for sidekiq there, only the production one.

Edit: maybe no sidekiq log file is due to the fact that I start it with systemd. I checked them with journalctl but no mention of import there.

For the records: $: sudo journalctl -u diaspora-sidekiq or sudo journalctl -u sidekiq shows the logs

[Flaburgan]

@tclaus any chance you can have a look at the "Import" button not disappearing when closing th dialog? I wish I can tell people to come to diaspora-fr.org before diasp.org is closed.

[tclaus]

I can check this on the weekend. The button should Test the pending migrations for a user in the migration table.

[tclaus]

To disable the button I have made some deeper investigation - first, the dialog is submitted - here Javascript may do the job to disable the button immediately, Import file is uploaded and validation stars - here an enum (new column) in the user-table may indicate an ongoing validation check (status: “Import Validation”) Then a job is triggering (status: “Import job pending”) Then the job could set a “Import running” and at least “import completed” or “import failed”.

I think on a new column, with some statuses, to indicate that an import has been started and its current status. IMHO this kind of status does not exist currently?

What did you think? Is this a way we can go?

[Flaburgan]

first, the dialog is submitted - here Javascript may do the job to disable the button immediately,

I think when you submit the form you should do a POST redirect GET. At the moment if the users press F5 after the dialog is closed, it is re-submitting the form, that should not happen. To reload the page entirely will avoid this problem, and allow us to display the correct status instead of the button.

Then about how to get this information, how is this done for the export buttons? Because everything is working nicely for those, so I think we should do the same.

[Flaburgan]

So I just checked how it is done for exporting, and indeed we have two booleans on the user table, one exporting for the data and one exporting_photos for the pictures. They are then set to true when the export starts and back to false when it's done. So I guess we should do the same for the import. Will you have time to have a look in the coming days, or should I try (even if I never modified the schema or anything similar).

[tclaus]

@Flaburgan

So I just checked how it is done for exporting, and indeed we have two booleans on the user table, one exporting for the data and one exporting_photos for the pictures. They are then set to true when the export starts and back to false when it's done. So I guess we should do the same for the import. Will you have time to have a look in the coming days, or should I try (even if I never modified the schema or anything similar).

Sounds OK for me - let's include one boolean for importing user data and one for photos. The details are already stored in the table 'account_migrations'.

This evening I have some time to implement this.

[Flaburgan]

@tclaus hey, it looks like with your last commits the import is not launched anymore: I don't have the green confirmation popping up, and it does not look like it starts. Why did you do the POST with JS, I think it was working fine the way it was before, but in the rails controller at the end you should simply redirect to the user settings, instead of returning it directly.

[tclaus]

@tclaus hey, it looks like with your last commits the import is not launched anymore: I don't have the green confirmation popping up, and it does not look like it starts. Why did you do the POST with JS, I think it was working fine the way it was before, but in the rails controller at the end you should simply redirect to the user settings, instead of returning it directly.

Hi @Flaburgan , I thought the POST with JS in combinati0on was the only way to hide the dialog after uploading, but I was wrong. Changed this back and enabled the flash-message again. (Was a simple parameter in the flash statement that prevented the flash in the UI - I fixed this. I also fixed another failing test.

Also without a visible flag message the import should have been startet (I can see in the debugger a start of the import job every time)