Can anyone point me any site/forum which allow you to edit others comment(not approve/reject or delete entire comment). I'm just curious :) Think what will happen when someone comment on your blogs, media etc(or even you can think of product comments of most common e commerce platforms). It will go through approval process or filter and then publish.
If we allow someone to edit others comments its a crime IMO :). Hence -1 for let someone to edit/update others comment. Thanks, sanjeewa. On Fri, May 19, 2017 at 11:04 AM, Nuwan Dias <[email protected]> wrote: > I think standard forums allow privileged users to moderate comments. > Moderation can be in the form of approving/rejecting comments or in the > form of removing obscene type of comments. > > If we go down the workflow (approval) path, there's much to implement. Ex: > We need to introduce a "state" to the comment, need to implement a > workflow, a callback mechanism, a workflow cleanup, etc. But if we just > write a piece of code which allows a pre-configured role to remove, edit > comments, I think the implementation is much simpler. > > On Fri, May 19, 2017 at 10:52 AM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> >> >> On Fri, May 19, 2017 at 10:43 AM, Bhathiya Jayasekara <[email protected]> >> wrote: >> >>> Hi Sanjeewa, >>> >>> On Thu, May 18, 2017 at 5:09 PM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> I don't think its worth to get complete permission model for comments >>>> as well. Like bhathiya mentioned only comment owner is allowed to >>>> update/delete his comment. That is the normal behavior. Also i feel its >>>> better if we can have work flow support for comments(by default this need >>>> to disabled). Once something posted if we let someone else to modify its >>>> not nice. >>>> >>> >>> Admin or similar role might be needing moderator capability for >>> comments. WDYT? To support that we can easily use existing permission >>> model. >>> >> I haven't see a single website or forum which allows one person to edit >> others comments. We cannot edit or update any others comment :) Its not >> Only thing admin or other person can do is approve/reject comment or delete >> it. It means workflow + delete permission to only super user. WDYT? >> >> Thanks, >> sanjeewa. >> >> >>> Thanks, >>> Bhathiya >>> >>> >>>> >>>> Thanks, >>>> sanjeewa. >>>> >>>> On Thu, May 18, 2017 at 11:20 AM, Fazlan Nazeem <[email protected]> >>>> wrote: >>>> >>>>> Hi Nuwan/Bhathiya, >>>>> >>>>> On Tue, May 9, 2017 at 10:19 AM, Nuwan Dias <[email protected]> wrote: >>>>> >>>>>> I think what Bhathiya is suggesting is to bring in our usual >>>>>> permissions model (in APIM 3.0.0) to comments as well. This will require >>>>>> more data to be saved in the DB but will address the issue at hand. >>>>>> >>>>>> >>>>> Are you suggesting we should have an extra column in Comments table in >>>>> the db to fulfill this? >>>>> >>>>> I am thinking of using the AM_API_PERMISSION column introduced in >>>>> AM_API table to decide on who can update/delete a specific comment. Apart >>>>> from the user who commented, If a user can delete or update an API he can >>>>> delete/update any comment for that API. This way we do not need to save >>>>> extra information in the db, and can use the api permission information to >>>>> control the comment actions. >>>>> >>>>> There are two levels of permissions required here. One is "who can >>>>>> add/update/remove comments in general" and the other is "whose comments >>>>>> can >>>>>> I update/remove". >>>>>> >>>>>> The first can be simply achieved using scopes. Basically say which >>>>>> scope is permitted for the /comments API. The second can be solved by >>>>>> using >>>>>> our usual permission model in APIM v3.0.0. >>>>>> >>>>>> On Tue, May 9, 2017 at 10:10 AM, Ayyoob Hamza <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> This won't tackle the problem Musthaq suggested which requires >>>>>>> validation in the backend. >>>>>>> >>>>>>> *Ayyoob Hamza* >>>>>>> *Senior Software Engineer* >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>>> >>>>>>> On Tue, May 9, 2017 at 10:01 AM, Ayyoob Hamza <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We had a similar requirement to have a fine grained access for >>>>>>>> users in IoTS and we went with the approach of assigning permission for >>>>>>>> scope rather than roles. >>>>>>>> >>>>>>>> *Ayyoob Hamza* >>>>>>>> *Senior Software Engineer* >>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>> email: [email protected] cell: +94 77 1681010 <%2B94%2077%207779495> >>>>>>>> >>>>>>>> On Tue, May 9, 2017 at 9:51 AM, Mushthaq Rumy <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Prasanna/Pubudu, >>>>>>>>> >>>>>>>>> I think if we use scope based validation there will be an issue >>>>>>>>> here. Lets take the same example. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} - >>>>>>>>> comment-delete-scopeUPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>> - >>>>>>>>> comment-update-scope* >>>>>>>>> >>>>>>>>> Scope and roles matching are as follows. >>>>>>>>> >>>>>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>>>>> *comment-**update**-scope : **subscriber-role, **admin-role* >>>>>>>>> *comment-delete-scope : **admin-role* >>>>>>>>> >>>>>>>>> Lets say there are two store users *A* and *B* who have the >>>>>>>>> *subscriber-role. >>>>>>>>> *And user *A* adds a comment to an API (*comment-add-scope*). >>>>>>>>> Then user *B *logs in and he will be able to update that >>>>>>>>> particular comment which user *A *has added since user *B *has >>>>>>>>> the *subscriber-role* too. >>>>>>>>> >>>>>>>>> IMO this should not be allowed. AFAIC we might have to go with >>>>>>>>> user validation. >>>>>>>>> If we can get the logged in user's roles and if that user has >>>>>>>>> admin-role or that particular comment is added by the logged in user >>>>>>>>> we can >>>>>>>>> allow this user to update or delete the comment. WDYT? >>>>>>>>> >>>>>>>>> Thanks & Regards, >>>>>>>>> Mushthaq >>>>>>>>> >>>>>>>>> On Tue, May 9, 2017 at 6:31 AM, Prasanna Dangalla < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Fazlan, >>>>>>>>>> >>>>>>>>>> I think as Ishara and Pubudu have mentioned we can use the scope >>>>>>>>>> validation. >>>>>>>>>> >>>>>>>>>> On Tue, May 9, 2017 at 12:03 AM, Pubudu Gunatilaka < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> + Adding architecture mail group >>>>>>>>>>> >>>>>>>>>>> On Mon, May 8, 2017 at 11:59 PM, Pubudu Gunatilaka < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Fazlan, >>>>>>>>>>>> >>>>>>>>>>>> As Ishara mentioned above, we can do this with scope >>>>>>>>>>>> validation. Each and every resource has a scope. The scope is >>>>>>>>>>>> associated >>>>>>>>>>>> with one or more roles. Consider the following example. >>>>>>>>>>>> >>>>>>>>>>>> Resource and scope matching are as follows. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> *GET /apis/{apiId}/comments/{commentId} - >>>>>>>>>>>> comment-add-scopeDELETE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>> - >>>>>>>>>>>> comment-manage-scopeUPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>> - >>>>>>>>>>>> comment-manage-scope* >>>>>>>>>>>> >>>>>>>>>>>> Scope and roles matching are as follows. >>>>>>>>>>>> >>>>>>>>>>>> *comment-add-scope : subscriber-role, **admin-role* >>>>>>>>>>>> *comment-manage-scope : admin-role* >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> @Pubudu: >>>>>>>>>> >>>>>>>>>> IMO a person who adds a comment should have the UPDATE privilege >>>>>>>>>> as well. DELETE can be restricted to admin. Like wise we might find >>>>>>>>>> many >>>>>>>>>> combinations with different use cases. So I think its better to >>>>>>>>>> decouple >>>>>>>>>> this *comment-manage-scope *to two different scopes as >>>>>>>>>> *comment-update-scope *and *comment-delete-scope. *If we do >>>>>>>>>> this, we can assign it to respective roles in scope and role mapping >>>>>>>>>> for >>>>>>>>>> different use cases. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Prasanna >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> When a user hits the GET resource we can do the following. >>>>>>>>>>>> >>>>>>>>>>>> 1. Retrieve the scope of the resource >>>>>>>>>>>> 2. Retrieve the roles of the scope >>>>>>>>>>>> 3. Validate the user based on the role and allow or deny the >>>>>>>>>>>> request. >>>>>>>>>>>> >>>>>>>>>>>> Thank you! >>>>>>>>>>>> >>>>>>>>>>>> On Mon, May 8, 2017 at 5:04 PM, Fazlan Nazeem <[email protected] >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, May 8, 2017 at 3:59 PM, Ishara Cooray < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> How about introducing scope based permission model? >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can define scope for each resource and validate against >>>>>>>>>>>>>> the logged in user scopes. >>>>>>>>>>>>>> This way we can let the admin to edit the scope so that he >>>>>>>>>>>>>> can fine grain the access to these resources. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> My understanding is, with scopes what we can decide is whether >>>>>>>>>>>>> a particular user has access to hit an API resource URL. In my >>>>>>>>>>>>> example all >>>>>>>>>>>>> users with subscriber scope will have access to hit the api, but >>>>>>>>>>>>> the >>>>>>>>>>>>> question is, out of those subscribers how do we choose the right >>>>>>>>>>>>> subscriber >>>>>>>>>>>>> for the right action. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>> Ishara Cooray >>>>>>>>>>>>>> Senior Software Engineer >>>>>>>>>>>>>> Mobile : +9477 262 9512 <+94%2077%20262%209512> >>>>>>>>>>>>>> WSO2, Inc. | http://wso2.com/ >>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, May 8, 2017 at 3:42 PM, Fazlan Nazeem < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is about how we should handle access permission for >>>>>>>>>>>>>>> subresources in api store. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Parent Resource Access * >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Consider the following REST calls. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> GET /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>> GET apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At the moment we are not checking whether a particular user >>>>>>>>>>>>>>> has read access to the specific api before we retrieve the >>>>>>>>>>>>>>> requested >>>>>>>>>>>>>>> comment or document. Is it fine to ignore this check for these >>>>>>>>>>>>>>> apis >>>>>>>>>>>>>>> assuming that a user might be already having read access to the >>>>>>>>>>>>>>> api because >>>>>>>>>>>>>>> he already knows the uuid of the api? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Or should we be doing an explicit permission validation? Do >>>>>>>>>>>>>>> we have any drawbacks in doing this check? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Subresource Update/Delete* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Consider the following REST api calls done by a user in >>>>>>>>>>>>>>> store. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DELETE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>> UPDATE /apis/{apiId}/comments/{commentId} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> DELETE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>> UPDATE /apis/{apiId}/documents/{documentId} >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In order to restrict who can update and delete these >>>>>>>>>>>>>>> subresources, we can pass the username to DAO layer and check >>>>>>>>>>>>>>> who created >>>>>>>>>>>>>>> it, and allow only that person to do these modifications. But >>>>>>>>>>>>>>> there could >>>>>>>>>>>>>>> be a use-case where another user(admin) will need to delete or >>>>>>>>>>>>>>> update a >>>>>>>>>>>>>>> resource created by someone else. If we restrict only the >>>>>>>>>>>>>>> creator to do >>>>>>>>>>>>>>> these actions, then we cannot support such a use-case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Appreciate your thoughts on this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Thanks & Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Fazlan Nazeem >>>>>>>>>>>>> >>>>>>>>>>>>> *Senior Software Engineer* >>>>>>>>>>>>> >>>>>>>>>>>>> *WSO2 Inc* >>>>>>>>>>>>> Mobile : +94772338839 >>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194> >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>>> Software Engineer >>>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> *Pubudu Gunatilaka* >>>>>>>>>>> Committer and PMC Member - Apache Stratos >>>>>>>>>>> Software Engineer >>>>>>>>>>> WSO2, Inc.: http://wso2.com >>>>>>>>>>> mobile : +94774078049 <%2B94772207163> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mushthaq Rumy >>>>>>>>> *Software Engineer* >>>>>>>>> Mobile : +94 (0) 779 492140 <%2B94%20%280%29%20773%20451194> >>>>>>>>> Email : [email protected] >>>>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>>>> lean . enterprise . middleware. >>>>>>>>> >>>>>>>>> <http://wso2.com/signature> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Nuwan Dias >>>>>> >>>>>> Software Architect - WSO2, Inc. http://wso2.com >>>>>> email : [email protected] >>>>>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> >>>>> Fazlan Nazeem >>>>> >>>>> *Senior Software Engineer* >>>>> >>>>> *WSO2 Inc* >>>>> Mobile : +94772338839 >>>>> <%2B94%20%280%29%20773%20451194> >>>>> [email protected] >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 <071%20306%208779> >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Bhathiya Jayasekara* >>> *Associate Technical Lead,* >>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>> >>> *Phone: +94715478185 <071%20547%208185>* >>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>> <http://www.linkedin.com/in/bhathiyaj>* >>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>> *Blog: http://movingaheadblog.blogspot.com >>> <http://movingaheadblog.blogspot.com/>* >>> >> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 <+94%2071%20306%208779> >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <077%20777%205729> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <071%20306%208779> <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda. blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
