d4f9fa1 frontend: move repos_info generation logic to a separate class

4 files Authored by frostyx 2 years ago, Committed by praiskup 2 years ago,
    frontend: move repos_info generation logic to a separate class
    
    Fix #1816
    
    I started working on the #1816 but the code was too unreadable for me
    because the `repos_info` generation consists of a whole lot of logic
    to be done within one view function. I refactored the code and moved
    it to a separate `ReposLogic` class. Unfortunatelly I did it in the
    middle of fixing #1816 so the change is lost in this larger commit.
    
    > It says "This chroot is EOL ..." though e.g. the epel-7-aarch64 is
    > EOL, while epel-7-x86_64 is not yet
    
    This was caused by the fact, that we iterated over all chroots but
    only generated the whole repository information for each
    `name_release` combination. So it depended which architecture we took
    first and generated the reason why it is deleted based solely on it.
    
    Moreover, if the first architecture of a given `name_release` wasn't
    going to be deleted, the trash icon didn't appear at all.
    
    I adjusted the logic so all the chroots are considered.
    
    > We should really state that only particular arch is going to be
    > removed.
    
    I added the list of architectures that are going to be deleted into
    the message.
    
        
  • Zuul
    success
    Jobs result is success
    2 years ago
  • Copr build
    success (100%)
    #2344342
    2 years ago
  • Copr build
    failure
    #2344332
    2 years ago