Change how we rename filenames for talks, pubs, and posters

[jonfroehlich]

Right now, we are using m2m_changed.connect to rename talk, poster, and publication files, which is only triggered when an author (or speaker) is changed on a file. But this doesn't trigger when another field is updated. And, generally, talks, posters, and publication filenames are based on:

• First author
• Title
• Venue + Year

So, really, we should trigger a change when any of these are updated.

Second, it seems to me that we may want to try a different strategy to rename the initial file based on these fields, like:

• http://www.learningaboutelectronics.com/Articles/How-to-rename-an-image-or-file-in-an-upload-Django.php
• https://www.reddit.com/r/django/comments/31pr88/how_does_django_handle_file_names_for/

[jonfroehlich]

Moreover, while we are renaming the pdf files, we are not appropriately renaming the raw files (e.g., the pptx or ai files)

[jonfroehlich]

This is related to #1052 and a similar implementation should work

[jonfroehlich]

More here.

I asked chat.bing.com

What's the difference between adding in m2m_changed as I do below and overriding the def save(self, *args, **kwargs) save function for a Django model class?

def update_file_name_poster(sender, instance, action, reverse, **kwargs):
    # Reverse: Indicates which side of the relation is updated (i.e., if it is the forward or reverse relation that is being modified)
    # Action: A string indicating the type of update that is done on the relation.
    # post_add: Sent after one or more objects are added to the relation
    if action == 'post_add' and not reverse:

         # Convert metadata into a filename
        new_filename_no_ext = ml_fileutils.get_filename_without_ext_for_artifact(
            instance.get_person().last_name, instance.title, instance.forum_name,
            instance.date)
        
        # Rename the database entry and file on filesystem
        if instance.pdf_file:
            new_pdf_filename_with_path = ml_fileutils.rename(instance.pdf_file, new_filename_no_ext)
            if new_pdf_filename_with_path is not None:
                instance.save()
        
        # Rename the database entry and file on filesystem
        if instance.raw_file:
            new_raw_filename_with_path = ml_fileutils.rename(instance.raw_file, new_filename_no_ext)
            if new_raw_filename_with_path is not None:
                instance.save()

m2m_changed.connect(update_file_name_poster, sender=Poster.authors.through)

Bing's response.

The m2m_changed signal and the save method in Django serve different purposes and are used in different scenarios.

The m2m_changed signal is sent when a ManyToManyField on a model is changed. It's useful when you want to perform some action specifically when the many-to-many field changes. In your case, you're using it to update the file name of a Poster instance when the authors field changes.

On the other hand, overriding the save method of a model allows you to add custom behavior to the save process. The save method is called every time an instance of a model is saved. If you override this method, your custom code will run every time an instance is saved, regardless of what field was changed.

So, the main difference is:

• Use m2m_changed when you want to do something specifically when a many-to-many field changes.
• Override save when you want to do something every time an instance of a model is saved, regardless of what field changed.

In your case, if you moved the file renaming logic to the save method, it would run every time any field on the Poster model is saved, not just when authors changes. This might not be what you want if, for example, updating the title field should not rename the file. So, using m2m_changed seems appropriate here. However, if you want the files to be renamed every time any change is made to the Poster instance, then moving this logic to the save method would make sense.

Remember, it's important to call super().save(*args, **kwargs) at the end of your custom save method to ensure that the save operation is completed properly. If you don't, Django won't actually save your object to the database.

Here's an example of how you might override the save method:

class Poster(models.Model):
    # fields here

    def save(self, *args, **kwargs):
        # your custom save code here

        # don't forget this!
        super().save(*args, **kwargs)

I hope this helps! Let me know if you have any other questions.

My followup:

Would m2m_changed get triggered if I changed that value in a different admin interface. For example, if I changed the person's name?

The m2m_changed signal is specifically tied to changes in the ManyToManyField on a model. If you change a person's name through the admin interface or any other interface, the m2m_changed signal for the authors field in the Poster model will not be triggered because the authors field itself is not being modified.

However, if you modify the set of authors for a Poster instance (i.e., add, remove, or clear authors), then the m2m_changed signal would be triggered, regardless of where you make the change (admin interface, Django shell, view function, etc.).

If you want to perform some action when a related object (like a Person instance) is changed, you might want to use Django's post_save signal for the Person model instead. This signal is sent every time a Person instance is saved. Here's an example:

from django.db.models.signals import post_save
from django.dispatch import receiver
from myapp.models import Person

@receiver(post_save, sender=Person)
def update_poster_on_person_save(sender, instance, **kwargs):
    # Your code here. `instance` is the Person instance being saved.

In this code, update_poster_on_person_save will be called every time a Person instance is saved. You can put your file renaming logic here if you want it to run when a person's name is changed. Note that you'll need to get the related Poster instances from the Person instance.

Remember, signals are a somewhat advanced feature of Django and can make your code harder to follow if overused. It's often better to call a function explicitly when you want something to happen, rather than relying on signals. But they can be very useful for certain tasks, like the one you're doing.

I hope this helps! Let me know if you have any other questions.

[jonfroehlich]

This ended up being a very large undertaking—in part because of how Django handles m2m fields—and required lots of experimentation and testing. I eventually arrived at a solution, which is now captured in this branch https://github.com/makeabilitylab/makeabilitylabwebsite/tree/add-artifact-abstract-class-and-update-talks-posters-and-pubs.

I captured a ticket to handle this here: #1098

[jonfroehlich]

This is now done. Wo0t! 🎉

See: #1098