FIX: Update model class importer key

[mikenuguid]

Description

Using a custom URL slug throws an exception due to non-existing key equivalent to the model class. Using model tab solves this since it utilises either the custom url slug or the fully-qualified name of the class as key on the model importers.

This fixes the undefined array key exception e.g. [Warning] Undefined array key "Sheadawson\Linkable\Models\Link" seen when importing on a model admin with a custom URL slug.

This should not have any regressions on model admins without custom slug.

Code clean-up on a test suite.

Manual testing steps

With custom url slug

1. Add a model admin and model class e.g.: ContactAdmin and Contact (model admin and model, respectively).

2. Assign a custom slug to the model admin e.g.:

   class ContactAdmin extends ModelAdmin
   {
       private static $url_segment = 'contactadmin';
   
       private static $managed_models = [
          'contacts' => [
               'dataClass' => Contact::class,
               'title' => 'Contacts',
           ]
       ];
   
   // ...
   }

3. Once setup and viewable on the CMS, go to the ContactAdmin landing page on the CMS and import a file to populate the model. (Note: this can also be done by pre-populating the model and exporting the records as .csv file then re-uploading the same file via import)

4. Import should not cause any exception.

Without custom url slug

Follow same steps above but do not assign a custom slug to the model admin i.e.

class ContactAdmin extends ModelAdmin
{
    private static $url_segment = 'contactadmin';

    private static $managed_models = [
       Contact::class,
    ];

//...
}

Using the import form should not generate any errors.

Issues

• Exception seen when importing from custom URL slug #1680

Pull request checklist

• The target branch is correct
  • See picking the right version
• All commits are relevant to the purpose of the PR (e.g. no debug statements, unrelated refactoring, or arbitrary linting)
  • Small amounts of additional linting are usually okay, but if it makes it hard to concentrate on the relevant changes, ask for the unrelated changes to be reverted, and submitted as a separate PR.
• The commit messages follow our commit message guidelines
• The PR follows our contribution guidelines
• Code changes follow our coding conventions
• This change is covered with tests (or tests aren't necessary for this change)
• Any relevant User Help/Developer documentation is updated; for impactful changes, information is added to the changelog for the intended release
• CI is green

[GuySartorelli]

CMS 4 has entered its security-only support phase, and won't be getting any new patch releases. Please target the 2.2 branch (assuming this affects CMS 5)

[mikenuguid]

Is it fine to re-use the same branch name (and target 2.2)? Or do I need to create a new pull request?

[GuySartorelli]

If you retarget to 2.2 and there are more commits than your original one displayed at the top of the PR, you may need to reset your commits - but you don't have to make a new PR unless that's easier for you.

[mikenuguid]

Marked this ready for review but some jobs on workflow still failing, do I need to re-run them until green?

[GuySartorelli]

CI is green here: https://github.com/silverstripe/silverstripe-admin/actions/runs/9008788626
But it's not appearing in this PR for some reason, which is concerning. Can you please force a push so CI shows up correctly? Sometimes GitHub needs a nudge.

You can force a push without making any changes by running git commit --amend --no-edit && git push --force-with-lease

[GuySartorelli]

Works well locally. Looks like there's no unit test for the import() method so I won't ask you to add that now.

Thank you for implementing this fix