Community Forums

1. 

   am262327
   Member
   Posted 11 years ago

   Dear Mediacore Community,

   I propose that I help to add a feature to mediacore, which we will be using upon successful completion. I have time set aside already to complete it. I would appreciate any pointers as I begin to plan and research this project:

   * Users would be forced to provide an email from a specific domain.
   * That email address used to confirm
   * Publication of the upload is completed upon confirmation via email

   The benefits are:

   * Users don't have to log in. We have 1000+ students who could potentially upload videos and this would cut out maintaining these accounts

   * Cuts out spam (I've already gotten a bunch.)

   The downsides are:

   * The front-end upload doesn't allow users to choose tags or to upload thumbnail. What would be involved rectifying this?
2. 

   Ian Nalepa
   Member
   Posted 11 years ago

   This sounds like a pretty good idea, and maybe something that could also be useful to us in the future. I only wish we had the python skills to help out.
3. 

   am262327
   Member
   Posted 11 years ago

   I have the python skills but I'll have to do a crash course in how mediacore functions generally. I hope my eyes aren't bigger than my head!
4. 

   Felix Schwarz
   MediaDrop developer
   Posted 11 years ago

   I'd like to give you some pointers on this. Generally I really like the idea, makes a lot of sense. In my dream world some of the code would go in MediaCore itself and some more specific stuff (e.g. "only allow specific email addresses") in a plugin.

   The current public upload is pretty basic as you know. From the customer inquiries I get it looks like this mechanism must be improved in the future (e.g. uploading videos from authenticated but non-editor users similar to what we have in the backend). Your question (e.g. thumbnails) points in a similar direction.

   The first question is: Where do you store the video information? "media" table would be the easiest as you could reuse all mechanisms (e.g. storing the actual video). Downsides: You'd get new media notification and possibly a lot of spam media visible in the admin (even though not published). Use media.meta to store additional data which you need for the confirmation.

   Sending the confirmation email should be done in a plugin - probably you should add a new event when a public upload was successful.

   Uploading a thumbnail: I'm not 100% sure but probably you could add a appropriate field to the form using a plugin.

   Tags: Again some work is needed, I assume you need to suggest from the existing tags and possibly allow new tags.

   Technical info: If you build new JS code, I'd advise to use jQuery/jQuery UI+klass.js (github/ded). My plan is to phase out both mootools and Google closure though I'm not sure over which period of time. If you want to extend the existing mootools base instead, fine with me as well.

   I built also a Fine Uploader-based pure JS upload for the backend. It's not releasable yet though the client wanted to publicize it later. Currently it's pretty much a special solution but if you need upload progress, that code might provide you with some inspiration.

   Also I'm happy to help you with any implementation questions you might have.
5. 

   am262327
   Member
   Posted 11 years ago

   Okay so the time I set aside for this starts tomorrow and the following two weeks.

   >The first question is: Where do you store the video information? "media" table
   > would be the easiest as you could reuse all mechanisms
   > (e.g. storing the actual video).

   Is there some technical reason I couldn't use the media table? I assumed that the public upload would handle the storing for me already, that I would just be piggybacking some additional functionality.

   > Downsides: You'd get new media notification and possibly a lot of spam
   > media visible in the admin (even though not published).

   I don't think I'd get a lot of spam because I would restrict by domain.

   >Use media.meta to store additional data which you need for the confirmation.

   Okay, what about how do I connect the email reply to mediacore then?

   >Uploading a thumbnail: I'm not 100% sure but probably you could add a appropriate
   > field to the form using a plugin.

   Why is the public upload so different from the logged-in version?
6. 

   am262327
   Member
   Posted 11 years ago

   Okay, so I've spent a few hours and have gotten somewhere. I already figured out how to add the needed preferences using ToscaWidgets. The following now appear in the "Upload" section (and has appropriate validation):

   User uploads can be published via email confirmation:

   Enabled (checkbox)

   User upload requires email from specified domain(s):

   Enabled (checkbox)
   Invalid message (textfield)
   Domains (textarea, validation accomplished by overriding a Regex class)

   Also, in the unauthenticated user upload form, the "Your email" field has appropriate validation and checks to see that it matches one of the domains entered in the preference setting.

   I think, however, I have done something of an amateurish job of it, because while these admin settings are available in the response.settings dictionary (which I use to validate), I cannot get them to "stick" the first time -- that is, be saved when first entered, although once entered (sort of forcefully by restarting paster) they do get saved. So I must be missing something. Is this because I haven't given these settings default settings? Is there some interaction between these widgets and the app that would result in this behaviour?

   Now that I got the user interface for email confirmation, the next major thing is figuring out how to add actual email confirmation, which looks like is best to do by writing a plugin. Sends the user an email with a token key. I know for sure there's an event for new media item, but what about an event for having received an email from user? How would I go about registering that?

   I'll stick my nose in the pylons community and see if they have any ideas as well. Thanks.
7. 

   am262327
   Member
   Posted 11 years ago

   Just to let you know that I have got a working fork of mediacore that does much of what I described above. Although it still needs a bit of refactoring and error-checking added, it has already survived a day in the wild!
8. 

   Felix Schwarz
   MediaDrop developer
   Posted 11 years ago

   Adam: Thanks for sharing. Unfortunately I did not have the time yet to check out your code but I definitively will do so!

RSS feed for this topic

Reply

You must log in to post.