I think there are multiple issues in the user model, that is surfacing through this discussion.
1. Allowed only one App Owner due to the restriction of not letting to delete Well, think of the scale. Sat that, there are thousands of apps and a user is the owner of hundreds of them. And that user decides to leave the organization. AF will crash, as the user cannot be removed form the system. Or in order to facilitate that deletion, we will have to go and identify new owner for hundreds of apps. Sounds to be broken with scale. The real world model will be, once the apps hit production, and after few iterations, either they will live or will die. And if they live, there will be users, and DevOps who keep an eye, but no "project team" needed, neither an app owner. 2. API-M integration crash with multiple owners Again, there are two angles to it. First, I think, it is wrong to have a user used to manage the API-M dependency. Again think scale. A user who owns hundreds of apps leaves the org, and now, we need to re-assign them all? Does not sound like a scaling solution. Why not use roles here? 3. If we really need a super owner, we need to think of a new role of "app Admin" which is different form "app owners" and which is different from "app creator" Someone creates the app. Then is in the project for some time, and moved to another project. So, app creator, while being a unique identity, cannot be the sole owner of an app for the whole lifetime. It should be the "app Admin" who own this, and then admin should be a role, rather than a user, so that we can have multiple people in there if needed. It looks to me, we are using app owner concept both for app admin and app stakeholder. Which is a problem. They are not the same. It is admin role we need to use for integration points such as API-M and it is the app owner role with a stakeholder (client) perspective that we need to use for monitoring, mentoring and managing the app. So, can we re-visit the whole user/role mapping for the apps please? IMHO, current design, if we keep to patch up as it is, will hit us with road-blocks as it seems too rigid and restrictive. On Thu, Jul 18, 2013 at 2:57 PM, Dimuthu Leelarathne <[email protected]>wrote: > > > > On Thu, Jul 18, 2013 at 2:50 PM, Dimuthu Leelarathne <[email protected]>wrote: > >> >> >> >> On Thu, Jul 18, 2013 at 2:22 PM, Asanka Dissanayake <[email protected]>wrote: >> >>> Hi Sameera, >>> We (me,sumedha,manisha,dimuthu) had an offline chat very similar to >>> this.yes, this is an option. We can start implementing this after getting >>> this thing confirmed. >>> @ Dimuthu. WDYT ? >>> >> >> +1 for not pushing to live until the APIM is sorted out. >> >> +1 for implementing a single user to be used for APIM. >> > > P.S. lets make this user transparent in the appmgt ui. Of course we cannot > help it but we'll see him in carbon management console. > > thanks, > dimuthu > > >> >> >> thanks, >> dimuthu >> >> >>> >>> >>> On Thu, Jul 18, 2013 at 2:13 PM, Sameera Perera <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> If you introduce a new role, that has the same permissions as App >>>> Owner; you could keep everything as is. >>>> For e.g. in Google Docs, you have one owner, multiple editors. >>>> Owner needn't have any special permission that other "editors" have. >>>> He'll just be the person who initially created the app. >>>> >>>> Is there any reason, this approach will not work? >>>> >>>> >>>> On Thu, Jul 18, 2013 at 1:55 PM, Asanka Dissanayake >>>> <[email protected]>wrote: >>>> >>>>> Hi, >>>>> User invitation and update for application owner implemented and >>>>> tested in 105 machine. But there are several problems arises. >>>>> 1-API manager subscriptions are only allowed for the user that created >>>>> the app >>>>> 2-and many other places that checks whether the logged in user is app >>>>> owner, >>>>> 3-even in block level method such as getAppOwner needs to be changed >>>>> >>>>> So IMHO , we should not push this to live until we get these solved. >>>>> >>>>> >>>>> On Thu, Jul 18, 2013 at 11:27 AM, Shiroshica Kulatilake < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> The requirement of Samisa is also part of the aPaaS story as Sameera >>>>>> pointed out very correctly. >>>>>> >>>>>> So we need to think in that line as well. >>>>>> >>>>>> Will we be doing a similar QSP to introduce aPaaS inhouse ? if not >>>>>> will we be migrating this into aPaaS ? >>>>>> >>>>>> Thank you, >>>>>> Shiro >>>>>> >>>>>> >>>>>> On Thu, Jul 18, 2013 at 10:05 AM, Manisha Gayathri >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> Hi Samisa, >>>>>>> >>>>>>> Yes. As Asanka mentioned, we will have considered this aspect for >>>>>>> the internal QSP. >>>>>>> We have removed having multiple app owner concept in this 1.0.0 >>>>>>> release, basically because of the fact that if all the app owners were >>>>>>> deleted, then the app is going to be unusable. For that we will disable >>>>>>> the >>>>>>> App Owner Deletion permission. >>>>>>> >>>>>>> At the end of the QSP, the AF will be able to maintain multiple app >>>>>>> owners per app and we will be pushing these features to the AF Live as >>>>>>> well. To keep track of this, have created the JIRA [1] and [2]. >>>>>>> >>>>>>> [1]. https://wso2.org/jira/browse/APPFAC-1419 >>>>>>> [2]. https://wso2.org/jira/browse/APPFAC-1420 >>>>>>> >>>>>>> Thanks >>>>>>> Manisha >>>>>>> >>>>>>> On Thu, Jul 18, 2013 at 9:18 AM, Samisa Abeysinghe >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> In addition to having multiple users in app owner role, there is >>>>>>>> more into this, in terms of perspectives. >>>>>>>> >>>>>>>> Lets get the feature in first, and we can dig more into pespectives >>>>>>>> later. >>>>>>>> >>>>>>>> On the subject of patching, I think we agreed that we will keep >>>>>>>> updating the live one on a regular basis, meaning, we will do builds >>>>>>>> (and >>>>>>>> thus not just the support patches, rather "build" number increment >>>>>>>> releases >>>>>>>> of AF) on a weekly basis on AF. So I hope these features will be >>>>>>>> available >>>>>>>> "tomorrow" rather than in next October. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 18, 2013 at 8:38 AM, Shiroshica Kulatilake < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> If this change (and others that we may discover through doing the >>>>>>>>> QSP) are to be for AF in general then shouldn't we also have these as >>>>>>>>> Jiras >>>>>>>>> which get committed into the support branch as well ? Then such >>>>>>>>> additions >>>>>>>>> will go through the normal process of adding or improving the product >>>>>>>>> - >>>>>>>>> e.g. review, test etc.. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Shiro >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 18, 2013 at 8:11 AM, Asanka Dissanayake < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi samisa, >>>>>>>>>> It is ok to have multiple app owners for an app. But at the mean >>>>>>>>>> time it is restricted by UI. Sumedha and tried it using direct back >>>>>>>>>> end >>>>>>>>>> call yesterday. It worked. There are slight changes in the front end >>>>>>>>>> to be >>>>>>>>>> done. Once they are done we are good to go. >>>>>>>>>> On 18 Jul 2013 07:23, "Samisa Abeysinghe" <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> The more I try to use AF, the more I feel the need for $subject >>>>>>>>>>> >>>>>>>>>>> For e.g. we are developing a series of apps for internal WSO2 >>>>>>>>>>> use. In here, Maheshica and myself act as the stakeholders of the >>>>>>>>>>> apps. >>>>>>>>>>> When I map the use case to AF, not being able to be owners of >>>>>>>>>>> the same app as stakeholders is a major blocker. >>>>>>>>>>> >>>>>>>>>>> Here, app owner is a role, and there could be multiple users who >>>>>>>>>>> play the role. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Samisa... >>>>>>>>>>> >>>>>>>>>>> Samisa Abeysinghe >>>>>>>>>>> VP Engineering >>>>>>>>>>> WSO2 Inc. >>>>>>>>>>> http://wso2.com >>>>>>>>>>> http://wso2.org >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Shiroshica Kulatilake >>>>>>>>> >>>>>>>>> Architect, >>>>>>>>> WSO2, Inc. http://wso2.com/ >>>>>>>>> Phone: +94 776523867 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Samisa... >>>>>>>> >>>>>>>> Samisa Abeysinghe >>>>>>>> VP Engineering >>>>>>>> WSO2 Inc. >>>>>>>> http://wso2.com >>>>>>>> http://wso2.org >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ~Regards >>>>>>> *Manisha Eleperuma* >>>>>>> Software Engineer, Solutions TG >>>>>>> WSO2, Inc.: http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> *blog: http://manisha-eleperuma.blogspot.com/* >>>>>>> *mobile: +94 71 8279777* >>>>>>> * >>>>>>> * >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Shiroshica Kulatilake >>>>>> >>>>>> Architect, >>>>>> WSO2, Inc. http://wso2.com/ >>>>>> Phone: +94 776523867 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Asanka Dissanayake >>>>> Software Engineer* >>>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com* >>>>> * >>>>> email: [email protected] <[email protected]>, blog: >>>>> cyberwaadiya.blogspot.com, asankastechtalks.wordpress.com mobile: +94 >>>>> 71 8373821* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> ------------------------------ >>>> >>>> *Sameera Perera* >>>> Senior Manager, Cloud Technology Group >>>> gtalk: [email protected] >>>> *WSO2, Inc.* <http://wso2.com/> >>>> lean.enterprise.middleware >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> *Asanka Dissanayake >>> Software Engineer* >>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com* >>> * >>> email: [email protected] <[email protected]>, blog: >>> cyberwaadiya.blogspot.com, asankastechtalks.wordpress.com mobile: +94 >>> 71 8373821* >>> >> >> >> >> -- >> Dimuthu Leelarathne >> Architect & Product Lead of App Factory >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> > > > > -- > Dimuthu Leelarathne > Architect & Product Lead of App Factory > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile : 0773661935 > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
