I am not quite sure if this is the right project for this report.

I am running migrations through drush and the last_imported column in the map tables is 0 for all of them.

Hi,

in the current version of drupal 7.x it's not possible to extend the taxonomy_autocomplete results with custom callbacks, due to the drupal json_output rendering.

How could this be implemented ?

best regards.

Problem/Motivation

Now that jQuery 3.0 has been released jQuery 2.x will only be receiving security updates. I know what we've had discussions about updating specific libraries in the past. But there are a few compelling reasons why we should consider updating jQuery to 3.x

Support for JavaScript Promises: This could potentially make a large change in the readability / programming of deferred actions / behaviors.
Better error reporting: Apparently jQuery has add a number of actions that silently failed in the past, now fewer of those silently fail.
Let's make a statement that Drupal doesn't get stuck in the past with JavaScript libraries any more: A key problem with Drupal in the past is that we didn't want to break core by updating jQuery but that led to all kinds of hacks that we had to rely on in cases where we needed to update the library. Let's move forward now that we have semantic versioning.
References:
https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/

Proposed resolution

- A POC with jQuery3 naively applied can be made to actually evaluate the issues with it. (it may take to wait for jQueryUI to be compatible ?)
- Considering to remove deprecated APIs in current 2.x before other libs supports catch up.

The query that Migrate's SqlBase source class produces doesn't appear to have any order applied.

For example, in my source D6 database, my nodes of type foo start at nid 14614, and run to nid 95771. But when I migrate a single node, it's nid 75396 that comes through.

This is rather confusing!

Problem/Motivation

Proposed resolution

Remaining tasks

User interface changes

API changes

Original report by @catch

If you want to change the path alias for a user, you have to first find the user and their uid then go into the path admin interface, find the alias, then edit it. This takes ages.

We should add a path alias form to the user edit screen if path module is enabled - same as is currently done for nodes.

Problem/Motivation

In Drupal 6, you can use the I18n Taxonomy module to translate a taxonomy vocabulary and taxonomy terms.

At this time, they cannot be migrated into Drupal 8. If you have a Drupal 6 site with this setup, you get the English terms migrated in, and the English name for the vocabulary, but the translations are not migrated.

Note that #2784371: Migrate D6 i18n taxonomy term language (but not yet translations) migrated term language, and #2225781: Migrate D6 i18n taxonomy vocabularies migrated vocabulary language, but neither of them migrated translations. Also, once this is done, we can look at also making sure the translated nodes get the translated taxonomy terms, on #2859297: Migrate d6 translated nodes with translated taxonomy.

Proposed resolution

Migrate taxonomy vocabulary and term translations.

Remaining tasks

User interface changes

API changes

Data model changes

https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...

Current description is confusing.

Does the style plugin allows to use style plugins.

It appears that the description was copied to some derived plugins (Table).

Beta phase evaluation

Original description

Currently the form cache has a lifetime of 6 hours by default.
I'd like to see the possibility to define a cache lifetime by using relative date formats like in php's strtotime.
Further it would be nice to be able to set the form cache expiration per form - e.g. with $form_state['cache_expire'] (Another solution could be to store this information straight into $form_state['cache'])

The goal I've in mind is to be able to get the lifetime of the page cache and the form cache in sync (The page cache is a whole different story ;) )
The scenario I think of is a website where all the pages, including the forms on it, are cacheable until tomorrow (midnight). But if the form cache is cleared before the page cache things break e.g. the ajax magic.

The attached patch contains the changes needed to introduce a custom form lifetime. The setting can be found in admin/config/development/performance .

Problem/Motivation

Maintainers of distributions and themes have pointed out that there is some bleed through of css from themes into the settings tray, which can significantly impact experience and usability.

We did #2853208: [META] Determine best method ensure consistent theming of Off Canvas Tray
Which involved this issue and #2853222: Explore using an IFrame to sandbox CSS for the Off Canvas tray

It was determined that iframe though it would provide better CSS isolation it would introduce its own problems to solve.

Proposed resolution

Add an aggressive CSS reset to the off-canvas tray to the module that will to the extent possible offer a uniform look when using the tray across different themes.

No CSS reset will ever be absolute because we can't control the CSS used on a sites current theme.

Since we decided not do #2847522: Allow off-canvas links to be rendered by either "default" or "admin" renderer there does not need to be a different look for the off-canvas tray when used by the Settings Tray module and other uses of the tray.

This module provides 2 libraries drupal.off_canvas and drupal.outside_in.

The CSS reset and other CSS related to the tray should be contained within the CSS files of the drupal.off_canvas and should follow the off-canvas.*.css naming pattern.
The drupal.off_canvas library will be moved out of the Settings Tray module in #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it

The drupal.outside_in library should not contain CSS that deals with tray. It should contain CSS that deals with other functionality of the Setting Tray module such as toolbar, highlighting regions, etc.

Remaining tasks

Test the patch.

User interface changes

Theme styles should not bleed into the tray.

API changes

none

Data model changes

none

Decimal field is being serialized as "null" instead of "0.0" when the value is empty. However, in other languages, such as Java or SQL, "null" is not allowed for decimal primitive.

This is because DecimalItem is being defined as "string" in core/lib/Drupal/Core/Field/Plugin/Field/FieldType/DecimalItem.php

 /**
   * {@inheritdoc}
   */
  public static function propertyDefinitions(FieldStorageDefinitionInterface $field_definition) {
    $properties['value'] = DataDefinition::create('string')
      ->setLabel(t('Decimal value'))
      ->setRequired(TRUE);

    return $properties;
  }

Proposed solution:

change the "string" definition to "decimal"

Problem/Motivation

Accidentally, we commited a transformed version of test file. The ES6 builder (Babel) removed some test cases from this file.

Proposed resolution

Restore the file and only non-JS only.

Remaining tasks

- Review

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Plugin%21...

The class has no docblock.

Currently, if you render tokens for message, all timestamps are rendered by using current user. With multilingual (and multi-timezoned) this becomes a bit tricky.

In scenario, where there's mail including datetime token being sent to recipient from queue, and the queue is ran in cron, the current user is anonymous, which does not have timezone. This leads in situation where the datetime is default timezone.

The solution for above is to use `account_switcher` service when handling the queue to set current user to be the recipient.

However, if you like to let the user know what timezone was actually used for the timestamps, you would probably add something like
All times are shown as timezone of [current-user:timezone]

And for some reason, this isn't yet possible.

Problem/Motivation

In the FormatDate process plugin implementation the source format and destination format use the same timezone which comes from the settings, but we could have case when we need different timezone for destination format, for instance we have date in America/Denver timezone but we need to convert it to UTC.

Proposed resolution

1. Add new option from_timezone, and rename existing timezone parameter to to_timezone.
2. Throw exeption if timezone incorrect
3. Write test coverage

Remaining tasks

User interface changes

API changes

Different exceptions.

Data model changes

Add Change record to @deprecated in UrlGeneratorTrait.php

Problem/Motivation

While sourcepluginbase loads the source plugin configuration into the row to facilitate constants, SubProcess doesn't do this. We need access to all the statics that are setup in the source while inside of the SubProcess plugin.

Proposed resolution

$defaults = $this->configuration;
unset($defaults['plugin'], $defaults['key'], $defaults['process']),
  $new_row = new Row($new_value + $defaults, array());

is my best guess.

Remaining tasks

Determine what breaks. Code, test, debate, review, commit, dance.

User interface changes

API changes

Data model changes

Problem/Motivation

composer.json in HEAD does not prevent minor version updates to Symfony components. Historically and currently (as with Symfony 3.3), minor releases break Drupal.

Steps to reproduce

1. Clone Drupal.
2. composer update
3. Composer updates Symfony to 3.3 and Drupal is broken.

Being somewhat liberal about version constraints is a good thing but executing composer update ought to produce a working system.

Proposed resolution

Use the tilde "~" version constraint to allow only bugfix releases of Symfony components.

Another way of looking at it is that using ~ specifies a minimum version, but allows the last digit specified to go up.

— https://getcomposer.org/doc/articles/versions.md#tilde

Remaining tasks

Original report

After pulling down 8.4.x at commit c3f81d1, I ran composer update and attempted to reload the existing Drupal install.

The site threw the following fatal error:

Drupal\Core\Routing\Router::doMatchCollection(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition "Drupal\Core\Routing\CompiledRoute" of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition  in /var/www/html/docroot/core/lib/Drupal/Core/Routing/Router.php on line 209

Trying a new install after composer update:

Error: Class 'Symfony\Component\Config\Resource\ComposerResource' not found in /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php on line 1444 #0 /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php(394): Symfony\Component\DependencyInjection\ContainerBuilder->inVendors('/Users/cjm/Site...')
#1 /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php(303): Symfony\Component\DependencyInjection\ContainerBuilder->fileExists('/Users/cjm/Site...')
#2 /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php(463): Symfony\Component\DependencyInjection\ContainerBuilder->addObjectResource('Drupal\\Core\\Dep...')
#3 /Users/cjm/Sites/drupal8x/core/lib/Drupal/Core/CoreServiceProvider.php(62): Symfony\Component\DependencyInjection\ContainerBuilder->addCompilerPass(Object(Drupal\Core\DependencyInjection\Compiler\ModifyServiceDefinitionsPass))
#4 /Users/cjm/Sites/drupal8x/core/lib/Drupal/Core/DrupalKernel.php(1273): Drupal\Core\CoreServiceProvider->register(Object(Drupal\Core\DependencyInjection\ContainerBuilder))
#5 /Users/cjm/Sites/drupal8x/core/lib/Drupal/Core/DrupalKernel.php(883): Drupal\Core\DrupalKernel->compileContainer()
#6 /Users/cjm/Sites/drupal8x/core/lib/Drupal/Core/Installer/InstallerKernel.php(18): Drupal\Core\DrupalKernel->initializeContainer()
#7 /Users/cjm/Sites/drupal8x/core/lib/Drupal/Core/DrupalKernel.php(465): Drupal\Core\Installer\InstallerKernel->initializeContainer()
#8 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(414): Drupal\Core\DrupalKernel->boot()
#9 /Users/cjm/Sites/drupal8x/core/includes/install.core.inc(114): install_begin_request(Object(Composer\Autoload\ClassLoader), Array)
#10 /Users/cjm/.composer/vendor/drush/drush/includes/drush.inc(726): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#11 /Users/cjm/.composer/vendor/drush/drush/includes/drush.inc(711): drush_call_user_func_array('install_drupal', Array)
#12 /Users/cjm/.composer/vendor/drush/drush/commands/core/drupal/site_install.inc(82): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array)
#13 /Users/cjm/.composer/vendor/drush/drush/commands/core/site_install.drush.inc(255): drush_core_site_install_version('standard', Array)
#14 /Users/cjm/.composer/vendor/drush/drush/includes/command.inc(422): drush_core_site_install('standard')
#15 /Users/cjm/.composer/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#16 /Users/cjm/.composer/vendor/drush/drush/includes/command.inc(199): drush_command('standard')
#17 /Users/cjm/.composer/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#18 /Users/cjm/.composer/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#19 /Users/cjm/.composer/vendor/drush/drush/drush.php(12): drush_main()
#20 {main}
Error: Class 'Symfony\Component\Config\Resource\ComposerResource' not found in Symfony\Component\DependencyInjection\ContainerBuilder->inVendors() (line 1444 of /Users/cjm/Sites/drupal8x/vendor/symfony/dependency-injection/ContainerBuilder.php).

Problem/Motivation

We want to get rid of simpletest.module in Drupal 9. We want to prepare the latest Drupal 8 development branch as much as possible before opening the Drupal 9 development branch (see #2608062: [policy, no patch] Pre-requisites for opening Drupal 9). Therefore we need to convert all web tests to BrowserTestBase or UnitTestBase or KernelTestBase and deprecate WebTestBase.

Proposed resolution

1) Convert a small part of Drupal core web tests to Browser tests to get them battle tested. See all the conversion child issues that have been opened here before 2016-Sept-01.
2) Implement a backward compatibility layer as AssertLegacyTrait used by BrowserTestBase. Ideally a test conversion should only be the change of the namespace and used base class. Everything else should be covered by backwards compatible methods as far as possible/reasonable.
3) Prepare one big bang patch of test conversions in #2770921: Feb 21st: Convert chunk of WTB to BTB by just moving classes, changing use statements adding traits. Commit it during code freeze of the next Drupal minor release (likely March 2017 for 8.3).
4) In the meantime open child issues to convert web tests for each core module. While doing so we should also check if the test cases actually require a browser or can be converted to unit/kernel tests. They will be postponed until #2770921: Feb 21st: Convert chunk of WTB to BTB by just moving classes, changing use statements adding traits is committed.

Remaining tasks

Resolve all the child issues. Convert web tests in child issues per module/component in Drupal core.

Instructions for converting a Simpletest web test:

• Read https://www.drupal.org/phpunit and all subpages, especially https://www.drupal.org/node/2783189 .
• Move the test file to a tests/src/Functional folder in the module.
• Don't bulk move the tests but move and work on 1 test at the time. Regularly upload a patch to see if the tests pass on the testbot as well.
• Rename the namespace, make the class extends BrowserTestBase and fix the use statement.
• Try to run the single test with phpunit, example for HelpTest (replace the path with the file you converted):
  

  cd core
  ../vendor/bin/phpunit modules/help/tests/src/Functional/HelpTest.php --stop-on-failure

• Fatal error: undefined function assertNoLink(): not all legacy assertion methods are implemented yet, check #2750941: Additional BC assertions from WebTestBase to BrowserTestBase to borrow from there.
• If there is a test method which does not perform a web request (for example no ->drupalGet() or ->drupalPostForm() calls) then that method should be extracted to a unit test or kernel test. $this->setRawContent() generally means the test should be converted to a Kernel test
• $this->drupalPostAjaxForm(); means the test should be converted to a Javascript test. There most likely already is an issue for it, see #2809161: Convert Javascript/AJAX testing to use JavascriptTestBase
• Otherwise try to change as little things as possible in the converted web test. The conversion should be easy to review and further cleanup can be done in a follow-up issue.
• If you get stuck checkout the other child issues that do conversions - they can give you a hint what needs to be changed.
• If you have tricky conversions, please read out to people. They might have an issue. Occasional it could be also helpful to skip tricky tests.

Progress report

Want to know how we are doing? Check:
http://simpletest-countdown.org

Conversions

Note: don't convert the following bits:

• Tour tests
  
• Update path tests
  
• Views tests
  
• WizardTestBase tests
  

Needed conversions per module

• big_pipe: #2863607: Convert WebTestBaseTests of BigPipe to BrowserTestBase
• block: #2863644: Convert web tests of block
• block_content: #2887311: [PP-1] Convert web tests to browser tests for block_content module Part -2
• comment: #2866513: Convert web tests to browser tests for comment module
• config: #2870439: Convert web tests to browser tests for config module
• config_translation: #2870440: Convert web tests to browser tests for config_translation module
• content_translation: #2887813: Convert web tests to browser tests for content_translation module Part -2
• contextual: #2865407: Convert web tests to browser tests for contextual module
• editor: #2870443: Convert web tests to browser tests for editor module
• field: #2870444: Convert web tests to browser tests for field module
• field_ui: #2794347: Convert web tests to browser tests for field_ui module
• file: #2870448: Convert web tests to browser tests for file module
• filter: #2863416: Convert web tests to browser tests for filter module
• image: #2863626: Convert web tests to browser tests for image module
• menu_ui: #2870452: Convert web tests to browser tests for menu_ui module
• outside_in: #2870456: Convert web tests to browser tests for outside_in module
• page_cache: #2870457: Convert web tests to browser tests for page_cache module
• quickedit: #2870458: Convert web tests to browser tests for quickedit module
• rdf: #2864035: [PP-2] Convert web tests to browser tests for rdf module
• rest: #2775553: Convert web tests to browser tests for REST module
• search: #2863842: [PP-1] Convert web tests to browser tests for search module
• shortcut: #2864088: Convert web tests to browser tests for shortcut module
• simpletest
• system: #2862508: Convert system functional tests to phpunit
• taxonomy: #2887134: Convert rest of taxonomy web tests to browser tests
• text: #2870462: Convert web tests to browser tests for text module
• tour: #2767275: Convert web tests to browser tests for tour module
• update: #2870464: Convert web tests to browser tests for update module
• user: #2870465: Convert web tests to browser tests for user module

Completed

• aggregator: #2757023: Convert all aggregator web tests to BrowserTestBase
• action: #2736109: Convert web tests to browser tests for action module
• automated_cron: Doesn't contain any tests: ¯\_(ツ)_/¯
• ban: #2742497: Convert web tests to browser tests for ban module
• basic_auth: #2862494: Convert web tests to browser tests for basic_auth module
• block_content: #2864005: Convert web tests to browser tests for block_content module
• block_place: Already converted initially
• book: #2757007: Convert all book web tests to BrowserTestBase
• breakpoint: No webtests
• ckeditor: #2863996: Convert web tests to browser tests for ckeditor module
• color: #2753179: Convert all color web tests to BrowserTestBase
• contact: #2742995: Convert web tests to browser tests for contact module#2212869: Extend ContactAuthenticatedUserTest for anonymous user
• content_moderation: #2864008: Convert web tests to browser tests for content_moderation module
• content_translation: #2870441: Convert web tests to browser tests for content_translation module
• datetime & datetime_range: #2780063: Convert web tests to browser tests for datetime and datetime_range modules
• dblog: #2863372: Convert dblog web tests to BrowserTestBase
• dynamic_page_cache: Already converted
• entity_reference: No tests
• field_layout: No WebTests
• forum: #2737805: Convert web tests to browser tests for forum module
• hal: Already converted
• help: #2735199: Convert web tests to browser tests for help module
• history: #2795049: Convert web tests to browser tests for history module
• inline_form_errors: No webtests and FunctionalJavascriptTests already exist
• language: #2756059: Convert web tests to browser tests for language module
• layout_discovery: No webtests
• link: #2763013: Convert web tests to browser tests for link module
• locale: #2872059: Convert web tests to browser tests for locale module
• migrate: No webtests
• migrate_drupal: No webtests
• migrate_drupal_ui: #2867304: Convert web tests to browser tests for migrate_drupal_ui module
• minimal (profile): #2865537: Convert web tests to browser tests for minimal profile
• menu_link_content: #2870451: Convert web tests to browser tests for menu_link_content module
• node: #2870453: Convert web tests to browser tests for node module
• options: #2863969: Convert web tests to browser tests for options module
• path: #2863993: Convert web tests to browser tests for path module
• responsive_image: #2863984: Convert [1/3] web tests to browser tests for responsive_image module
• serialization: #2865413: Move RegisterSerializationClassesCompilerPassTest.php to correct location
• statistics: #2864121: Convert web tests to browser tests for statistics module
• syslog: #2782663: Convert web tests to browser tests for syslog module
• taxonomy: #2870459: Convert web tests to browser tests for taxonomy module
• telephone: #2755991: Convert web tests to browser tests for telephone module
• toolbar: #2863597: Convert web tests to browser tests for toolbar module
• tracker: #2863268: Convert web tests to browser tests for tracker module#2888539: Convert TrackerUserUidTest web tests to browser tests
• views: #2863267: Convert web tests of views
• views_ui: #2747167: Convert first part of web tests of views_ui
• workflows: No Webtests :)

Tips: Common conversions

• Simpletest allowed typecasting of elements. BrowserTestBase does not. Instead of (string) $element use $element->getText() or $element->getHtml();
• Views tests need the new constructor format with $import_test_views = TRUE as the first parameter in the setUp() method.
• Attributes are fetched with $item->getAttribute('value'); now, previously it was $item->value or $item->attributes()->value.

Issue creation

Please add the tag 'phpunit initiative' to every issue and add the issue to the correct Component (if it's a test for the comment module, add it to comment.module).

User interface changes

None.

API changes

Simpletest and WebTestBase will be deprecated.

Data model changes

None.

Follow-up to #2830581: Fix ContentModeration workflow type to calculate correct dependencies

Problem/Motivation

Content Moderation can be applied to entities that are revisionable but not those that are not. See #2850627: Do not require a revisionable entity type when using content_moderation.. It does not check if the the entity is use EntityPublishedInterface. The states offer settings around setting the default revision or published state.

This issue will decide what is the correct set of conditions that means you can apply content moderation to a specific entity type.

See also:
#2825973: Introduce a EditorialContentEntityBase class for revisionable and publishable entity types
#2812811: Use EntityPublishedInterface during moderation of entities to add support beyond nodes
#2850353: Test content_moderation with a non-bundleable content entity
#2842692: Warn users before enabling moderation on an entity type that can't be (un)published

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

The filter_format_permission process plugin hard codes the migration lookup name. This should be configurable, similar to #2640842: Make related file migration ID configurable in d6_cck_file.

Proposed resolution

Make the configuration configurable.

public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
return new static(
$configuration,
$plugin_id,
$plugin_definition,
$migration,
$container->get('plugin.manager.migrate.process')->createInstance('migration', ['migration' => 'd6_filter_format'], $migration)
);
}

Remaining tasks

• code it.
• review it.
• update/add change record

User interface changes

n/a

API changes

n/a

Data model changes

Original report

I get the following error when trying to import users

InvalidArgumentException: Passed variable is not an array or object, using empty array instead in /var/www/docroot/core/modules/migrate/src/Plugin/migrate/process/Flatten.php:30
Stack trace:
#0 /var/www/docroot/core/modules/migrate/src/Plugin/migrate/process/Flatten.php(30): ArrayIterator->__construct(NULL)
#1 /var/www/docroot/core/modules/migrate/src/MigrateExecutable.php(395): Drupal\migrate\Plugin\migrate\process\Flatten->transform(NULL, Object(Drupal\migrate_tools\MigrateExecutable), Object(Drupal\migrate\Row), 'permissions')
#2 /var/www/docroot/core/modules/migrate/src/Plugin/migrate/process/Migration.php(139): Drupal\migrate\MigrateExecutable->processRow(Object(Drupal\migrate\Row), Array)
#3 /var/www/docroot/core/modules/migrate/src/MigrateExecutable.php(381): Drupal\migrate\Plugin\migrate\process\Migration->transform(Array, Object(Drupal\migrate_tools\MigrateExecutable), Object(Drupal\migrate\Row), 'roles')
#4 /var/www/docroot/core/modules/migrate/src/MigrateExecutable.php(218): Drupal\migrate\MigrateExecutable->processRow(Object(Drupal\migrate\Row))
#5 /usr/local/share/drush/includes/drush.inc(720): Drupal\migrate\MigrateExecutable->import()
#6 /usr/local/share/drush/includes/drush.inc(711): drush_call_user_func_array(Array, Array)
#7 /var/www/docroot/modules/contrib/migrate_tools/migrate_tools.drush.inc(280): drush_op(Array)
#8 [internal function]: _drush_migrate_tools_execute_migration(Object(Drupal\migrate\Plugin\Migration), 'awm_users', Array)
#9 /var/www/docroot/modules/contrib/migrate_tools/migrate_tools.drush.inc(246): array_walk(Array, '_drush_migrate_...', Array)
#10 /usr/local/share/drush/includes/command.inc(422): drush_migrate_tools_migrate_import('awm_users')
#11 /usr/local/share/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#12 /usr/local/share/drush/includes/command.inc(199): drush_command('awm_users')
#13 /usr/local/share/drush/lib/Drush/Boot/BaseBoot.php(73): drush_dispatch(Array)
#14 /usr/local/share/drush/includes/preflight.inc(93): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#15 /usr/local/share/drush/drush.php(11): drush_main()
#16 {main}

I've generated this from the migrate-update --config-only drush command

langcode: en
status: true
dependencies: {  }
id: awm_users
migration_tags:
  - 'Drupal 7'
migration_group: migrate_drupal_7
label: 'User accounts'
source:
  plugin: d7_user
process:
  uid: uid
  name: name
  pass: pass
  mail: mail
  created: created
  access: access
  login: login
  status: status
  timezone: timezone
  langcode:
    plugin: user_langcode
    source: language
    fallback_to_site_default: false
  preferred_langcode:
    plugin: user_langcode
    source: language
    fallback_to_site_default: true
  preferred_admin_langcode:
    plugin: user_langcode
    source: language
    fallback_to_site_default: true
  init: init
  roles:
    plugin: migration
    migration: awm_users_role
    source: roles
  user_picture:
    -
      plugin: default_value
      source: picture
      default_value: null
    -
      plugin: migration
      migration: upgrade_d7_file
destination:
  plugin: 'entity:user'
migration_dependencies:
  required:
    - awm_users_role
  optional:
    - upgrade_d7_file
    - upgrade_language
    - upgrade_default_language
    - upgrade_user_picture_field_instance
    - upgrade_user_picture_entity_display
    - upgrade_user_picture_entity_form_display
    - upgrade_d7_field_instance
    - upgrade_d7_user_role

Using Drupal 8.2.5. awm_users_role migrated ok.

Tbh I have no idea which of the 9 additional migration modules this would fall under. I'm trying to do a selective migration from drupal 7 to 8, so generating the migration templates through drush, and then running migrate-import.