Hi all,
The WSO2 Streaming Integrator team is pleased to announce WSO2 Analytics
Dashboard 1.0.0 Release Candidate 2
*What's new in WSO2 Analytics Dashboard 1.0.0-RC2*
- Added support for Siddhi 5
- Added the Status Dashboard feature
- Bug fixes and improvements
*Documentation*
I also think the first approach will be good. Regarding the migration i
think all published APIs wont have any impact due to this migration.
APIs in prototype state should be in prototype state after migrating. So if
existing deployment migrated to 3.2.0 there will not be any changes in APIs
and
Hi Kasun,
On Wed, Apr 22, 2020 at 9:17 AM Kasun Thennakoon wrote:
> Hi Hasunie,
>
> Out of the above three suggestions, I'm +1 to the 1st approach you have
> suggested, Where
>
>
>- Combination of *prototype *state and *enableStore=true*(API artifact
>property) will depict the *testing*
Hi Hasunie,
Out of the above three suggestions, I'm +1 to the 1st approach you have
suggested, Where
- Combination of *prototype *state and *enableStore=true*(API artifact
property) will depict the *testing* state
- *enableStore *property will control the visibility in the developer
Hi all,
We are calling off this vote due to an issue identified in the Widget
Generation Wizard
Thanks and Regards,
Charuka
On Tue, Apr 21, 2020 at 10:23 AM Anusha Jayasundara
wrote:
> Hi Devs,
>
> I have tested the followings,
> 1. Portal profile
>
>- Creating dashboard
>- Add
Hi all,
We will not be converting the Admin Portal to a Web App anymore. Once the
Admin Portal is converted to a Web App we need to implement a new approach
for the login flow.
We have 2 options for this,
1. Rewrite the jaggery login code in jsp
2. Use IS authentication SDK
We were hoping to
Hi All,
We have been working on a testing console for the API Publisher. The main
> intention of this feature is that the developer(creator, publisher) can
> make sure that the API is working as expected by performing functional
> tests before publishing to the dev portal.
> For example, test
Hi Chathuranga/Hisan,
In terms of the REST APIs:
*Moving Admin API to new codegen*
1. We are using a code generator to generate server-side code skeletons
using swagger specs. For admin API we have it in [1]. But for Admin API, we
were using a proprietary code generator plugin and we have to
Hi Ayesha,
Thank you for the suggestions. I'm +1 for the 1st approach as it is
providing all the server configs in a single call instead of requiring the
client to perform multiple calls. I have introduced slight modifications to
the inbound config. Please see the final configs model and let me
