This is derived from samvera/maintenance#119, and follows the guide in https://guides.rubygems.org/mfa-requirement-opt-in/

Ruby 2.7.0 was released on 12/25/2019, and in accordance with the charter of the current phase of the Component Maintenance Working Group, the CircleCI configuration for this should be updated.

Descriptive summary

This repository’s default branch has already been renamed to main using GitHub’s renaming tool. In order to preserve automatic redirection of links that reference the old branch name master to the new default main branch, a branch with the old name should not be recreated.

CircleCI can be used to prevent the recreation of the old default branch name by preventing PRs with a branch named master from being merged by causing a test failure during continuous integration.

Rationale

Git's default "master" branch derives from "master/slave" jargon which perpetuates systemic racist language and systems (see email Replacing "master" reference in git branch names). To uphold our Code of Conduct, we must move away from the term "master" in our technical language (as well as words like blacklist or whitelist).

Expected behavior

If a PR is submitted with a branch named master, the continuous integration tests should fail.

Actual behavior

If a PR is submitted with a branch named master, the continuous integration tests will not fail because of the branch name.

Related work

Background on the renaming effort is available in the working group notes.

Waffle.io is scheduled to be shut down by May 16th: https://waffle.io/

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

All versions of Rails are affected by a remote code execution bug, CVE-2022-32224, affecting serialized YAML. There are no workarounds- Rails expects everyone to upgrade to safe versions: 7.0.3.1, 6.1.6.1, 6.0.5.1, or 5.2.8.1. These new versions of Rails appear to have caught the community off guard, and frequently require other code changes to successfully upgrade.

hydra-role-management does not call serialize itself, but Blacklight does. Blacklight version 7.28.0 supports the Rails versions above.

Community feedback to the Rails team has led to new tickets and pull requests to make this upgrade easier, and the consensus from the Hyrax Working Group and Tech calls this week is to wait a little while for the dust to settle before implementing this upgrade. The current versions of Ruby on Rails and Blacklight may not be the best to target for this work.

This should follow the conventions proposed by https://keepachangelog.com/en/1.0.0/

Derived from samvera/maintenance#16

https://github.com/samvera-labs/bixby should probably be explored for this as well.

The default role mapper allowed a username to be added to a role before a user has registered.

We use this for people wanting access to our test server. They email us requesting access, we add them to a role, and send them an email with instructions for how to create an account through IU's CAS.

Another use case would be students or TAs that you want added to a role before a term starts and not have to negotiate with each one to add them to a role after they have registered with the system.

The existing behavior could be easily restored by creating a user when they are added to a group and this works in our system which uses devise+omniauth but wouldn't with default devise. Is there a better way to provide for this use case?

Rails version 6.0.0 was released on 08/16/2019, and in accordance with the charter of the current phase of the Component Maintenance Working Group, the CircleCI configuration for this should be updated.

Derived from samvera/maintenance#17

User ids are integers, however, when deleting users from roles, an email string is used:

http://localhost:3000/roles/3/users/awead@aic-dot-org

As opposed to the integer id of the user:

http://localhost:3000/roles/3/users/1

Is there a Devise configuration I'm missing?

Thanks so much for this gem! However, I run into troubles in Rails 5, because the migrations are only suitable for Rails 4. For example, if in a Rails 5.1.2 app, I run the following commands:

rails generate roles
rake db:migrate

I get the error:

Directly inheriting from ActiveRecord::Migration is not supported. Please specify the Rails release the migration was written for

Derived from samvera/maintenance#76

Derived from samvera/maintenance#89

This follows the proposed maintenance reorganization within samvera/maintenance#137

Please see the maintenance policy for Ruby on Rails for further information regarding which releases of Rails are still supported by the community.

There doesn't seem to be any reason to have the hydra-head dependency. Is there any reason we can't remove it?

This engine defines normal controller actions around Role as well as add_user and remove_user. We should document this somewhere with notes about how to grant these abilities.

https://github.com/projecthydra/hydra-role-management/blob/81e05f26ccd9c37a41eef38cb83c266c6f050210/app/models/concerns/hydra/role_management/user_roles.rb#L11

Derived from samvera/maintenance#77

Bundler 2.x seems to come with json 2.x installed by default, which means that when I take an application that uses hydra-role-management and try to upgrade it to use the latest bundler, I get an error like this:

/home/bess/.rvm/gems/ruby-2.6.3@cypripedium/gems/bundler-2.0.2/lib/bundler/runtime.rb:319:in `check_for_activated_spec!': You have already activated json 2.1.0, but your Gemfile requires json 1.8.6. Since json is a default gem, you can either remove your dependency on it 
or try updating to a newer version of bundler that supports json as a default gem. (Gem::LoadError)    

If I download the hydra-role-management gem, I can run the test suite locally against json 2.x.

I had this line in my routes file:

devise_for :users, controllers: { sessions: :sessions, registrations: :registrations}

When I ran "rails generate roles", it inserted the role management line in the middle of the devise line, so my routes file looked like this:

devise_for :users
mount Hydra::RoleManagement::Engine => '/'
, controllers: { sessions: :sessions, registrations: :registrations}