Bump - looks like we let this get away from us as a discussion. We can all agree that the current security system that is in place has some definite areas for improvement - and I think we're getting some where with this discussion - but I don't want it to lose steam in the community since there's a definite deficiency that needs to be address.
I'm hoping to see a bit more action on this front from everyone since there was so much discussion about it. I know that Adrian's working on his design thoughts, Andrew's obviously already put his up there for discussion, David started a couple of threads to elicit information from more people about requirements, and Adam / Jacques / Anil / etc participated in the discussion. Let's get back to this - the system needs it! Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 ----- "Jacques Le Roux" <jacques.le.r...@les7arts.com> wrote: > Hi Andrew, > > Thanks for your answer and your time on this important subject that > should benefit to all the community! > > I had not much time these last days to follow, and I'm still have to > read some messages (notably the couple of threads David opened > lastly). > Thanks to everybody's explanations, my understanding is really better > now. > So from you explanation below I understand that, as I supposed at the > beginning, it's a kind of OFBTOOLS. > Not exactly since you need to have OFBTOOLS to gain access to a > component while you don't need to have access. On the other hand if > you have access you have access to this component. > > Though at this time I did not have a very good understanding (and I'm > sure I still miss some points, but hopefully not about access > ;o), I have discussed about access a bit with a client. > Of course everybody using the ERP side of OFBiz is *very interested* > by access auth. and by all possible improvments of this central > feature. > He gave me an idea, while we were discussing about possible reason of > the access introduction. > As he knew even less than me his interpretation was not right (I was > already able to explain why) but his conclusion is interesting. > He suggested that this may be used to grant all other rights (CRUD > ones). So it would allow to quicly set all other permissions > > What do you think about such a possibility ? A kind of ADMIN stuff. We > could call it "All". > > Also he wondered why we would differentiate create from update. I gave > him some examples (like an automatic task able to create but > not to change) but he was not very convinced. > I then said that this is used by Unix file systems too. It's > subjective but when you refer to Unix/Linux file systems it helps > people to "understand". > Afterward I thought that maybe we could also have a look at how access > control is managed there. After all files are kind of > artifacts, and Linux files systems are known as efficient... > Of course the problematic for files access is far less complex and I > don't say it's a paradigm, but we may find some ideas (if we > need ones at some point). > For instance, it's pretty clear that all files store their own > permissions and all have a combination of them. But I feel anyway > that this is a bit out of topic :/ > Though Adrian is drawing his proposal by looking at Novel Netware, > IRRW. > > Jacques > > From: "Andrew Zeneski" <andrew.zene...@hotwaxmedia.com> > > Jacques, > > > > Thanks for your questions. I will address each one inline... > > > >>> Honestly, in my initial plan I only had 4 permissions > create,read,update and delete. Then after thinking about it, access > >>> seemed > >>> to be a nice extra permission to limit access to applications. > Read is nothing more than what view is today, the only reason > >>> for > >>> using the name "read" instead of "view" is because we can call > them CRUD permissions or ACRUD permissions if we keep access. > >> > >> Yes I see, we need something like OFBTOOLS was used for. > >> But can't we use simply read for that. It seems to me that access > introduce redudancy. > >> What would be the differences between, for instance > >> access:sfa vs read:sfa > >> access:sfa:lead vs read:sfa:lead > >> access:sfa:opportunity vs read:sfa:opportunity > >> etc. > >> > > > > access:sfa would mean that the user can simply access the > application. Where read:sfa would mean, the user can read anything > in > > the SFA application. A better example of this would be the order > manager, where access:order would allow the user to login, but > > read:order would allow the user to view any order/request/etc in > the application. A more granular permission of > > read:order:orderdetail:10000 would limit the user to only reading > the specific order without granting permission to the rest of > > orders/requests/etc. > > > > I would not recommend creating granular permissions for access, > unless we wanted to limit the access of specific "tabs" or areas > > in an application. If we wanted to restrict access to leads in sfa, > then we might create an access:sfa:lead process/permission > > which can then be used to restrict access to the leads section of > the app. Where as read:sfa:lead would mean the user can view > > any lead. > > > > > >> > >>> So, access was added only for granting access to the application. > In most cases this is the only permission a user would need > >>> to > >>> access an app. Let's use Project Manger as an example for this: > >>> > >>> access:project would be the permission required to access the > application. All users of the app would have this permission. > >>> The > >>> create:project permission would be given to a administrator, so > new projects could be created same with create:project:task. > >>> However, create:project:task would have some dynamic access logic > associated which would allow users to create tasks as long > >>> as > >>> they were associated with a project in certain role(s). The > read:project permission could be used to restrict viewing > >>> details > >>> of a project, task, etc. > >> > >> But could we not use read:project instead of access:project, and > then keep only the CRUD permissions ? > >> What we will be missing if we remove access ? > > > > I don't think so. Because read:project would grant the user global > read access to all projects. Instead, when displaying a > > project we might want to attach the process of read:project:10000 > to the UI, to verify the user is indeed allow to read that > > project. Where access:project would just simply allow the user to > login to the tool. > > > >> > >>> This is just how I have been thinking of it, read could also be > used in replace of access, I just thought it would be more > >>> flexible to have the extra permission. Mainly because I believe > that most users only need a permission to access the > >>> application, the other permissions would be handled in a dynamic > way based on how the user is associated in the application. > >> > >> Could you please elaborate on the extra permission and why it's > needed ? > >> > > > > I think I elaborated in the above two comments, so if this is still > vague please let me know and I will try to explain it again > > in a different way. > > > > Thanks again for your questions! > > > > Andrew > >
