Fix macos && suse gid issue

[TheREK3R]

Description

Patches a bug I introduced in 7.1 This is a breaking change for the following use case, where a non-username primary group is given to a user by an integer gid alone.

u = [{
  'id': 'X'
  'groups': ['A'],
  'gid': 7000,
  'no_user_group': true
}]

users_manage 'A' do
  users u
  group_id 7000
end

This case is bad practice, if a second group is introduces it can break, and the gid field is agnostic of its primary group.

u = [{
  'id': 'X'
  'groups': ['A', 'B'],
  'gid': 7000,
  'no_user_group': true
}]

users_manage 'A' do
  users u
end

users_manage 'B' do
  users u
  group_id 7000
end

The fix for this issue was also included in 7.1. It is to include the primary_group key in the user hash, which defines the primary group belonging to an integer gid. This is not needed when the gid is a string or meant to be associated with the username group. The proper way to handle this case is as follows.

u = [{
  'id': 'X'
  'groups': ['A', 'B'],
  'gid': 7000,
  'primary_group': 'B',
  'no_user_group': true
}]

users_manage 'A' do
  users u
end

users_manage 'B' do
  users u
  group_id 7000
end

This will ensure that group 'B' is created with the proper gid and that the user 'X' can have it as its primary group.

Issues Resolved

https://github.com/sous-chefs/users/issues/459

Check List

• [X] All tests pass. See TESTING.md for details.
• [X] New functionality includes testing.
• [X] New functionality has been documented in the README if applicable.

[kitchen-porter]

Released as: 8.0.0