Moving images around after batch upload [UNSOLVED] :( Moving images around after batch upload [UNSOLVED] :(
 

News:

CPG Release 1.6.26
Correct PHP8.2 issues with user and language managers.
Additional fixes for PHP 8.2
Correct PHP8 error with SMF 2.0 bridge.
Correct IPTC supplimental category parsing.
Download and info HERE

Main Menu

Moving images around after batch upload [UNSOLVED] :(

Started by RonS, April 28, 2005, 06:22:19 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

RonS

Hi,

I am so sorry if this has been asked/answered.... but I have looked and looked for an answer, but I must be using the wrong keywords in my searches.

I have integrated coppermine with my phpbb2 board, and all is working fine, or so it seems.  Great job folks!
Up until now, I have manually managed all the images on my site.  All manually/anonymously FTPd to a write-only incoming directory, then I take them, resize them, watermark them, sitck'em in an images directory and link'em up.

Here's my issue: I have about 1,000 images to batch load.  After that's done, I would like my phpBB-now-Coppermine members (also about 1,000 but purely coincidence) to be able to identify the photos that are theirs, and either move them into their own albums, or notify me as to their ownership and I'll be glad to do it for them.

For the life of me, I can't figure out how to move files between albums.  Am I going daft?  Ok, am I going daft more quickly than I previously believed?

Thanks in advance so much for your patientce and help.

-Ron.

PS and it's a big PS..... if anyone has a better idea on how to accomplish this task, I am ALL EARS/EYES/Whatever.  Just looking to hand back ownership to the members.  THANKS!

RonS

Anybody? 

Nobody has had to move images around? From one Album and/or Category and/or user's private album to another?

Is this posted in the wrong board here?

Any suggestions would be welcome and  welcomed.

Thanks.

Nibbler


RonS

First off, THANK YOU very much, Nibbler.  I sincerely appreciate you taking the time to point this out to me.  I truly searched and search for this info, and could NOT find it.  It's actually quite embarrassing.

secondly ... AAAAAHHHHHHHHHHHHHHHHRRRRRRRRRRRRGGGGGGGHHHHHHHHH!!!!  I can't believe I missed that.

Finally, it's a little strange that the button says "Edit Description" as that's what I assumed it did, naively so.  I obviously had no clue that you could accomplish 8 different functions under the heading "edit Description", and now that I look I see I can change other things under "Crop and Rotate", too.

Maybe those buttons ought to be changed in title to "Manage File" and "Manipulate Image" or some more accurate titles?
Not a complaint, just an observation.

Thanks again, Nibbler.  I had literally given up, and had formed an imperssion of CPG's management capabilities that was not very positive.

Nibbler

It's called 'Edit file information' in the next version :)

RonS

Actually, it doesn't do what I want at all with batch uploads :(((

I want to be able to move it into a member's personal folder.  It won't allow me to do that, the personal folders aren't in the list there.  Also, after applying edits, there's no confirmation or acknowlegement.
Those aren't bugs, but design and style issues, I'd guess.

However, if I batch uploded the picture into a user's album,  I think there are two "bugs" here. Sorry.

1) If I actually want to edit the description, or anything else with that button, it looks like it will move a photo OUT of that user's personal album, since there is not an option to keep it where it is in the current user's album, and
2) that user doesn't have permissions to edit the file that's in their own albumn.

Are these reported bugs?  Are they a batch upload problem, or an editing problem?  Which bug section? Off to report it.

[edit: Ok, looks like there is no dedicated bug reporting section to which regular users can post, and doesn't look like there's a section for edit support, so will this do?]

(I *HATE* when I feel so n00bish)

Tranz

If the album belongs the the user, why are you uploading to it? ??? Can you see why the gallery wasn't designed like that?

I see in your case that you have an existing gallery structure and want to replicate it after the fact. However, your situation is not a common one. Know what I mean? It's not a bug if it works the way it's supposed to but doesn't agree with your way of doing things.

RonS

Quote from: TranzNDance on May 05, 2005, 03:44:19 AM
If the album belongs the the user, why are you uploading to it? ??? Can you see why the gallery wasn't designed like that?

I see in your case that you have an existing gallery structure and want to replicate it after the fact. However, your situation is not a common one. Know what I mean? It's not a bug if it works the way it's supposed to but doesn't agree with your way of doing things.
At a minimum, it's either a bug that
1) an administrator can upload to a user's album and then the user not be able to edit it, or it's a bug that the administrator can upload to a user's album at all
2) that an administrator can upload a picture into a user's album, but not be able to modify it without moving it out of that album.

This is just common sense, no? Whether or not you feel it should be a feature of cpg, half of the functionality of that feature exists. It's a bug.  Why so defensive?  If I had a nickel for every bug I've written, I'd have at least a pocketful of change... just today!

However, I personally think it's a major shortcoming if THE administrator can't move photos between user albums, but I agree that's a design/features issue.  I think that the Admin needs to have flexibility to do anything with any of the files anywhere on his/her gallery, without resorting to coding against the database.  But that's just my opinion as a brand new user of coppermine.

I also think it's a shortcoming that only ADMINs have the ability to approve uploads.  I have the phpBB bridge installed, and have already modified CPG to allow my phpBB moderators to approve uploads.  Now I just have to find the time to integrate the functionality that I've written into editpic into the groupmgr code, so that it can be maintained via cpg.

I've also added a feature that displays "bbcode" for each image in the file info section.  The bbcode displayed differs based on the size of the original, as I like to limit the size of images embedded in my forum to 6" wide.  So if the pic is over the limit, and an intermediate file is used, the bbcode points to the intermediate "normal_" file, otherise it points to the original.  Pretty neat, and the forum members love the feature.  It also saves on a ton of explaining about which picture to point to in the [img] tags.

Too bad I don't have much time to offer right now, I'd really enjoy working on this project.

To answer your question as to if I could see why it wasn't designed that way, first off, again, if it was designed to not allow it, then it's not working.  If it was designed to allow it, it's not working.  Either way.  Secondly, how about the fact that a user can only upload 10 files max at a time, and there are timeout problems, and might ask an administrator to help with batch uploads of a bunch of files moved to the server in a more robust batch fashion?

Batch upload is a great feature, and I'd love to help to enhance it... as time permits perhaps I'll delve into the issues I have with it, but for right now, the importation of the 1,000+ images is on hold, but the users have added 103 files to the gallery already, and it's working well.

Thanks!

Joachim Müller

Quote from: RonS on May 05, 2005, 07:30:57 PM1) an administrator can upload to a user's album and then the user not be able to edit it, or it's a bug that the administrator can upload to a user's album at all
Please be carefull when shouting "bug": a bug is a failure of a feature that is supossed to work. What you are requesting is additional functionality, so the word "bug" just doesn't apply. Developers react quite "dense" if you shout bug, when the actual thing you want to accomplish is not a bug.

Quote from: RonS on May 05, 2005, 07:30:57 PMSecondly, how about the fact that a user can only upload 10 files max at a time, and there are timeout problems, and might ask an administrator to help with batch uploads of a bunch of files moved to the server in a more robust batch fashion?
If the server time-outs when a user uploads over http, it's the settings of your server that is to blame, not the architecture of coppermine. If you know your way around in coppermine's database, you can easily ftp-upload and batch-add files and then modify the db to make them "owned" by the user.

Quote from: RonS on May 05, 2005, 07:30:57 PMToo bad I don't have much time to offer right now, I'd really enjoy working on this project.
It's a pity that a lot of people keep requesting additional features and the only thing that keeps them from contributing is time. The coppermine devs of course have unlimited time at their disposal, and we love to code new features that we don't need for our galleries, but others (those who have oh so little time) need.

You have to understand that the version you use (cpg1.3.x) is an "old" version from a developer's point of view: we're busy working on new versions that actually have new features. A more granular permission system is scheduled for cpg2.x, and cpg1.4.x already has the option to let users retain control over pics that exist in public albums.

Joachim

RonS

Gaugau,
With all due respect, and I mean it, I started as a professional developer in the 80's, and was last a development manager. I know a bug when I see one, and I certainly know the difference between a bug report and a feature request.  I thought I clearly differentiated between the two in my post.

If one half of an application allows you to place a file somewhere that the rest of the application can't deal with, it's a bug.  Either the batch upload shouldn't allow the file to be place where edit can't handle it, or edit should be able to handle it.  BTW if the ADMIN puts the file into the user's album, the user DOES get an error message when they try to edit the pic, saying they don't have perms to do that.  It's not a bug to be unable to edit a pic that's in your own album that was put there by another part of the application?  I'm sorry, but I've tried to look at it six ways to Sunday, but the only way I can justify that is by calling it a feature that hasn't quite been finished yet!  That works for me! ;)

Also, both of you seem hung up on either "why would you want to place things in other's directories" or "the time limits need to be upped, or code against the database." The FAQs (Troubleshooting) in THIS SECTION specifically suggest that "If you are looking to upload in excess of 15 or 20 files at a time, you should consider the batch add process " and *I* specifically said I didn't want to code against the database.

I'm not looknig for an argument, but c'mon, this is common sense, no?

Anyway, I'm not impatient, I can wait for the next release, or until I've got time to work on the project.

QuoteThe coppermine devs of course have unlimited time at their disposal, and we love to code new features that we don't need for our galleries, but others (those who have oh so little time) need.
Ahhhh sarcasm. Ok!
<sarcasm>Apparently I've annoyed you.  Not my intent.  Sorry.  I know I have soooooo much time with nothing to do than come by here and specifically antagonize someone for absolutely no gain and no hope in making a friend to get him to prioritize my feature list.  </sarcasm>

Hey, lets be friends.  There really was no intent to insult or otherwise antagonize anyone, and I'm sorry if it came off that way.  K?

Joachim Müller

k, sorry - it was not my intent to attack you personally. The way permissions are handled now is there for "historical" reasons: the admin used to be incapable of uploading to a user's album. We changed this, as "admin should be able to do anything". However, there are some drawbacks in the way permssions are handled. For future versions of coppermine, there are already plans to change the permission system entirely.
You have to understand that from a developers point of view, cpg1.3.x is already "dead" - we won't change any functionality in the cpg1.3.x code. We're eager to release cpg1.4.x, so we can start working on the version that will come after it.

Peace!

GauGau