We collaborated with Factorial, the web agency based in Germany, to develop the Subgroup module, which allows the Group module* to handle hierarchies. In the process, we also sponsored the able release of the Group module, which has been in development for several years.
The actual development effort was undertaken out by Kristiaan van Den Eynde, the maintainer of the Group module.
*The Group module allows Drupal site administrators to configure complex access controls which cannot be realised with the roles and permissions features of the Drupal core.
Developing the Subgroup module
At the beginning of the project, we didn't only communicate the requirements to the developer, but also the reasons we needed the feature and the problems the system needs to solve so the requirements can be adequately reflected on the architecture.
From the beginning of the project, our intention was to make the deliverable open-source; therefore, the solution needed to be highly generic. At times we had to make a difficult decision to drop some features which were peculiar to our needs.
The project was managed in an agile method. Each story was given a priority and we started with the essential features.
API-driven, with a wide test coverage
Often Drupal modules have processes that are form-dependent, which cause issues when writing tests, as well as making the features available via API. The Subgroup module was built with the API-first approach to maintaining a clean separation of the form and the functionality. This allowed the developer to easily write unit tests and detect regressions whenever erroneous code was added.
How the Group module help make Drupal better
The Group module is indispensable for building sites with a large number of users with complex access control, such as enterprises and universities. Such access checks require enormous calculations and caching of the results of the calculation is essential for the site's performance. The Group module's maintainer Kristiaan noticed that Drupal core's caching mechanism was not efficient so built the VariationCache module that replaces the entire caching mechanism of Drupal core, which he did a presentation on at Drupalcon Amsterdam 2019. This has been highly regarded by core contributors and is expected to eventually replace the core's caching system.
If you are interested in reading about this endeavour from Kristiaan's perspective, here's the link to his blog post: https://www.factorial.io/en/blog/group-finally-released-look-past-and-f…
- 第1回 歴史に見るDrupal のDNA
- 第2回 Drupalはフレームワークか？CMSか？
- 第3回 Drupalの特徴
- 第4回 Drupal 9のインストール(1)
- 第5回 Drupal 9のインストール(2)
- 第6回 コンテンツを投稿してみる
- 第7回 ボキャブラリとタクソノミーを使う
- 第8回 コンテンツ管理におけるDrupalと他のCMSとの比較
- 第9回 Drupal 9のブロックシステム
- 第10回 Drupalの標準クエリービルダ Views
- 第11回 Drupalと他のCMSのクエリビルダー機能を比較
- 第12回 Drupal 9の多言語機能と他のCMSやサービスとの比較
- 第13回 Drupalの権限設定とWordPressやMovable Typeとの比較
- 第14回 Drupalのテーマシステムについて
- 第15回 Drupalの拡張モジュールの選定と利用方法
- 第16回 Drupalをもっと知りたい方に向けた各種情報