Problem/Motivation

As an overall issue based on #2292707: GET on entity/taxonomy_vocabulary/{id} is not working it is weird we cannot GET to ConfigEntities.

Some use cases are

  • Get Vocabulary name to display for the current language.
  • Get Menu items for the headless app.
  • Get site name (is not a ConfigEntity!)

Proposed resolution

As rest already has a view permission why not just return ConfigEntities for GET ops?

Some examples

curl --user admin:admin --request GET http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json

{"uuid":"091cf3b1-de66-4dd8-8403-3d6d63de5d43","langcode":"en","status":true,"dependencies":[],"name":"Tags","vid":"tags","description":"Use tags to group articles on similar topics into categories.","hierarchy":0,"weight":0}
curl --user admin:admin --request GET http://drupal.d8/entity/menu/main?_format=json

Remaining tasks

  1. The anonymous call should not result in error. Is that related to #1916302: Serve REST errors as application/api-problem+json OR application/vnd.error+json ?

    curl --user "anonymous:" --request GET "http://drupal.d8/entity/taxonomy_vocabulary/tags?_format=json"
    
    {"error":""}
    

User interface changes

API changes

Files: 
CommentFileSizeAuthor
#80 2300677-80.patch7.85 KBdawehner
#64 interdiff.txt13.38 KBdawehner
#64 2300677-64.patch19.84 KBdawehner
#60 2300677-60.patch7.33 KBdawehner
#50 support_configentity-2300677-50.patch3.74 KB-enzo-
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-50.patch. Unable to apply patch. See the log in the details link for more information. View
#42 support_configentity-2300677-42.patch5.4 KB-enzo-
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-42.patch. Unable to apply patch. See the log in the details link for more information. View
#38 support_configentity-2300677-38.patch5.42 KB-enzo-
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-38.patch. Unable to apply patch. See the log in the details link for more information. View

Comments

clemens.tolboom’s picture

Berdir’s picture

Config entities have no validation and access API beside their UI's/Forms, so exposing over REST is tricky.

If we'd want that, it would be clearer if that would be a completely separate plugin and serialization, that would just directly use toArray().

clemens.tolboom’s picture

@Berdir thanks for the quick response. But I don't understand. For me its 'just' an entity where rest manage permission. Why distinguish on Content versus Config? Patch seems valid to me :p

Patch skips field access for ConfigEntities checks but not entity view.

class EntityResource extends ResourceBase {

...
  public function get(EntityInterface $entity) {
    if (!$entity->access('view')) {
      throw new AccessDeniedHttpException();
    }
...

What do I miss?

Status: Needs review » Needs work

The last submitted patch, rest-config-entity.patch, failed testing.

tstoeckler’s picture

Yeah, I agree that access checking should be sufficient for config entities. We have been moving away from route-based access (i.e. using _permission directly) to entity-level access for config entities so that should work fine. And in terms of validation we can use the new SchemaCheckTrait. It's not as powerful as content entity validation, but I think it too should be sufficient to validate that nothing completely bogus enters the system.

Berdir’s picture

Maybe, but that still means that it would be a separate plugin for config entities and IMHO a feature request, not a bug. The only bug seems to be that you can configure rest.module to expose config entities right now an it's then choking on it...

clemens.tolboom’s picture

I just checked service 7.x-3.x module which exposed 2 config `entities`

  • taxonomy_vocabulary
  • system

I myself ran into what menu item belong to ie 'main' which both are config entities :(

Use case: A headless Drupal with AngularJS menu controller.

From the list below I'm not sure we need all ConfigEntities available but at least menu, menu_link, tour are very useful.

$ drush @drupal.d8 entity-type-read  `drush @drupal.d8 entity-type-read` | grep ConfigEntity | sort
...
    [action] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [block] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [block_content_type] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [breakpoint] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [breakpoint_group] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [comment_type] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [contact_category] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [date_format] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [editor] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [entity_form_display] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [entity_view_display] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [field_config] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [field_instance_config] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [filter_format] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [form_mode] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [image_style] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [menu] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [node_type] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [rdf_mapping] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [search_page] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [shortcut_set] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [taxonomy_vocabulary] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [tour] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [user_role] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [view] => Drupal\Core\Config\Entity\ConfigEntityType Object
    [view_mode] => Drupal\Core\Config\Entity\ConfigEntityType Object

@tstoeckler what code should be changed for CRUD through REST for ConfigEntities?

Berdir’s picture

What services supported and not is not really relevant, a feature in a contrib module doesn't mean that not having it in core is a regression :) Especially because 7.x did not differentiate between config and content entities, services.module did not integrate entities in a generic way and system is not an entity :)

If one config entity is supported then all are.

clemens.tolboom’s picture

I was only trying to list and select 'valid' reasons to expose a ConfigEntity. In the end permissions guard what is exposed.

I hope for some pointers to fix this bug.

Grayside’s picture

Configuration being what it is in Drupal, exposing it even behind permissions is a little like exposing custom module code if you've got the right permission. The delicate balance there seems pretty good for Contrib to explore, and maybe something gets into 8.1.

In practice, I expect it's not the full config entity you need, but some externally useful information (e.g., the name of a vocabulary), associated with the content it configures. Full CRUD support for Config would make this an API for building your Drupal site, and that seems like a glaring potential for massive security problems.

moshe weitzman’s picture

Title: Rest should support ConfigEntity » Support ConfigEntity via REST
Category: Bug report » Feature request

In an effort to constrain scope. the REST team decided to focus on content entities and not config entities. I'd be happy if someone took up this important feature. Retitling and recategorizing accordingly.

clemens.tolboom’s picture

@moshe weitzman it's good to focus on content.

I hope for some more pointers on how to solve this issue.

Wim Leers’s picture

I'm no REST expert, but from what I can tell, the main problem is validation when modifying config entities.

What if core would only support reading config entities? That'd satisfy the majority and still defer the most complex parts to contrib.

clemens.tolboom’s picture

When adding GET on ConfigEntityType we should block the other methods for sure otherwise we get core bug reports when people enable permissions on those methods.

clemens.tolboom’s picture

XREF #1897612-16: Add serializer support for YAML

The REST and CMI teams already concluded that since CMI files are best deployed via Git, not via REST, so we're not supporting ConfigEntities. That means this wouldn't be useful for doing configuration deployments.

clemens.tolboom’s picture

Issue summary: View changes

Trying building a web app we are blocked for not GETting Vocabulary and Menu and even just the site name.

What options do we have to expose these resources and what more resources are valid candidates to expose for GET?

-enzo-’s picture

Issue tags: +#amsterdam2014 #headlessdrupal

During the Spring of DrupalCon Amsterdam 2014 I did a debug of how get via Rest Config Entity

I did my test with Entity entity:entity_form_display and the URL I use test was http://example.com/entity/entity_form_display/node.article.default after pass the Basic Auth I got a Access Denied 403.

The access denied was trigger in Resource Drupal\Core\Entity\Entity\EntityFormDisplay. because the class Drupal\rest\Plugin\rest\resource\EntityResource tried to execute the method access and doesn't exist.

I will improve the function get of Class EntityResource

public function get(EntityInterface $entity) {
    if (!$entity->access('view')) {
      print_r(get_class($entity));
      throw new AccessDeniedHttpException();
    }
    foreach ($entity as $field_name => $field) {
      if (!$field->access('view')) {
        unset($entity->{$field_name});
      }
    }
    return new ResourceResponse($entity);
  }

ASAP I got a patch I will upload.

clemens.tolboom’s picture

Issue summary: View changes

@-enzo- this issue has a patch already. What is wrong with that patch?

Note there is #2339815: Limit EntityResource to content entities, rather than them causing fatal errors which is doing the opposite.

It would be great to have more use cases into the summary so please add yours.

-enzo-’s picture

Uhhh my fault, I will review and provide a feedback if works for Entity Form Display

alansaviolobo’s picture

Issue tags: -#amsterdam2014 #headlessdrupal +Amsterdam2014, +#headlessdrupal
clemens.tolboom’s picture

Parent issue: » #2335229: [meta] REST et al
-enzo-’s picture

Hi folks

I did a patch to support Entity Display entities via Rest, fixing the error trying to call access method with view parameters, also add current validation to confirm the user has access to get Entity Display definition.

To test this patch you can use the Chrome plugin Simple REST Client and the URI http://example.com/entity/entity_form_display/node.article.default remember enable the resource using the Rest UI module as you can see in the following image

As you can see in configuration you must to use Basic Auth in Rest Client and be sure the header Accept with application/json

As result you will get something similar to this output

{
    "uuid": "a3283201-6a27-41a4-a400-bfbd7550fd54",
    "langcode": "en",
    "status": true,
    "dependencies": {
        "entity": [
            "field.field.node.article.body",
            "field.field.node.article.comment",
            "field.field.node.article.field_image",
            "field.field.node.article.field_tags",
            "node.type.article"
        ],
        "module": [
            "comment",
            "entity_reference",
            "image",
            "path",
            "taxonomy",
            "text"
        ]
    },
    "id": "node.article.default",
    "targetEntityType": "node",
    "bundle": "article",
    "mode": "default",
    "content": {
        "title": {
            "type": "string_textfield",
            "weight": 0,
            "settings": {
                "size": 60,
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "body": {
            "type": "text_textarea_with_summary",
            "weight": 1,
            "settings": {
                "rows": 9,
                "summary_rows": 3,
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "field_tags": {
            "type": "taxonomy_autocomplete",
            "weight": 3,
            "settings": [],
            "third_party_settings": []
        },
        "field_image": {
            "type": "image_image",
            "weight": 4,
            "settings": {
                "progress_indicator": "throbber",
                "preview_image_style": "thumbnail"
            },
            "third_party_settings": []
        },
        "uid": {
            "type": "entity_reference_autocomplete",
            "weight": 5,
            "settings": {
                "match_operator": "CONTAINS",
                "size": 60,
                "autocomplete_type": "tags",
                "placeholder": ""
            },
            "third_party_settings": []
        },
        "created": {
            "type": "datetime_timestamp",
            "weight": 10,
            "settings": [],
            "third_party_settings": []
        },
        "promote": {
            "type": "boolean_checkbox",
            "settings": {
                "display_label": "1"
            },
            "weight": 15,
            "third_party_settings": []
        },
        "sticky": {
            "type": "boolean_checkbox",
            "settings": {
                "display_label": "1"
            },
            "weight": 16,
            "third_party_settings": []
        },
        "comment": {
            "type": "comment_default",
            "weight": 20,
            "settings": [],
            "third_party_settings": []
        },
        "path": {
            "type": "path",
            "weight": 30,
            "settings": [],
            "third_party_settings": []
        }
    },
    "hidden": [],
    "third_party_settings": []
}
dmouse’s picture

@-Enzo- thanks, works for me! =)

clemens.tolboom’s picture

Issue tags: +needs test

Patch look great. Hope to review this week. This needs some tests.

  1. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -32,6 +37,55 @@
    +
    

    Remove white line

  2. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -32,6 +37,55 @@
    +  /**
    

    prepend white line

  3. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -32,6 +37,55 @@
    +    public function __construct(
    +        array $configuration,
    +        $plugin_id,
    +        $plugin_definition,
    +        array $serializer_formats,
    +        LoggerInterface $logger,
    +        AccountProxyInterface $current_user) {
    +
    +        parent::__construct($configuration, $plugin_id, $plugin_definition, $serializer_formats, $logger);
    +
    +        $this->currentUser = $current_user;
    +      }
    +
    

    Why add line breaks in the arguments list? Grepping on core source tree show lots of single line __construct.

    Fix indentation of function body.

  4. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -43,12 +97,26 @@ class EntityResource extends ResourceBase {
    +    else if (is_a($entity, ContentEntityInterface)) {
    

    Use instanceOf instead

-enzo-’s picture

HI @clemens.tolboom I did a new patch following your recommendation, please check and let me know if works for you.

clemens.tolboom’s picture

General: this needs tests too to confirm the GET versus other ops work as expected.

  1. +++ b/core/lib/Drupal/Core/Entity/Plugin/rest/resource/BundleViewModesResource.php
    @@ -86,10 +86,10 @@ public function get($entity = NULL, $bundle = NULL) {
           }
     
    -      throw new NotFoundHttpException(t('Log entry with ID @id was not found', array('@id' => $id)));
    +      throw new NotFoundHttpException(t('Views modes for @entity and @bundle were not found', array('@entity' => $entity, '@bundle' => $bundle)));
         }
     
    -    throw new HttpException(t('No log entry ID was provided'));
    +    throw new HttpException(t('Entity or Bundle weren\'t provided'));
       }
     
    

    This seems unrelated.

  2. +++ b/core/lib/Drupal/Core/Entity/Plugin/rest/resource/EntityBundlesResource.php
    @@ -73,7 +73,7 @@ public function get($entity = NULL) {
    -      throw new NotFoundHttpException(t('Log entry with ID @id was not found', array('@id' => $id)));
    +      throw new NotFoundHttpException(t('Bundles for entity @entity were not found', array('@entity' => $entity)));
         }
    

    This seems unrelated.

  3. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -34,6 +39,47 @@
    +        parent::__construct($configuration, $plugin_id, $plugin_definition, $serializer_formats, $logger);
    +        $this->currentUser = $current_user;
    +      }
    +
    

    Fix indentation.

-enzo-’s picture

Status: Needs work » Needs review
FileSize
3.87 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,479 pass(es), 1 fail(s), and 0 exception(s). View

Hi @clemens.tolboom

I remove unrelated code and fix indentation

-enzo-’s picture

@clemens.tolboom how I can do this " this needs tests too to confirm the GET versus other ops work as expected."?

Status: Needs review » Needs work

The last submitted patch, 27: support_configentity-2300677-27.patch, failed testing.

MartijnBraam’s picture

I've tried the patch to get the contents of the main menu. (The path in REST UI is incorrect. The /entity part is missing)

curl --user admin:admin --header "Accept: application/json" --request GET http://drupal.d8/entity/menu/main

The response is correct but useless:

{
    "uuid": "2ee5aa01-b45d-46f0-9d06-6be711cdcedc",
    "langcode": "en",
    "status": true,
    "dependencies": [],
    "id": "main",
    "label": "Main navigation",
    "description": "Use this for linking to the main site sections.",
    "locked": true
}

The thing I needed was the items in the menu, not the metadata of the main menu.

-enzo-’s picture

Hi @MartijnBraam

About the missing entity in end point, maybe you need to update the Rest UI module I did a patch to resolve that issue #2290605: REST URI paths changed to canonical paths.

About the entity menu did you request, after enable the Entity Menu Resorce as you can see in the following image.

When I tried to consume this end point using the URL http://example.com/entity/menu/main I got the following error

[Wed Oct 15 06:35:14 2014] [error] [client 127.0.0.1] PHP Fatal error: Call to a member function access() on a non-object in /Users/enzo/www/drupal8beta/core/modules/rest/src/Plugin/rest/resource/EntityResource.php on line 52

I will debug and propose a new version of patch.

-enzo-’s picture

Status: Needs work » Needs review
FileSize
3.77 KB

Attached you can find a new patch testes Menu, Nodes and Entity Display Form

clemens.tolboom’s picture

Issue summary: View changes
Status: Needs review » Needs work
clemens.tolboom’s picture

Ehm ... I did not delete file from #32 ... how could I delete that file!?!?

clemens.tolboom’s picture

Status: Needs work » Needs review
FileSize
5.48 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 79,472 pass(es), 1 fail(s), and 0 exception(s). View

I've tested using Rest UI to configure + permissions for anonymous with

curl --user admin:admin --header "Accept: application/json" --request GET http://drupal.d8/entity/user_role/anonymous
$ curl --user anonymous: --header "Accept: application/json" --request GET http://drupal.d8/entity/user_role/anonymous

both gives

{"uuid":"f5c18ef3-25f2-4442-9204-4cf8d72a4380","langcode":"en","status":true,"dependencies":[],"id":"anonymous","label":"Anonymous user","weight":0,"permissions":["use text format plain_text","access content","use text format restricted_html","access comments","access site-wide contact form","create article content","edit any article content","delete any article content","restful get entity:node","restful post entity:node","restful delete entity:node","restful patch entity:node","restful get entity:comment","restful post entity:comment","restful delete entity:comment","restful patch entity:comment","restful get entity:user","restful post entity:user","restful delete entity:user","restful patch entity:user","restful get entity:file","restful get entity:menu","restful get entity:user_role","restful get entity:taxonomy_vocabulary"]}

Attached patch adds a test as an example. It needs some fixes.

Status: Needs review » Needs work

The last submitted patch, 35: support_configentity-2300677-35.patch, failed testing.

clemens.tolboom’s picture

@-enzo- I used your patch from #32

Below the changes I did. Interdiff was better :-/ I added a test which 'nicely' failed.

  1. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -45,12 +91,26 @@ class EntityResource extends ResourceBase {
    +    else if ($entity instanceof EntityDisplayBase) {
    

    Added space after if

  2. +++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
    @@ -45,12 +91,26 @@ class EntityResource extends ResourceBase {
    +      $permission = "restful get $plugin_definition->pluginId";
    

    Don't use label.

-enzo-’s picture

FileSize
5.42 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-38.patch. Unable to apply patch. See the log in the details link for more information. View

Hi @clemens.tolboom

Using you patch #35 I did a new patch, because the way you use to get the Id of plugin return empty because is not an object is an array, but if you test with admin user the validation never is executed.

About the test I can't test because I'm getting a awful error trying to list the test to execute.

[Thu Oct 16 05:18:09 2014] [error] [client 127.0.0.1] Uncaught PHP Exception ReflectionException: "Class Drupal\\Tests\\devel_generate\\DevelGenerateManagerTest does not exist in expected /Users/enzo/www/drupal8/modules/devel/devel_generate/tests/src/DevelGenerateManagerTest.php" at /Users/enzo/www/drupal8/core/modules/simpletest/src/TestDiscovery.php line 153, referer: http://drupal8/admin/config/development/testing/settings

ASAP I resolve this issue I will work in testing, but meanwhile do you have any idea what is wrong in test? Also the test must be cover in this issue or maybe we can create a new issue?

clemens.tolboom’s picture

@-enzo- thanks for the feedback and sorry for the bad code :-/

Just remove devel module temporary.

I wrote #35 in order to show you were test could be written.

Test must be in this issue :-)

-enzo-’s picture

@clemens.tolboom I follow your instructions and remove the devel issue, but now I got a new error if I try to run any Test you can see the error at #2341997: Uncaught exception - Circular reference detected for service "database".

Maybe you can consider to separate the Test in other issue and if work the patch apply to Drupal Core.

Any thoughts?

tim.plunkett’s picture

Issue tags: -needs test +Needs tests
-enzo-’s picture

FileSize
5.4 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-42.patch. Unable to apply patch. See the log in the details link for more information. View

Hey folks

I did a re-roll of path #38 to meet the latest changes in Drupal 8 but still works in Unit Test are required.

djbobbydrake’s picture

Hi all. Tried the patch in 42 (support_configentity-2300677-42.patch), and still getting the metadata for menu:

curl --user admin:admin -H "Accept: application/hal+json" --request GET http://d8.local/entity/menu/footer
{"uuid":"3f36ed88-a631-4614-8601-1d7c9ae394c1","langcode":"en","status":true,"dependencies":[],"id":"footer","label":"Footer","description":"Use this for linking to site information.","locked":true}

Is this patch supposed to pull the actual menu items?

Berdir’s picture

No, the patch is not. Menu links are something else entirely. The menu config entity *is* the menu metadata.

I still have the opinion that providing generic support for config entities is problematic and unneeded. In many cases, they will not give you the data you actually care about. See above.

The only real use case I see for the current content entity implementation is to synchronize data 1:1 between equal systems, e.g. a staging/production site. It is an internal representation of the raw data.

For config entities, we have the configuration sync/import API, and nothing we do could do here would come close to what that provides, with diffs, and sync flags and so on.

IMHO, if you want an API that you can use from an external source, e.g. an app, or a public API for your clients, especially if that involves config entities but likely even for content, then write it yourself, then you can define an API and structure that makes sense for your use case. Take the example in #43, where the expectation is to get all the menu links, which are actually plugins, with different sources. There is no way we can make a generic API that supports that, but it should be fairly easy to write a custom resource plugin that returns menu links in a simple structure.

-enzo-’s picture

@Berdir I use this patch with a Headless Drupal Generator github.com/enzolutions/generator-marionette-drupal , in my case is good idea because in that way I can generate HTML5 forms based in Drupal 8 site current status.

I know you point an API is only for data, but with proper permissions you can expose this information to create great tools and services integrated with Drupal 8

webchick’s picture

Yeah, I really don't understand how you can write a custom front-end for a Drupal 8 site without supporting at least some config entities. The inability to get vocabulary names when displaying a node is a huge limitation.

clemens.tolboom’s picture

Today I revisited our tiny effort to mimic garland using Angular https://github.com/build2be/drupal-8-rest-angularjs

It could not list the term names as we have a list of nodes on taxonomy/term/:tid which renders the term on HTML but there is no equivalent in REST context. Adding a view we can add a list of terms which partly solves term names.

But IMHO it should not be necessary to build that view on every site. It should be out of the box.

To really build the mentioned Garland App menu items are really needed. As menu items are not config entities (what are they?) I guess a contrib module should solve that :-/

andypost’s picture

Related issues: +#2413769: Prevent the deletion of a bundle entity if there are existing content entities of that bundle
-enzo-’s picture

@clemens.tolboom Correct you can solve that with view because is content.

But in my case I want to create a REST Frontend #headless Drupal with Backbone with the capability to generate Forms for content types based in current content types definition in a Drupal 8 site, how you can solve that with out expose a config entity?

If you check the patch the rest resource require a specific permission to access config entities, so IMHO is not security issue. Also a Rest Resource has a security level with Authentication Provider selected when the Rest Resource is enabled.

If the argument to disable this option is force users to create content in Drupal instead of provide the option the user to decide how access his content even the admin content is the wrong angle.

-enzo-’s picture

FileSize
3.74 KB
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] Unable to apply patch support_configentity-2300677-50.patch. Unable to apply patch. See the log in the details link for more information. View

Hey folks

I did a re-roll of path #42 to meet the latest changes in Drupal 8 but still works in Unit Test are required.

davidwbarratt’s picture

Status: Needs work » Needs review

Kicking of the testbot to see if we need a re-roll....

The last submitted patch, 38: support_configentity-2300677-38.patch, failed testing.

The last submitted patch, 42: support_configentity-2300677-42.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 50: support_configentity-2300677-50.patch, failed testing.

frob’s picture

Assigned: Unassigned » frob

Not sure if this should still be 8.0 or 8.1 but, I will see if I can reroll this patch.

Status: Needs work » Needs review
Wim Leers’s picture

Version: 8.0.x-dev » 8.1.x-dev
dawehner’s picture

I worked a bit on it, here are some bits I ran into it on the meantime.

Status: Needs review » Needs work

The last submitted patch, 60: 2300677-60.patch, failed testing.

Wim Leers’s picture

Looks great!

+++ b/core/modules/rest/src/Plugin/rest/resource/EntityResource.php
@@ -210,6 +216,9 @@ public function delete(EntityInterface $entity) {
   protected function validate(EntityInterface $entity) {
+    if (!$entity instanceof FieldableEntityInterface) {
+      return;
+    }

Shouldn't we perform config schema validation for config entities? See \Drupal\Core\Config\Schema\SchemaCheckTrait — hattip @tstoeckler in #5.

Wim Leers’s picture

Priority: Normal » Major
Related issues: +#2650792: What permissions control REST's field_storage_config?

Closed #2650792: What permissions control REST's field_storage_config? as a duplicate, another person wondering why this doesn't work, and the lack of helpful errors also getting in the way.

I think it's safe to say this is at least major.

dawehner’s picture

Status: Needs work » Needs review
FileSize
19.84 KB
13.38 KB

Made some progress:

  • The create test now actually works, yeah
  • Started to expand the read test
frob’s picture

Assigned: frob » Unassigned

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dawehner’s picture

Note: This is blocked on #1928868: Typed config incorrectly implements Typed Data interfaces technically, doesn't mean though one cannot work here.

dawehner’s picture

Title: Support ConfigEntity via REST » [pp-2] Support ConfigEntity via REST

Let's be more honest about it.

clemens.tolboom’s picture

Issue summary: View changes

Fixed links using _format now.

dawehner’s picture

frob’s picture

what does pp-2 mean?

clemens.tolboom’s picture

Wim Leers’s picture

Wim Leers’s picture

Title: [pp-2] Support ConfigEntity via REST » [PP-1] Support ConfigEntity via REST
dawehner’s picture

@Wim Leers
Do you mind updating your comment and replace just with "just"?

Wim Leers’s picture

Done :P

Wim Leers’s picture

Title: [PP-1] Support ConfigEntity via REST » [PP-1] Create/Update/Delete (POST/PATCH/DELETE) ConfigEntity via REST
Wim Leers’s picture

Status: Needs review » Postponed

This is not blocked on reviews. If somebody wants to take it on despite the blocker, feel free to mark it as active. For now, marking as postponed.

dawehner’s picture

Issue tags: +DevDaysMilan

Note: #1928868: Typed config incorrectly implements Typed Data interfaces has a needs review patch now. Feedback there would be great.

dawehner’s picture

FileSize
7.85 KB

Just some intermedia reroll, nothing to see :)

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dawehner’s picture

Title: [PP-1] Create/Update/Delete (POST/PATCH/DELETE) ConfigEntity via REST » [PP-2] Create/Update/Delete (POST/PATCH/DELETE) ConfigEntity via REST