Design decision on ticket #13223

[Igor Sobreira]

Hi,

I'm working on a patch for #13223 [1], but I need some help on how to proceed. The solution I would like to work on is to replace the "save as new" button  for a "clone object" link. This is how I understood the suggest on the ticket, and the way makes more sense to me.

I've started to create a clone_view() in admin, and submitted a prototype-not-yet-done patch, with the idea. When the user enables the "save_as" admin option (maybe change the name) a "save as new" *link* appears, which opens a <obj id>/clone/ view pre-filled data based on the object id from the url.

Any feedback would be welcome.

There is a drawback: file uploads would not work. The user would need to upload a new file (or the same). Maybe a new ticket would be better to find the best solution to this (#14760 !?). What I was planning to do is provide a template method called by clone_view() function where the user could copy the file on disk or do anything she wants regarding form filling on GET.

Thanks in advance,

Igor.

[1] https://code.djangoproject.com/ticket/13223

--
Igor Sobreira
www.igorsobreira.com

[Thomas Woolford]

Why would file uploads not work?
If the file has already been uploaded on the previous object, it will appear in the clone view.
Any files uploaded when the clone view is submitted will be uploaded on save and associated with the new object anyway.
It is perfectly valid for two DB rows to point at the same file because as soon as that file is re-uploaded it creates a new file instead of overwriting the old one anyway (unless the user has provided a custom file path handler in which case it is the user's problem).

[Juan Pablo Martínez]

On Tue, Feb 21, 2012 at 10:55 PM, Thomas Woolford <rocker....@gmail.com> wrote:

Any files uploaded when the clone view is submitted will be uploaded on save and associated with the new object anyway.

It is perfectly valid for two DB rows to point at the same file because as soon as that file is re-uploaded it creates a new file instead of overwriting the old one anyway

But this behaviour doesn't represent all cases. In some cases, the users could be want to "clone" in a full copy and a representation of files too and NOT link to
the pre-existing files of the other/s objects.

This mean that if I change the "origin" object file, the cloned/s objects will change their links too?

The obviously behaviour will be to copy another file on the server and associate it with this new object and be consistent with the default admin functionality.

Regards,
--
juanpex

[Igor Sobreira]

On Wednesday, February 22, 2012 2:34:38 AM UTC-2, juanpex wrote:

On Tue, Feb 21, 2012 at 10:55 PM, Thomas Woolford wrote:

Any files uploaded when the clone view is submitted will be uploaded on save and associated with the new object anyway.

It is perfectly valid for two DB rows to point at the same file because as soon as that file is re-uploaded it creates a new file instead of overwriting the old one anyway

But this behaviour doesn't represent all cases. In some cases, the users could be want to "clone" in a full copy and a representation of files too and NOT link to
the pre-existing files of the other/s objects.

Yes, that's what I wanted to say. We can decide that this behavior is fine by default, document it, and provide an easy way (with callback and helper functions) to allow the user to clone the file on disk.

 

This mean that if I change the "origin" object file, the cloned/s objects will change their links too?

The obviously behaviour will be to copy another file on the server and associate it with this new object and be consistent with the default admin functionality.

Regards,
--
juanpex

-- 

Igor Sobreira 

[Juan Pablo Martínez]

That's it. I only identify this 2 behaviour.

Now, the question is: when and where put this decision the user?

A like ligthbox before copy on click button "clone"?, or in the new page displaying the cloned object?

I don't know :)

Regards,

On Wed, Feb 22, 2012 at 11:53 AM, Igor Sobreira <ig...@igorsobreira.com> wrote:

Yes, that's what I wanted to say. We can decide that this behavior is fine by default, document it, and provide an easy way (with callback and helper functions) to allow the user to clone the file on disk.

--
juanpex

[Igor Sobreira]

When I said "user", I actually meant "developer", "django user"... sorry for the confusion :]

When pre-filling the form to display the "clone" page we can provide a method the developer can override to copy the files on disk, or change anything he wants (for example, change unique fields like slug, since the user will have to edit anyway)

But it's possible to implement as Thomas suggested, just provide a new reference for the same file on disk by default, and let the developer choose to copy or not. I'll work on an implementation for this.

Thanks for the feedback!

Igor.

On Wednesday, February 22, 2012 12:04:12 PM UTC-2, juanpex wrote:

That's it. I only identify this 2 behaviour.

Now, the question is: when and where put this decision the user?

A like ligthbox before copy on click button "clone"?, or in the new page displaying the cloned object?

I don't know :)

Regards,