Spawned from the comments in #65.

In the collection create form, «Add» is bigger than «Submit». I was tempted to click «add», which adds a display field instead of the submit button on the left. — idea: replace «Add» by «+» and move submit to the right

We should add an easy way to resolve the conflict from the error message.

In this specific case, both records contains the same data (even if it is hard to tell)

Picking one or the other will have the same impact.

Imported from mozilla-services/amo-blocklist-ui#4

Should be "easy" with kinto query string parameters.

Note: this would obviously be proposed for collections having a schema defined only.

After a discussion we had on #80 (comment) I am spawning this as a separate feature request.

That's important if you want to avoid versioning the credentials and also to have this file puppettized.

Changelog: https://github.com/mozilla-services/react-jsonschema-form/releases/tag/v0.12.0

As we're starting from 0.4 currently, expect some breakage. /cc @magopian

This would make it easier to develop kinto-admin against a local kinto (although this sort of situation would probably be rare).

I tried implementing this but I wanted to share the check function for the -c argument from bin/kinto-admin and I couldn't figure out how to do it. One ugly way is to have devServer.js require("./bin/kinto-admin"), but I couldn't bring myself to commit this. I couldn't figure out how to have bin/kinto-admin able to require stuff from scripts when it was run directly and from node_modules when the user had npm install'd kinto-admin.

We should implement the same UI for deleting collections as the one we landed for buckets in #83.

Spawned from the comments in #65.

Spawned from the comments in #65.

I tried to upgrade the amo-blocklist-ui repo with the 0.12.4 version.

Some errors are thrown when going to bulk creation:
Uncaught Error: Could not find a definition for #/definitions/minVersion.

Whereas the single record creation seems to work fine.

(did not investigate yet)

We should be able to target a given object schema property for selecting it to be displayed:

{
  "fooCollection": {
    "displayFields": ["level1.level2"],
    "schema": {
      "properties": {
        "level1": {
          "type": "object",
          "properties": {
            "level2": {
              "type": "object",
              "properties": {}
            }
          }
        }
      }
    }
  }
}

Hello,

our project uses generated names of collections on an oauth application's bucket, therefore we cannot predict collection or bucket names. Being able to "scan" a bucket for collections within the kinto admin would be amazing, and before we have this ability, it doesn't make sense to integrate kinto-admin into our growing suite of tools.

Thanks for all your hard work on this project, and I hope that you include this feature in the future! I'll keep an eye out.

Idea: by cherry picking react-router imports

https://github.com/reactjs/react-router/blob/master/docs/guides/MinimizingBundleSize.md

mjnjjkkj

For example, it makes no sense to render a Create collection button to people not allowed to do so in a given bucket.

Alternatively to hiding action buttons entirely, we could mark them as disabled, and/or add a lock icon next to their label. Thoughts?

Note: This will need Kinto/kinto#600 (comment)

Todo

• Hide Add/Bulk add buttons if we don't have the permission to create records in a collection (#135)
• Hide Create collection sidebar menu entry if we don't have the permission to create collections in a listed bucket
• Hide Create bucket button if no permission to do so (refs #401)

Spawned from the comments in #65.

When going to «Create a collection», the item in the left menu is not blue like with other pages

not an emergency

Currently the object id is used as the label AFAIK.

The use-case would be to have a collection with id addons but shown as Add-ons in the menu.
It could read a label the name attribute in the collection metadata for example.

mozilla-services/amo2kinto#13

Given action "COLLECTIONS_LIST_RECEIVED", reducer "collections" returned undefined. To ignore an action, you must explicitly return the previous state.

Idea: use the current field to populate a label attribute, and slugify to assign the id attribute to be used.

This URL http://kinto.github.io/kinto-admin/ in github seems to be not working

I've just spent a few unecessary minutes trying to figure out a weird error I had in the admin because I misspelled properties in my schema, while it was accepted just fine when submitted.

We should validate the entered JSON schema, eg. using https://github.com/mafintosh/is-my-json-valid.

Now #65 has landed and the conflict resolution stuff has been partially kept in the codebase, we should reintroduce a way to handle a conflict when posting a resource which has been updated on the server since we started editing it on the client.

This is a much less critical issue than before when we used to synchronize a full local replication of the server database, where these happened very frequently.

Actually, maybe what we want here is to simply render a notification that a race condition occurred, which is what github does when editing a same comment on two different instances concurrently.

• Link to jsonschema website for the collection schema JSON editor (even better if we find some online JSON schema builder, maybe the formbuilder?)
• Link to uiSchema documentation for the collection uiSchema JSON editor

Hat tips redux author: http://stackoverflow.com/a/36749963/330911

Suppose I have a field in the edited record that is not defined in the schema. Will it be lost upon save when I edit it ?

(not a priority)

Might require some work on react-jsonschema-form to prevent it to add the validation messages in the DOM, and let the user handle them in the onError callback.

Imported from https://github.com/mozilla-services/amo-blocklist-ui/issues/20

Now that xml2kinto creates the collection with the schema, this could be a nice to have for https://github.com/mozilla-services/amo-blocklist-ui

Please tell me the differences between the two :)

For quickly finding a listed entry.

This little cross (see screenshot below, its css class is close) is set as position: fixed, and will thus stay exactly in the same position when scrolling.

It's also not properly aligned with the notification box title.

Using the manual strategy, there can be conflict when collection is synchronized.

In a first version, there could be a dialog where the user is shown the local and remote version of the conflicting record, and they can choose what to do (client wins/server wins/abort)

Imported from https://github.com/mozilla-services/amo-blocklist-ui/issues/16

Ref https://github.com/Kinto/kinto-admin/pull/34/files/3d38b9679f67280c10ebb06c154bda3c5f41c5a3#r59392095

So when at the bottom of a long list we keep seeing them.

Spawned from the comments in #65.

Spawned from #67 and #83.

We should probably just remove it as it's redundant with the browser's one.

Spawned from the comments in #65.