Yes its good have. If it's a race against time and we are dropping the edit due to that, i guess it's ok for now. However it will not be very user friendly. So better make note of it for next time then :)
Thanks On Thu, Aug 15, 2019 at 12:09 PM Bhathiya Jayasekara <[email protected]> wrote: > It's good to have. But with the time limits we have, delete is also enough > I think. I mean they can delete and write again if need. > > Thanks, > Bhathiya > > On Thu, Aug 15, 2019 at 11:55 AM Dushan Silva <[email protected]> wrote: > >> Hi Bhathiya, >> Shouldn't we support edit at least for the person who put the comment? >> Since it's more of a social feature edit would be useful for a user. >> >> >> Thanks >> >> On Thu, Aug 15, 2019 at 11:47 AM Bhathiya Jayasekara <[email protected]> >> wrote: >> >>> >>> On Thu, Aug 15, 2019 at 11:13 AM Kavishka Fernando <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> Thank you for the feedback. I will make the necessary changes. >>>> >>>> Should we allow users to comment on APIs which belong to different >>>>> tenants? If not we can remove '#/parameters/requestedTenant' from >>>>> POST operation. >>>>> >>>> In APIM-2.6.0 we do not allow users to comment to APIs which belong to >>>> different tenants. >>>> Hence +1 to remove '#/parameters/requestedTenant' from POST operation. >>>> >>> >>> To support that we don't need a separate param I assume. We can use the >>> user's tenant domain. >>> >>> >>>> >>>> Are we allowing admin or the provider to edit the comment? >>>> >>>> In APIM-2.6.0 AFAIR we do not allow the provider to edit the comment. >>>> In the meantime I will proceed with the createdBy property. >>>> Shall we support this feature for the edit function? >>>> >>> >>> I don't think we need to have edit at this point. However, we need >>> delete by a privileged user. >>> >>> Thanks, >>> Bhathiya >>> >>> >>>> >>>> Thanks, >>>> >>>> On Thu, Aug 15, 2019 at 9:34 AM Tharindu Dharmarathna < >>>> [email protected]> wrote: >>>> >>>>> Hi Ishara, >>>>> >>>>> If we supporting cross tenant subscriptions we have to give access to >>>>> comment creation. >>>>> >>>>> Thanks >>>>> >>>>> On Thursday, August 15, 2019, Ishara Cooray <[email protected]> wrote: >>>>> >>>>>> Should we allow users to comment on APIs which belong to different >>>>>> tenants? If not we can remove '#/parameters/requestedTenant' from >>>>>> POST operation. >>>>>> IMO this is not required as if we need to comment on an api we need >>>>>> to login to the particular tenant. >>>>>> Hence +1 to remove '#/parameters/requestedTenant' from POST >>>>>> operation. >>>>>> >>>>>> Thanks & Regards, >>>>>> Ishara Cooray >>>>>> Associate Technical Lead >>>>>> Mobile : +9477 262 9512 >>>>>> WSO2, Inc. | http://wso2.com/ >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> >>>>>> On Thu, Aug 15, 2019 at 5:45 AM Ishara Cooray <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> username: >>>>>>>>> type: string >>>>>>>>> description: | >>>>>>>>> If username is not given user invoking the API will be >>>>>>>>> taken as the username. >>>>>>>>> >>>>>>>>> Regarding the description: I guess we should omit it when posting >>>>>>> a comment and always use the logged-in user? >>>>>>> +1 >>>>>>> >>>>>>>> content: >>>>>>>>> type: string >>>>>>>>> createdTime: >>>>>>>>> type: string >>>>>>>>> example: 2017-02-20T13:57:16.229 >>>>>>>>> createdBy: >>>>>>>>> type: string >>>>>>>>> >>>>>>>>> I guess we don't need two properties: createdBy and username? >>>>>>> Are we allowing admin or the provider to edit the comment? >>>>>>> If so it make sense to have both username and createdBy. >>>>>>> >>>>>>> @Kavishka Fernando <[email protected]> >>>>>>> Let's add operationId to the definition as a convention. >>>>>>> >>>>>>> Thanks & Regards, >>>>>>> Ishara Cooray >>>>>>> Associate Technical Lead >>>>>>> Mobile : +9477 262 9512 >>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 13, 2019 at 7:19 PM Malintha Amarasinghe < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 13, 2019 at 6:06 PM Thilini Shanika <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Shouldn't we add error handling for unauthorized/forbidden >>>>>>>>> API(Role restricted) comment retrievals/deletions >>>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> >>>>>>>> Also please find a couple of inline comments: >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Aug 13, 2019 at 5:10 PM Kavishka Fernando < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> We are planning on creating the comments feature for the Store in >>>>>>>>>> APIM 3.0 similar to the comments feature and outlook available in >>>>>>>>>> APIM-2.6.0. >>>>>>>>>> >>>>>>>>>> I am currently in the process of creating the REST API for the >>>>>>>>>> comments feature. >>>>>>>>>> Shown below is the swagger related to the resource, >>>>>>>>>> >>>>>>>>>> ###################################################### >>>>>>>>>> # The "Comments Collection" resource API >>>>>>>>>> ###################################################### >>>>>>>>>> '/apis/{apiId}/comments': >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> # Retrieve a list of all comments of a certain API >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> get: >>>>>>>>>> summary: Retrieve API comments >>>>>>>>>> security: >>>>>>>>>> - OAuth2Security: [] >>>>>>>>>> description: | >>>>>>>>>> Get a list of Comments that are already added to APIs >>>>>>>>>> parameters: >>>>>>>>>> - $ref: '#/parameters/apiId' >>>>>>>>>> - $ref: '#/parameters/limit' >>>>>>>>>> - $ref: '#/parameters/offset' >>>>>>>>>> >>>>>>>>>> We will need to add #/parameters/requestedTenant to retrieve >>>>>>>> comments of APIs which are in other tenant domains than the user's >>>>>>>> tenant. >>>>>>>> >>>>>>>>> tags: >>>>>>>>>> - Comments >>>>>>>>>> responses: >>>>>>>>>> 200: >>>>>>>>>> description: | >>>>>>>>>> OK. >>>>>>>>>> Comments list is returned. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/CommentList' >>>>>>>>>> 406: >>>>>>>>>> description: | >>>>>>>>>> Not Acceptable. The requested media type is not supported >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> # Add a new Comment >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> post: >>>>>>>>>> summary: Add an API comment >>>>>>>>>> security: >>>>>>>>>> - OAuth2Security: >>>>>>>>>> - apim:subscribe >>>>>>>>>> x-scope: apim:subscribe >>>>>>>>>> parameters: >>>>>>>>>> - $ref: '#/parameters/apiId' >>>>>>>>>> - $ref: '#/parameters/requestedTenant' >>>>>>>>>> >>>>>>>>>> Should we allow users to comment on APIs which belong to >>>>>>>> different tenants? If not we can remove >>>>>>>> '#/parameters/requestedTenant' from POST operation. >>>>>>>> >>>>>>>> >>>>>>>>> - in: body >>>>>>>>>> name: body >>>>>>>>>> description: | >>>>>>>>>> Comment object that should to be added >>>>>>>>>> required: true >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Comment' >>>>>>>>>> tags: >>>>>>>>>> - Comments >>>>>>>>>> responses: >>>>>>>>>> 201: >>>>>>>>>> description: | >>>>>>>>>> Created. >>>>>>>>>> Successful response with the newly created object as >>>>>>>>>> entity in the body. >>>>>>>>>> Location header contains URL of newly created entity. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Comment' >>>>>>>>>> headers: >>>>>>>>>> Location: >>>>>>>>>> description: | >>>>>>>>>> Location to the newly created Comment. >>>>>>>>>> type: string >>>>>>>>>> ETag: >>>>>>>>>> description: | >>>>>>>>>> Entity Tag of the response resource. Used by caches, >>>>>>>>>> or in conditional request. >>>>>>>>>> type: string >>>>>>>>>> 400: >>>>>>>>>> description: | >>>>>>>>>> Bad Request. >>>>>>>>>> Invalid request or validation error. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> 415: >>>>>>>>>> description: | >>>>>>>>>> Unsupported media type. >>>>>>>>>> The entity of the request was in a not supported format. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ######################################################### >>>>>>>>>> # "Individual API comment" resource APIs >>>>>>>>>> ######################################################### >>>>>>>>>> '/apis/{apiId}/comments/{commentId}': >>>>>>>>>> >>>>>>>>>> #----------------------------------------------------------------------- >>>>>>>>>> # Retrieve an individual Comment for a certain API >>>>>>>>>> #----------------------------------------------------------------------- >>>>>>>>>> get: >>>>>>>>>> summary: Get details of an API comment >>>>>>>>>> security: >>>>>>>>>> - OAuth2Security: [] >>>>>>>>>> description: | >>>>>>>>>> Get the individual comment given by a username for a certain >>>>>>>>>> API. >>>>>>>>>> parameters: >>>>>>>>>> - $ref: '#/parameters/commentId' >>>>>>>>>> - $ref: '#/parameters/apiId' >>>>>>>>>> - $ref: '#/parameters/If-None-Match' >>>>>>>>>> >>>>>>>>>> Same as GET here: We will need to add >>>>>>>> #/parameters/requestedTenant >>>>>>>> >>>>>>>>> tags: >>>>>>>>>> - Comments >>>>>>>>>> responses: >>>>>>>>>> 200: >>>>>>>>>> description: | >>>>>>>>>> OK. >>>>>>>>>> Comment returned. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Comment' >>>>>>>>>> headers: >>>>>>>>>> ETag: >>>>>>>>>> description: | >>>>>>>>>> Entity Tag of the response resource. >>>>>>>>>> Used by caches, or in conditional requests. >>>>>>>>>> type: string >>>>>>>>>> Last-Modified: >>>>>>>>>> description: | >>>>>>>>>> Date and time the resource has been modifed the last >>>>>>>>>> time. >>>>>>>>>> Used by caches, or in conditional requests. >>>>>>>>>> type: string >>>>>>>>>> 304: >>>>>>>>>> description: | >>>>>>>>>> Not Modified. >>>>>>>>>> Empty body because the client has already the latest >>>>>>>>>> version of the requested resource. >>>>>>>>>> 404: >>>>>>>>>> description: | >>>>>>>>>> Not Found. >>>>>>>>>> Requested comment does not exist. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> 406: >>>>>>>>>> description: | >>>>>>>>>> Not Acceptable. >>>>>>>>>> The requested media type is not supported >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> # Delete a particular Comment >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> delete: >>>>>>>>>> summary: Delete an API comment >>>>>>>>>> security: >>>>>>>>>> - OAuth2Security: >>>>>>>>>> - apim:subscribe >>>>>>>>>> x-scope: apim:subscribe >>>>>>>>>> description: | >>>>>>>>>> Remove a Comment >>>>>>>>>> parameters: >>>>>>>>>> - $ref: '#/parameters/commentId' >>>>>>>>>> - $ref: '#/parameters/apiId' >>>>>>>>>> - $ref: '#/parameters/If-Match' >>>>>>>>>> tags: >>>>>>>>>> - Comments >>>>>>>>>> responses: >>>>>>>>>> 200: >>>>>>>>>> description: | >>>>>>>>>> OK. >>>>>>>>>> Resource successfully deleted. >>>>>>>>>> 404: >>>>>>>>>> description: | >>>>>>>>>> Not Found. >>>>>>>>>> Resource to be deleted does not exist. >>>>>>>>>> schema: >>>>>>>>>> $ref: '#/definitions/Error' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The resource will be as follows, >>>>>>>>>> >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> # The Comment resource >>>>>>>>>> #----------------------------------------------------- >>>>>>>>>> Comment: >>>>>>>>>> title: Comment >>>>>>>>>> required: >>>>>>>>>> - content >>>>>>>>>> properties: >>>>>>>>>> commentId: >>>>>>>>>> type: string >>>>>>>>>> >>>>>>>>>> Can make it just "id". >>>>>>>> >>>>>>>> >>>>>>>>> apiId: >>>>>>>>>> type: string >>>>>>>>>> >>>>>>>>>> I think apiId is not required. >>>>>>>> >>>>>>>>> username: >>>>>>>>>> type: string >>>>>>>>>> description: | >>>>>>>>>> If username is not given user invoking the API will be >>>>>>>>>> taken as the username. >>>>>>>>>> >>>>>>>>>> Regarding the description: I guess we should omit it when posting >>>>>>>> a comment and always use the logged-in user? >>>>>>>> >>>>>>>> >>>>>>>>> content: >>>>>>>>>> type: string >>>>>>>>>> createdTime: >>>>>>>>>> type: string >>>>>>>>>> example: 2017-02-20T13:57:16.229 >>>>>>>>>> createdBy: >>>>>>>>>> type: string >>>>>>>>>> >>>>>>>>>> I guess we don't need two properties: createdBy and username? >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>>> Your input for this is highly appreciated. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> *Kavishka Fernando* >>>>>>>>>> *Software Engineer | WSO2* >>>>>>>>>> Email: [email protected] >>>>>>>>>> Mobile: +94773838069 >>>>>>>>>> Web: http://wso2.com >>>>>>>>>> Blog: https://medium.com/@kavishkafernando >>>>>>>>>> >>>>>>>>>> <http://wso2.com/signature> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Thilini Shanika >>>>>>>>> Associate Technical Lead >>>>>>>>> WSO2, Inc.; http://wso2.com >>>>>>>>> 20, Palmgrove Avenue, Colombo 3 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Malintha Amarasinghe >>>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>>> http://wso2.com/ >>>>>>>> >>>>>>>> Mobile : +94 712383306 >>>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> >>>>> *Tharindu Dharmarathna*Associate Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: *+94779109091* >>>>> >>>>> >>>> >>>> -- >>>> *Kavishka Fernando* >>>> *Software Engineer | WSO2* >>>> Email: [email protected] >>>> Mobile: +94773838069 >>>> Web: http://wso2.com >>>> Blog: https://medium.com/@kavishkafernando >>>> >>>> <http://wso2.com/signature> >>>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. >>> (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com >>> >>> >>> >> >> -- >> Best Regards >> Dushan Silva >> Software Engineer >> >> *WSO2, Inc. * >> >> lean . enterprise . middleware >> Mob: +94 774 979042 >> > > > -- > *Bhathiya Jayasekara* | Technical Lead | WSO2 Inc. > (m) +94 71 547 8185 | (e) bhathiya-@t-wso2-d0t-com > > > -- Best Regards Dushan Silva Software Engineer *WSO2, Inc. * lean . enterprise . middleware Mob: +94 774 979042
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
