There are several problems in allowing to edit the Swagger file directly.
1. We change it on new product releases. So now users have to find a way to
merge whatever their changes when doing product upgrades. This is error
prone.
2. The Swagger file is 100s of lines long and it has lots of
On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote:
> There are several problems in allowing to edit the Swagger file directly.
>
> 1. We change it on new product releases. So now users have to find a way
> to merge whatever their changes when doing product upgrades. This is
As Fazlan said, if we first publish and then only do API processing, it
will remove the need to rollback. If the API processing failed after
publishing, we can publish another event saying processing failed.
--Srinath
On Tue, May 9, 2017 at 11:06 AM, Fazlan Nazeem wrote:
>
adding Prabath.
Don't we have this level of permission checks though identity components?
If we have to implement this, then if we can keep the model with only allow
actions, it will simplify the model.
--Srinath
On Sat, May 6, 2017 at 12:45 AM, Ayyoob Hamza wrote:
>
+1 for auditing table
On Mon, May 8, 2017 at 2:45 PM, Ayyoob Hamza wrote:
> Hi Ruwan,
>
> +1 for this, Having the communication history through a common stream will
> help us to build an analytics solution for health status, anomaly detection
> .. etc.
>
> On Mon, May 8, 2017
Regarding adding entries to the config file, you don't need to even open
the swagger file. What you need to do is to find the resource from the docs
and enter it into the config file. By expecting a sys admin to edit the
Swagger file my main worry is we're expecting the sys-admin to play with an
On Tue, May 9, 2017 at 12:59 PM, Nuwan Dias wrote:
>
>
> On Tue, May 9, 2017 at 12:26 PM, Sanjeewa Malalgoda
> wrote:
>
>>
>>
>> On Tue, May 9, 2017 at 11:52 AM, Nuwan Dias wrote:
>>
>>> There are several problems in allowing to edit the
No Sanjeewa, in the method I'm proposing the system "will not break" even
if someone goes and puts Japanese characters in the config file. That is by
design.
One design principle from 3.0.0 onwards is to have no migration script
involved. In the method I'm proposing we avoid migration 100% (for
So it seems Sanjeewa's and my view points are clear on this.
1. Sanjeewa basically says let users (sys-admins) edit the Swagger file
that define the product REST API. Objective is to avoid duplicating
resource to scope mappings elsewhere.
2. I basically say maintain an optional config file so
On Tue, May 9, 2017 at 4:57 PM, Nuwan Dias wrote:
> Regarding adding entries to the config file, you don't need to even open
> the swagger file. What you need to do is to find the resource from the docs
> and enter it into the config file. By expecting a sys admin to edit the
>
10 matches
Mail list logo