FileField and ImageField return the wrong path/url before calling save_FOO_file()

Sorry for not explaining this properly already, but the fs-rf-fixed keyword on this ticket indicates that this fix has already been rolled into #5361.

added tests for previous patch

Malcolm reviewed.

(In [7986]) Fixed #5619 -- Return the same path in get_FOO_filename() before and after a model is saved (i.e. make sure the upload prefix is prepended in both cases).

Patch from wreese@gmail.com. Tests from Leah Culver.

This patch is totally broken, and breaks get_FIELD_url for all files or images uploaded prior to the current day, because field.get_directory_name uses datetime.now() to interpolate the date values. [7986] needs to be reverted as soon as possible.

You do know you can get your own copy reverted back to pre-7986 by doing something like:

svn -r7985 up

right? So you can get your code back to working immediately without the change actually being reverted instantaneously.

Of course, already done - but only after too much time spent looking for the problem. Not trying to be a pain, just trying to save others the same hassle.

Since you've already opened another ticket (#7843) for the new bug, how about now also reopening this one (which does fix another problem)? It only requires one ticket. I'm sorry it's had an unintended side-effect and I'll look at it very shortly, but for now, just use an earlier revision for a little bit.

My bad - guess I assumed that that if the fix here wasn't workable, this ticket would still need attention as well. Sorry for the hassle.

you could have reopened this. There's just no need for two tickets (the fix here needs changing, not reverting, since it fixes a real problem, as can be seen from the patch). Anyway, we're on the same page now. It'll be fixed soon.

(In [7998]) Reverted [7986].

It turns out that we need to treat filename creation/display (in particular, the upload_to path) differently depending upon whether the value is out of the database or provided by other code and there's no reliable way to determine that at the moment (although some later proposed changes might alter that). So calling get_FIELD_filename on an unsaved model with a changed file attribute will not necessarily return the same result as after the save().

Refs #5619. Fixed #7843.

(In [7999]) Added a cavaet to the use of get_FOO_filename() and get_FOO_url(). This constraint has always existed, but it's very hard to fix in the current code, so better to work around it for now.

Refs #5619

As noted in the above commits, there are technical reasons why it's not really possible to fix this in a straightforward fashion. Tracking when an attribute is updated by code (as opposed to a database read) is something we might add in the future, in which case, this problem could be addressed at that point. For now, the simplest and practical solution is "don't do that". The model is going to be saved in any case, so save it first, then read off the filename.

Reopening and moving to Someday/Maybe.

Yeah, I'm actually not sure now why I had put fs-rf-fixed on this one. When I add Leah's tests to the #5361 patch, it fails quite reliably, so it's clearly still an issue. I'll keep it in my head and see what happens if/when we get that potential future differentiation between db-load and otherwise. Removing all fs-rf tags, as well as the 1.0 beta milestone, since it clearly won't get taken care of in the immediate future.

The one thing I'd note on this is that the docs probably shouldn't say "*if* you are using upload_to," since it's actually a required argument on all FileFields. That requirement isn't going away after #5361 either, so it's still important to make it clear.