-
Notifications
You must be signed in to change notification settings - Fork 74
Conversation
use AdminAPI.ConnCase, async: true | ||
|
||
describe "/configuration.get" do | ||
test "returns a list of accounts and pagination data" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list of configurations
assert data["fake_setting"] == %{ | ||
"code" => "setting_not_found", | ||
"key" => "fake_setting", | ||
"object" => "configuration_setting_error" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to have 2 different kind of error
objects returned? If possible I'd stick with only error
and try to remove configuration_setting_error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
###################################### | ||
SettingResponse: | ||
description: "The response schema for settings" | ||
SettingSchema: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're using "configuration" now, should this be changed to ConfigurationSchema
?
Also SettingResponse
-> ConfigurationResponse
a bit down below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish it was just settings, but it was taken, so instead we send back a configuration composed of a set of settings, that's why you see both settings and configuration in the spec depending on the level.
…et into 502-add-settings-endpoints
Issue/Task Number: #502
closes #502
Overview
This PR adds two new endpoints to manage the configuration settings:
/configuration.get
/configuration.update
I decided to go with
configuration.*
instead ofsettings.
simply because we already have a/settings.all
endpoint that returns something in the shape ofI didn't know how to reuse that and make it fit with the settings system, so using something like
/configuration.*
made more sense. Totally up for discussion if you guys have better ideas.Changes
count
to the pagination object to know exactly how many records are being returned in the response (suggested by one of our mobile developers, a small change that makes it easier to parse a response and adds little overhead in the code)./configuration.get
to retrieve the list of all settings. This actually returns a paginated, filterable and sortable list of settings./configuration.all
could be a better name to stay consistent./configuration.update
that takes a hash of settings update in the form of:And will return a list of insert results which can either be:
configuration_setting
type)error
type)configuration_setting_error
(that would occur in case a setting key is not found)To Do