openupload-devel

[openupload-devel] A way for admins to see/download uploaded files?

[Terry H. <dig...@gm...>]

Hi!

I've only recently installed OpenUpload, and my first reaction to it
is very positive. This is a nice package, and it looks like it's going
to be very useful. It also seems to have a pretty well-thought-out
installer (reminds me of Mediawiki's installation).

My only serious problem is that it seems really awkward for me to
download the files that have been submitted.

We're using OpenUpload to receive submissions of large files (mostly
audio recordings in FLAC or WAV format) to our project.

There is one problem with this, though: the package doesn't seem to
give the administrator direct access to download the files that are
uploaded. If the submitters remember to email to the correct address,
I get a download link, but otherwise, I have to use some kind of
work-around to "trick" the program into letting me have access.

For example, I can ask the submitter for their password so I can log
in as them and visit "my files" to download their submission.

Or, in a pinch, I could use my admin privileges to _change_ their
password and then log in as them (but then, I'd be messing up their
account).

As an admin, I can look at the record of uploaded files. And I can
even delete them off of the server. But I can't actually seem to visit
their download pages or download them. Which seems really
counter-intuitive to me.

Is there a more direct way to do this? Was this an intentional
omission? Is there a way to enable admins to access all of the
downloads?

Thanks for any help,
Terry

--
Terry Hancock
Producer/Director - "Lunatics" Project - http://lunatics.tv

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Alessandro B. <ts...@br...>]

Il 18/09/2012 03:50, Terry Hancock ha scritto:
> Hi!
>
> I've only recently installed OpenUpload, and my first reaction to it
> is very positive. This is a nice package, and it looks like it's going
> to be very useful. It also seems to have a pretty well-thought-out
> installer (reminds me of Mediawiki's installation).
>
> My only serious problem is that it seems really awkward for me to
> download the files that have been submitted.
>
> We're using OpenUpload to receive submissions of large files (mostly
> audio recordings in FLAC or WAV format) to our project.
>
> There is one problem with this, though: the package doesn't seem to
> give the administrator direct access to download the files that are
> uploaded. If the submitters remember to email to the correct address,
> I get a download link, but otherwise, I have to use some kind of
> work-around to "trick" the program into letting me have access.
>
> For example, I can ask the submitter for their password so I can log
> in as them and visit "my files" to download their submission.
>
> Or, in a pinch, I could use my admin privileges to_change_  their
> password and then log in as them (but then, I'd be messing up their
> account).
>
> As an admin, I can look at the record of uploaded files. And I can
> even delete them off of the server. But I can't actually seem to visit
> their download pages or download them. Which seems really
> counter-intuitive to me.
>
> Is there a more direct way to do this? Was this an intentional
> omission? Is there a way to enable admins to access all of the
> downloads?
>
> Thanks for any help,
> Terry

Hello Terry,
this was discussed some time ago, and it's a very easy change that has 
to be made to the template which lists the files in the admin interface.

this should give you the right info to acomplish it (check the exact 
html behind it, I guess migration changed it a bit).

From:
https://sourceforge.net/tracker/index.php?func=detail&aid=2715256&group_id=242018&atid=1117807

----------------------------
In the file templates/default/modules/admin/files.tpl line 40:
old: {$f.id}
new: <a href="../{$script}?action=d&amp;id={$f.id}">{$f.id}</a>
----------------------------

Hope it helps,
Alessandro

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Terry H. <dig...@gm...>]

On Tue, Sep 18, 2012 at 3:47 AM, Alessandro Briosi <ts...@br...> wrote:
> Il 18/09/2012 03:50, Terry Hancock ha scritto:
>>  Is there a way to enable admins to access all of the
>> downloads?

> this was discussed some time ago, and it's a very easy change that has
> to be made to the template which lists the files in the admin interface.
>
> this should give you the right info to acomplish it (check the exact
> html behind it, I guess migration changed it a bit).
>
> From:
> https://sourceforge.net/tracker/index.php?func=detail&aid=2715256&group_id=242018&atid=1117807
>
> ----------------------------
> In the file templates/default/modules/admin/files.tpl line 40:
> old: {$f.id}
> new: <a href="../{$script}?action=d&amp;id={$f.id}">{$f.id}</a>
> ----------------------------

Thank you! I'll attempt it and report back how it worked out. :-)

Cheers,
Terry

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Terry H. <dig...@gm...>]

On Tue, Sep 18, 2012 at 10:12 AM, Terry Hancock <dig...@gm...> wrote:
> On Tue, Sep 18, 2012 at 3:47 AM, Alessandro Briosi <ts...@br...> wrote:
>> Il 18/09/2012 03:50, Terry Hancock ha scritto:
>>>  Is there a way to enable admins to access all of the
>>> downloads?
>
>> this was discussed some time ago, and it's a very easy change that has
>> to be made to the template which lists the files in the admin interface.
>>
>> this should give you the right info to acomplish it (check the exact
>> html behind it, I guess migration changed it a bit).
>>
>> From:
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2715256&group_id=242018&atid=1117807
>>
>> ----------------------------
>> In the file templates/default/modules/admin/files.tpl line 40:
>> old: {$f.id}
>> new: <a href="../{$script}?action=d&amp;id={$f.id}">{$f.id}</a>
>> ----------------------------
>
> Thank you! I'll attempt it and report back how it worked out. :-)

Okay, that works well enough for me.

Couple of comments:

1) Doesn't quite work right with multi-file feature

I have my preferences set to allow sets of 3 files to be uploaded. I
may even want to increase this. But this patch creates false links for
all but the first file. I can just remember that, but it probably
ought to be revised before becoming a regular feature.

2) However, I think it SHOULD be a regular feature (here, I'm
responding partly to the discussion on the link you referenced).

As an administrator, I expect to be able to inspect what's on my own
server. And it was not at all easy for me to figure out how to get the
correct URL (I made attempts at manually constructing them or using
the same links the users have to them, and kept getting errors). So,
it's very useful to have a proper link.

So here's my "case" for supporting this... :-)

I think that if you consider what would motivate someone to install
their own dropbox service instead of just using an existing service,
it's quite likely that many would be in my situation:

The reason I wanted to run my dropbox, is because I want to accept
submissions from people -- so I want to be able to give them an easy
way to upload files to my server, so I can download them. The e-mail
notification is useful, but it shouldn't be critical. If I find out
out-of-channel that they have submitted a file or I just check
periodically for uploads, then I should just be able to go in as
administrator and download the files.

A major reason for doing this, as opposed to using higher-buy-in
services like Subversion or Sparkleshare (where the user needs to
install and use client software), is that I'm dealing with people who
1) may not have regular contact with my project (this may be our only
interaction) and 2) may not have much computer skill (so forgetting to
send an email is probable). And because of (1), there's not much
opportunity to rectify (2).

So a common case would be a book publisher or a record label or (like
me) a multimedia project. These users all need to handle files that
are too big to comfortably send as email attachments -- and they're
all basically a case of a centralized "user" receiving files from
outside "submitters" (rather than a "service bureau" facilitating
transfers between "user/senders", which is what I think you are
optimized for).

I'm sure there are people using the other case, but I think my
situation is useful, probably pretty common, and OpenUpload can serve
it as well without a lot of fuss.

Anyway -- that's just my thoughts on the matter, submitted in the hope
of being useful to you.

Also, FWIW, I'm probably going to write a brief review of OpenUpload
for Free Software Magazine. I haven't seen much about it -- seems very
worthy of a mention.

My immediate problem is solved. So thank you very much!

Cheers,
Terry

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Alessandro B. <ts...@br...>]

Il 18/09/2012 17:55, Terry Hancock ha scritto:
> On Tue, Sep 18, 2012 at 10:12 AM, Terry Hancock <dig...@gm...> wrote:
>> On Tue, Sep 18, 2012 at 3:47 AM, Alessandro Briosi <ts...@br...> wrote:
>>> Il 18/09/2012 03:50, Terry Hancock ha scritto:
>>>>   Is there a way to enable admins to access all of the
>>>> downloads?
>>
>>> this was discussed some time ago, and it's a very easy change that has
>>> to be made to the template which lists the files in the admin interface.
>>>
>>> this should give you the right info to acomplish it (check the exact
>>> html behind it, I guess migration changed it a bit).
>>>
>>> From:
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2715256&group_id=242018&atid=1117807
>>>
>>> ----------------------------
>>> In the file templates/default/modules/admin/files.tpl line 40:
>>> old: {$f.id}
>>> new: <a href="../{$script}?action=d&amp;id={$f.id}">{$f.id}</a>
>>> ----------------------------
>>
>> Thank you! I'll attempt it and report back how it worked out. :-)
>
> Okay, that works well enough for me.
>
> Couple of comments:
>
> 1) Doesn't quite work right with multi-file feature
>
> I have my preferences set to allow sets of 3 files to be uploaded. I
> may even want to increase this. But this patch creates false links for
> all but the first file. I can just remember that, but it probably
> ought to be revised before becoming a regular feature.
>
> 2) However, I think it SHOULD be a regular feature (here, I'm
> responding partly to the discussion on the link you referenced).
>
> As an administrator, I expect to be able to inspect what's on my own
> server. And it was not at all easy for me to figure out how to get the
> correct URL (I made attempts at manually constructing them or using
> the same links the users have to them, and kept getting errors). So,
> it's very useful to have a proper link.
>
> So here's my "case" for supporting this... :-)
>
> I think that if you consider what would motivate someone to install
> their own dropbox service instead of just using an existing service,
> it's quite likely that many would be in my situation:
>
> The reason I wanted to run my dropbox, is because I want to accept
> submissions from people -- so I want to be able to give them an easy
> way to upload files to my server, so I can download them. The e-mail
> notification is useful, but it shouldn't be critical. If I find out
> out-of-channel that they have submitted a file or I just check
> periodically for uploads, then I should just be able to go in as
> administrator and download the files.
>
> A major reason for doing this, as opposed to using higher-buy-in
> services like Subversion or Sparkleshare (where the user needs to
> install and use client software), is that I'm dealing with people who
> 1) may not have regular contact with my project (this may be our only
> interaction) and 2) may not have much computer skill (so forgetting to
> send an email is probable). And because of (1), there's not much
> opportunity to rectify (2).
>
> So a common case would be a book publisher or a record label or (like
> me) a multimedia project. These users all need to handle files that
> are too big to comfortably send as email attachments -- and they're
> all basically a case of a centralized "user" receiving files from
> outside "submitters" (rather than a "service bureau" facilitating
> transfers between "user/senders", which is what I think you are
> optimized for).
>
> I'm sure there are people using the other case, but I think my
> situation is useful, probably pretty common, and OpenUpload can serve
> it as well without a lot of fuss.
>
> Anyway -- that's just my thoughts on the matter, submitted in the hope
> of being useful to you.
>
> Also, FWIW, I'm probably going to write a brief review of OpenUpload
> for Free Software Magazine. I haven't seen much about it -- seems very
> worthy of a mention.
>
> My immediate problem is solved. So thank you very much!
>

Actually I don't really understand how this does affect multifile 
uploads. It should present the page for downloading (with the 
restrictions if it applies) and then the files should be there, (ould be 
wrong)

In the long awaited 0.5 version which is in svn (not complete yet) there 
is a feature which is the "invitation" which pretty much solves what you 
want.

You might want to try that version, there are a couple of guides on the 
internet which talk how to install it.

Alessandro

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Terry H. <dig...@gm...>]

Hi Alessandro,

On Wed, Sep 19, 2012 at 2:57 AM, Alessandro Briosi <ts...@br...> wrote:
> Actually I don't really understand how this does affect multifile
> uploads. It should present the page for downloading (with the
> restrictions if it applies) and then the files should be there, (ould be
> wrong)

If the first file has a hash name, ike "WY45xdew", then the 2nd will
have a name like  "WY45xdew_2". But the URL from that doesn't exist
(only the earlier one -- although both files can be found there).

With this change, though, it works well enough for oru purposes.

Cheers,
Terry

Re: [openupload-devel] A way for admins to see/download uploaded files?

[Alessandro B. <ts...@br...>]

Il 19/09/2012 10:07, Terry Hancock ha scritto:
> If the first file has a hash name, ike "WY45xdew", then the 2nd will
> have a name like  "WY45xdew_2". But the URL from that doesn't exist
> (only the earlier one -- although both files can be found there).
>
> With this change, though, it works well enough for oru purposes.
>
> Cheers,
> Terry

maybe try substituting the a=d or action=d with action=i or a=i in the link

Alessandro