Hi Ishara, On Wed, Feb 8, 2017 at 11:58 PM, Ishara Karunarathna <isha...@wso2.com> wrote:
> Hi, > > I think this says "Service providers MAY choose not to permanently delete > the resource" and ask service provider to behave like > resources i deleted. > > So In our case its ok to delete resource when we get the delete request. > Yes our implementation is deleting the resource, and its ok... But the question is at some point, if someone wanted to avoid deleting the resource. This would be a rare case, -as you mentioned we have disable and inactive states- so most of the use cases can covered by those flags.. But if somebody really wanted to avoid deleting the resource, that also ok.. But keep that as an identity store implementation detail, outside parties does not need to know whether the resource got deleted in the data layer, as long as the it receive correct information from the API. Regards, Darshana > And in our implementation we have inactive, and disable option for that to > handle not permanently delete case. > > -Ishara > > On Wed, Feb 8, 2017 at 12:10 PM, Darshana Gunawardana <darsh...@wso2.com> > wrote: > >> Hi Gayan, >> >> On Wed, Feb 8, 2017 at 11:13 PM, Gayan Gunawardana <ga...@wso2.com> >> wrote: >> >>> Hi All, >>> >>> How are we going to support user delete operation in user core ? >>> Currently IdentityStore --> deleteUser operation delete user from user >>> store. Is there any future plan to set delete flag apart from completely >>> deleting user from user store. >>> >> >> Yes this is a good question, and somebody in future would come up with >> this requirement. But can't we say that, it's up to the identity store >> implementation to decide, whether to delete or not to delete from the >> database layer. >> >> In other words we can enforce the same condition for identity store API. >> So if there a delete operation executed, for the identity server's >> perspective that resource is deleted and should not conflict with the way >> identity store delete operation implemented. >> >>> >>> Appreciate your feedback since this is directly affected to SCIM >>> implementation according to [1]. >>> >> >> If we can agree on above behaviour for identity store API, this should >> not affect SCIM level implementation. >> >> WDYT? >> >> Regards, >> >>> >>> >>> [1]https://tools.ietf.org/html/rfc7644#section-3.6 >>> >>> Thanks, >>> Gayan >>> >>> -- >>> Gayan Gunawardana >>> Software Engineer; WSO2 Inc.; http://wso2.com/ >>> Email: ga...@wso2.com >>> Mobile: +94 (71) 8020933 >>> >> >> >> >> -- >> Regards, >> >> >> *Darshana Gunawardana*Associate Technical Lead >> WSO2 Inc.; http://wso2.com >> >> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise . >> Middleware >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Ishara Karunarathna > Associate Technical Lead > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > email: isha...@wso2.com, blog: isharaaruna.blogspot.com, mobile: > +94717996791 <+94%2071%20799%206791> > > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, *Darshana Gunawardana*Associate Technical Lead WSO2 Inc.; http://wso2.com *E-mail: darsh...@wso2.com <darsh...@wso2.com>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
