Moodle

Definitely! Please change the type of the issue from Improvement to Bug as it really is that. Just one question.

If "Existing files" (or Current files or whatever the final name would be) behaves as a repository, how will the user be able to delete a file? Does filepicker allows such operations in the right part of the window?

The "Used files" are all files that are carried along together with each forum post - if you backup forum and restore it on another server all those files will be available there.

Please note that you can not link the "Used files" outside of the current TinyMCE editor, it is a local file area only for one post, nothing else.

+1 for 2.1.

The only conflicting point is that the htmlarea or whatever should be immediately (eh, I wrote it perfectly, lol) refreshed to represent the current status in case of deletion of really used file (because the named "used files" tab isn't really used, but stored).

Ciao

Agree this is a good feature.

I would suggest changing the name from 'Used files' as I think this will confuse. Unfortunately I am having trouble thinking of a good solution that isn't quite long. Something like 'Files associated with this text area'. That's a bit long. Perhaps a tab like 'Current files' or 'Existing files' and then a single sentence below to explain once you actually click onto that tab, like:

'The list below shows all files that are already contained within this text area.'

(it's the 'within this text area' bit that is not obvious from the name...)

However I don't think this is a silver bullet - the behaviour when you upload a file with a name that already exists is not a pleasant interface and should ideally be improved even if this feature is in place.

One option for that would be to change the popup so it offers 'Rename' and 'Cancel' - the existing one just says 'ok' and dumps you out with no clue as to what to do. Rename is always what you want to do. Deleting the file and uploading again with the same name is a bad idea; you can't reuse the same name as cache will cause horrible confusion if you do that...

(btw I think it would be better if moodle automatically changed all file names upon upload so that if you upload frog.doc it would become frog.8ba0df34.doc, i.e. add 8 chars from the start of contenthash to ensure that if the file ever changes it will get a new name... but that's another issue.)

I agree that popup confirmation with rename/overwrite would be nice.

My point was that you may not decide easily if you do not know what files are there already, if there was a file manager you could simply delete the file and upload a new one.

There is a little internal problem, JS filepicker UI is used from the filepicker forms element too - in that case it should always be overwriting the file because only one is expected (at present it sometimes throws the error instead).

Our moodle 2.0.2 has been rendered unusable by this bug. All our course images broke on friday afternoon. we have no idea why, the images are still there in the recent file list but we cannot repair the links because choosing an existing file gives the file exists error.
The main concern is why every image link in all courses broke at once when nothing in the system changed that we know of.

Added UI Mockup: <2011-04-11 12.01>

Does the proposed solution allow used files to be deleted? Currently, once a file has been uploaded to an assignment, it can't be deleted. This is a significant disk space leak when large files are attached to assignments.

Brandon

The proposed solution allow to overwrite existing files or rename it.

imho, we really need a solution that allows delete them )
There can be thousands of those files, embedded in the labels, webpages, HTML blocks, etc, etc.

Elena
I totally agree with you, to manage all these files, we need to change a lot on current UI, it's planed on 2.1, but for now we need a temporary solution to handle the duplicated files.

ahh, ok. So it is on the roadmap already

Hi Dongsheng,

1) 'being' should be 'been' (x2) in :
$string['fileexistsdialog_editor'] = 'A file with that name has already being attached to the text you are editing.';
(and the next line too.)

2)abstract class repository { ...
should has_moodle_files() be abstracted as well ? if we're to depend on it, i think its better if we force the re-implementation onto the plugin developer.

3)i don't think so but just checking: draftfile_exists() ...
does $fs->get_file() actually retrieve the file into a short lived memory? (a really large file over NAS wouldn't perform well just for file exists test. especially in the while loop in get_unused_filename() )

4) append_suffix() : do we want to limit file name length anytime (file systems bc)? also, incrementing suffix will allow more names than appending suffix.

5) overwrite_existing_draftfile() : can we delete the first draftfile after the second draft file ($newfile) is created successfully? i mean if the $newfile fails to be created, would the original draft file be lost to moodle (for handling differently)? if itemid reuse is the problem, can we change the 'symlink' successfully before deleting the actual file.

6) not yet tested, will test and feedback soon.

1. Fixed
2. we shouldn't encourage people create repository plugin host moodle files, better to make it return false by default
3. not really, get_file only deals with db records
4.
5. changed the logic, if temp file exists successfully, old file will be deleted. Remember we need to delete the old file to release the file name, so it has to be before create_file_from_storedfile

4) i've just tried uploading during test (which is working so far!).
just wanted to note the very confusing situation : upload my test files called 'test.jpg' a few times then upload my 'test_2.jpg' has gotten me to a point i don't know which file is which :-D

ok all tested as per instructions.
(there was a glitch (broken img) while changing testing from uploading to using recent files using the same test file, but i can't reproduce it)

works for me!

Hi guys,

I've looked through this now and had a play with it.
It gets my +1 for integration, it is a big improvement to the way things were.
I did spot a couple of minor whitespace things within the JS changes however I am happy to fix them up during integration.
I'll talk with Eloy about it this afternoon and providing he is happy as well it will be integrated.

Cheers
Sam

Thanks Sam

Just noticed this issue got 40 votes!

Thanks Dongsheng, this has been integrated now.

Cheers
Sam

Yay and there was much rejoicing!

Just tested in the HTML editor as follows:

1. Create a new blog entry
2. In the blog entry body insert an image
3. Using the file picker upload a file test.jpg
4. Save changes
5. Create another new blog entry
6. In the blog entry body insert an image
7. In the file picker select recent files and then the file test.jpg

The insert/edit image dialogue box then has the image URL filled in as "undefined" which then results in a broken link if the image is inserted into the blog entry.

I've tried on the QA testing site and my local 2.0 site and obtain the same results. I don't get a dialogue box asking whether the file should be overwritten.

Sam or Dongsheng, please tell me what I am doing wrong in my testing, otherwise I will have to fail this issue.

Hi Helen

Aparup fixed it by reseting the browser cache.

Regards
Dongsheng

Sorry I have to fail this because resetting the browser cache does NOT fix this problem. I've updated the QA site from the integration server and tried Firefox and Chrome. The problem of an undefined image URL remains.

Please note that this problem occurs when attempting to use the same file in a NEW blog entry. If I try editing the original blog entry and adding the same file to it a second time then I obtain a different problem (using Chrome): after selecting the file, the file picker loading box appears on top of the insert/edit image box which appears on top of the file exists dialogue box.

Sam
I cannot reopen this issue from my end.
I just committed the fix on top of my branches.

Thanks for spotting that Helen and thanks for getting a quick fix Donghseng.
This is a very popular issue so I have integrated the fix immediately rather than revert this for next week.

Helen if you have a moment could you please test this again.

Cheers
Sam

I've tried the steps commented by Helen above, two different blog entries using the same image (uploaded in the fist entry and picked from recent in the second), and it has worked perfecty.

Then I've tried to add the same image twice in the same blog entry and I get the filepicker on top, with the spinning wheel image and, the overwrite dialog dimmed and behind.

Only if I close the filepicker and cancel the "add/edit image" dialog I can see the overwite dialog: "A file with that name has already been attached to the text you are editing, overwrite/rename/cancel".

Using Safari (Mac) here with all caches purged before testing.

Going to try in other browsers.

Working ok on Chrome (I get the overwrite dialog on top and all options - overwite, rename and cancel - seem to be working ok)

Working on FF too ok, going to clean all caches in safari and try again

Have cleaned all caches in Safari, disabled them, restarted it, purged again all moodle chaches + theme cache and I continue getting the same problem, the "overwrite dialog" is shown under (below) both the file picker and the "add/edit image" dialogs.

Attaching image (safari.png), ciao

Exactly same behavior with Safari & file managers, the "overwrite dialog" is shown below the file picker. Although if you move it, buttons work ok.

Confirmed same behavior with Safari on qa.moodle.net too.

safari screenshot

Oki, I'm passing this as far as it works under IE, FF and Chrome.

I've created MDL-27381 for the detected Safari problem. Would be hyper-cool to have it fixed before release tomorrow or, if not, in the minimum number of weeks (aka 1 )

Closing as fixed. Many thanks!

Plz, take a look to the Safari followup. It would be awesome if we can integrate it tomorrow, so 2.0.3 will get it working. If it's not possible for tomorrow... then ASAP. TIA!

This issue was NOT fixed sorry! You have hijacked my bug report with all the votes and fixed a different minor problem!!!!

I do not know who the moodle.com user was but changing "no management of files uploaded through tinymce filepicker" to "Handle duplicate files uploaded through filepicker" is completely wrong.

Please reopen this issue and change the title back.

It really sucks when folks hijack an issue and change the subject line.

+1 to clone in order to continue with the original issue in another place, keeping this as is now.

Yes, I agree it was an error to rename this issue. I'll clone a new one to cover file management.