Skip alert type postsave during config sync and skip type of alert in block if not present

[andybroomfield]

Fix #251

During config sync operations, if creating a new alert banner type the visibility field will try to be created, even though that is part of config.

This checks if the isSyncing flag is set and skips over the postSave actions as we assume they are part of the config being imported.

[Adnan-cds]

Hi Andy,
Thanks for such a prompt response. I have tried the fix on both a fresh site and and existing site. This fix has resolved the issue with the visibility field. But the block config imports are still failing :( This is the final error message I am seeing on a fresh site:

In ConfigImportCommands.php line 324:                                                                                       
                                                                                                                              
    The import failed due to the following reasons:                                                                           
    Unexpected error during import with operation create for block.block.localgov_alert_banner_base: 'type_of_alert' not found                                                                 
    Unexpected error during import with operation create for block.block.localgov_alert_banner_scarfolk: 'type_of_alert' not found

[andybroomfield]

Thanks for testing @Adnan-cds
Not sure why the blocks would cause the issue, needs further investiagtion.
Are you installing the theme alongside the alert banner module in the config sync, or just the module on its own (localgov_base / scarfolk already installed)?

[Adnan-cds]

Are you installing the theme alongside the alert banner module in the config sync, or just the module on its own

Just the localgov_alert_banner module and its related configs. The themes got installed earlier as part of the localgov profile during a fresh site install.

[andybroomfield]

Just did a quick test and I noticed the type of alert field is installed after the block.

+------------+------------------------------------------------------------------------------+-----------+
|            | field.storage.localgov_alert_banner.visibility                               | Create    |
|            | field.storage.localgov_alert_banner.link                                     | Create    |
|            | localgov_alert_banner.localgov_alert_banner_type.localgov_alert_banner       | Create    |
|            | field.field.localgov_alert_banner.localgov_alert_banner.visibility           | Create    |
|            | field.field.localgov_alert_banner.localgov_alert_banner.link                 | Create    |
|            | block.block.localgov_alert_banner_base                                       | Create    |
|            | block.block.localgov_alert_banner_scarfolk                                   | Create    |
|            | field.storage.localgov_alert_banner.type_of_alert                            | Create    |
|            | field.field.localgov_alert_banner.localgov_alert_banner.type_of_alert        | Create    |

[andybroomfield]

@Adnan-cds I've posted an additional fix to try and address this. Its beacuse the type_of_alert field is not present when creating an instance of the alert banner block, as it's not imported yet. Although we need to look at the order, as its possible for users to delete the field (should they be able to?) then I've added a check to the sort in getCurrentBanners so it can be skipped over, alongside a test that confirms the banner block still loads and order is just date changed order.

This should allow your import to work, and then we can consider the issues this has raised.

[Adnan-cds]

Works for me. Many thanks for the prompt fix :)