Open-event-server: Issues in creating an event after importing json files

[mananwason]

• [x] No option to import json files while creating a new event
• [ ] No progress after selecting event zip and clicking create event
• [x] After 15mins also, there is a Status : WAITING. Screenshot for this is attached
  

[mariobehling]

option to import json files while creating a new event

Is not desired at the moment.

[aviaryan]

After 15mins also, there is a Status : WAITING. Screenshot for this is attached

@mananwason
Importing the FOSSASIA sample does take some time as many objects are to be created. It took around 15-20 mins for me the last time I tried. Did it eventually succceed ?
I will add more progress indicators in the import process so that users don't get impatient.

[mananwason]

@aviaryan I closed it after an hour. Till then it was showing WAITING only. If it is actually running, why show a message like WAITINg instead shouldn't it be better to show "Processing" or something like that.

[mariobehling]

@aviaryan As it will always take a while the overlay is not the best way to implement this. Better would be to implement it on a separate page in two steps a) users upload file, b) as soon as it is uploaded they have to press "Create Event Now". Then they should be able to leave the page and get an email/notificaction when it is finished. Does this make sense? If yes, please create an issue.

[aviaryan]

If it is actually running, why show a message like WAITING

@mananwason
No the task has not been started when "WAITING" is showing. A different message will be shown once it is started.
My guess is that the server was re-deployed when the import was going. So the celery worker was killed and hence the status froze at "WAITING". I don't think it possible to stop killing a worker when the server is being re-deployed, so I will have to stop celery jobs when server is re-deployed.

@mariobehling :+1:

[aviaryan]

@mananwason I just tried importing a small event on server and it is showing WAITING forever.
I think something is wrong. Thanks for reporting. The logs are not showing anything useful for now. I am not sure about the problem as importing works on local system. I will open an issue for it.

[mananwason]

@aviaryan Great. Glad I could help 😄

[aviaryan]

@mananwason I have fixed the import issue on server. Can you please try again ?

[mananwason]

@aviaryan Just tried again. No loaders and shows working now, didn't get to STATUS part

[aviaryan]

@mananwason I just tried uploading the FOSSASIA sample and it did work (did get to the status part).
But the sample was not imported because of a syntax error https://github.com/fossasia/open-event/issues/77 .
I will try to import it again after fixing it.

EDIT - More issues https://github.com/fossasia/open-event/issues/79

[aviaryan]

@mananwason I fixed the issues ( https://github.com/fossasia/open-event/pull/80 ) and imported the FOSSASIA sample on server.
http://open-event-dev.herokuapp.com/events/132/

[mananwason]

@aviaryan Can I get access to this event? My email is [email protected]

[aviaryan]

@mananwason Invitation sent

[mananwason]

👍

[mananwason]

@aviaryan Still I am not able to import. I got a 500 internal server error

[aviaryan]

@mananwason Make sure you are using the latest version from open-event repo.
Also make sure the event(json), sessions(json) and other files are at root of the zip. If you are already doing these things, then share your FOSSASIA16.zip that fails to import. I will look into it.

[mariobehling]

@mananwason @aviaryan We should create zip files in the sample folder at every update of the files. The OTS sample would be too big though. I created zip for FOSSASIA16 and Ehealth. https://github.com/fossasia/open-event/tree/master/sample

[mananwason]

FOSSASIA16.zip
@aviaryan This is the zip I used. IT follows the things you said. It was made from the cloned repo on my pc.

@mariobehling What about if we add a travis script for this. On every commit we can commit a zip for every folder in the sample directory. But right now we can let it be I suppose. We need to get the project working first. We can do stuff like this later on after GSoC

[aviaryan]

@mananwason Sorry but I think you missed this point.

Also make sure the event(json), sessions(json) and other files are at root of the zip.

I opened your zip and this is what I saw.

event, sessions and other files are not at the root of the zip.

Here is how it should be.

I have already mentioned it in the import export docs. https://github.com/fossasia/open-event-orga-server/blob/development/docs/IMPORT_EXPORT.md#the-zip-structure

---

@mariobehling I think the same applies for zip's you uploaded in the repo. Their json files are not in the root too.

---

@mariobehling @mananwason I think including zip's (binaries) in the repo can increase the repo size at a rapid rate. (Not sure how git handles them though) So cloning and managing the repo can get tough especially for average Internet users.

[mananwason]

event, sessions and other files are not at the root of the zip.

@aviaryan When I create a zip using the compress option in OSX, it creates a folder by default and so does every other zip archiver. When decompressed we get this folder and this folder has all the files. So you should probably change your implementation.

@mariobehling @mananwason I think including zip's (binaries) in the repo can increase the repo size at a rapid rate. (Not sure how git handles them though) So cloning and managing the repo can get tough especially for average Internet users.

@aviaryan @mariobehling If we include the zips in the open event repo, we should be okay. It's anyway not being used to develop something. We are just maintaining README's and samples there

[mariobehling]

@aviaryan: Thanks for looking into this. Update the zips.

[aviaryan]

@aviaryan When I create a zip using the compress option in OSX, it creates a folder by default and so does every other zip archiver. When decompressed we get this folder and this folder has all the files. So you should probably change your implementation.

What happens if you go inside the FOSSASIA16 folder and then Ctrl-A to select all files and then compress them ? That way it should have all files at the root.
This behavior is obvious in Linux and Windows. I don't know about OS X. But if you still have problems, see the following links for OSX. The first one shows using commandline to fix it.

1. http://superuser.com/questions/850829/how-to-zip-files-in-mac-without-root-folder
2. http://apple.stackexchange.com/questions/51229/compressed-archive-in-lion-creates-a-root-level-archive-folder-in-zip-file

So you should probably change your implementation.

Allowing a folder at root can have lots of ambiguities --
What should be the name ? What if there is no folder with that name ? What if there are 2 folders like in your case with different names ?
The current implementation is simple and doesn't have these issues. Also it is not a problem in Linux and Windows and is quite solveable in OSX.

@mariobehling views ??

[mariobehling]

I think these kind of discussions are outside this issue and we have solved this question already. Closing it.

[mariobehling]

If anything is left, please follow up in dedicated new or existing issues. Please try to keep the comments short and focussed.