Problem/Motivation

For implementing an API based admin UI you not only need content entity APIs, config entity APIs, but also some support for simple config saving. Luckily we don't need full CRUD support. Read and update would be enough, aka. GET and PATCH requests.

Questions:

  • How do we do access checking? Right now access checking for simple config forms is in the routing level, so there is no way to access it.
    Possible solutions:
    1. Extend config schema
    2. Just use 'administer site configuration' for everything (not really a good solution for a core UI)
  • We need config validation, similar to what we plan over in #2300677: JSON:API POST/PATCH support for fully validatable config entities
  • For a generic UI it could be super helpful to have some level of knowledge, where the forms would appear in the new UI. (unrelated with this issue)
  • Potentially more during an actual implementation
  • Do we need field level access checking or at least per config entity field level access checking?

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

CommentFileSizeAuthor
#9 interdiff-2947759.txt8.74 KBdawehner
#9 2947759-9.patch12.35 KBdawehner
#3 2947759-3.patch9.4 KBdawehner

Comments

dawehner created an issue. See original summary.

dawehner’s picture

dawehner
Primary language German
commented
Issue summary: View changes
Issue tags: +API-First Initiative
dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new 2947759-3.patch9.4 KB

Here is the experiments which resulted in some of the questions above.

dawehner’s picture

dawehner
Primary language German
commented
Issue tags: +JavaScript
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2300677: JSON:API POST/PATCH support for fully validatable config entities

This is a WONDERFUL start! Thank you, @dawehner! 🎉👏

Extend config schema

This is interesting! How do you imagine that would work?

This also related to config entities, because they don't have a concept of field-level access checking yet. Solving this for simple config likely would also mean bringing the equivalent of field-level access to config entities.

dawehner’s picture

dawehner
Primary language German
commented
Issue summary: View changes

@Wim Leers I added your point about field level to the issue summary. That is a good/tricky question.
For me it feels like one function do determine what is changeable could be enough. You know, just like you decide on a form level what you actually want to expose?

This is interesting! How do you imagine that would work?

For the overall UI I really don't know. It feels wrong to put URLs into config schema, but yeah maybe something like this is needed:

system.site:
  type: config_object
  label: 'Site information'
  ui:
    path: /admin/config/site/...
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

For me it feels like one function do determine what is changeable could be enough.

Do you mean one function (callback) per top-level config key to indicate which child keys are changeable?

For the overall UI I really don't know. It feels wrong to put URLs into config schema […]

Is this really necessary? It'd also limit us in how we could rearrange/reimagine a JS-powered admin UI. (I think this is perhaps the most puntable part of the entire issue.)

dawehner’s picture

dawehner
Primary language German
commented

Is this really necessary? It'd also limit us in how we could rearrange/reimagine a JS-powered admin UI. (I think this is perhaps the most puntable part of the entire issue.)

Well, I totally think that it should be treated as suggestion, not as a mandatory thing. On the other hand like contrib_module_A should somehow be able to be added to the UI, without the UI being altered for this contrib_module_A.

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new 2947759-9.patch12.35 KB
new interdiff-2947759.txt8.74 KB
  • Ensure the config get be actually fetched via HTTP
  • Removed anything related to patch / post requests
  • Introduced a new normalizer
dawehner’s picture

dawehner
Primary language German
commented
Related issues: +#2952037: [meta] Add constraints to all simple configuration

In order to properly support that we need also #2952037: [meta] Add constraints to all simple configuration

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue tags: +Configuration system
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Category: Plan » Feature request

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: -JavaScript +JavaScript, +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!