Is your feature request related to a problem? Please describe.
While working on the export-all subnets feature (#104), I noticed that the current CSV importer is designed to handle a single subnet per file.
The importer (import_csv) reads subnet metadata once and then treats all remaining rows as IP address data for that subnet. Because of this, CSV files containing multiple subnet blocks (such as those produced by the export-all action) cannot be imported as a whole and may result in parsing errors.
Describe the solution you'd like
Extend the CSV import logic to support multiple subnet blocks within a single file, while keeping the existing CSV format unchanged.
The importer should iterate through the CSV sequentially and treat each subnet block independently. A subnet block is identified by the same structure already used for single-subnet imports (subnet metadata followed by IP address rows), with blank rows acting as delimiters between blocks.
For each subnet block, the importer should:
-read and create (or reuse) the subnet metadata,
-associate subsequent IP address rows with that subnet,
-stop IP parsing when a blank row or end-of-file is reached,
-continue processing the next subnet block until the file ends.
The updated behavior should remain backward compatible with existing single-subnet CSV files and handle trailing or extra blank lines gracefully.
Is your feature request related to a problem? Please describe.
While working on the export-all subnets feature (#104), I noticed that the current CSV importer is designed to handle a single subnet per file.
The importer (
import_csv) reads subnet metadata once and then treats all remaining rows as IP address data for that subnet. Because of this, CSV files containing multiple subnet blocks (such as those produced by the export-all action) cannot be imported as a whole and may result in parsing errors.Describe the solution you'd like
Extend the CSV import logic to support multiple subnet blocks within a single file, while keeping the existing CSV format unchanged.
The importer should iterate through the CSV sequentially and treat each subnet block independently. A subnet block is identified by the same structure already used for single-subnet imports (subnet metadata followed by IP address rows), with blank rows acting as delimiters between blocks.
For each subnet block, the importer should:
-read and create (or reuse) the subnet metadata,
-associate subsequent IP address rows with that subnet,
-stop IP parsing when a blank row or end-of-file is reached,
-continue processing the next subnet block until the file ends.
The updated behavior should remain backward compatible with existing single-subnet CSV files and handle trailing or extra blank lines gracefully.