security permission
Locked
 
|
HI Guys,
I have a question. Is there a particular reason why the permission which is added manually ( i.e. not selected from the permissions list) on Security-> permission tab is NOT get saved to SecurityPermission entity where all the permissions are stored? It appears that manually added permission just stored in SecurityGroupPermission to make a mapping to group, but not to SecurityPermission. While normally it would require foreign key constraint SecurityGroupPermission - > SecurityPermission on permissionId field? Please, let me know. Thanks. |
|
|
if I understand you question, not all security permission are added
automatically, otherwise there would be no reason to have a granulated permission scheme. for how they are connected refer to https://demo.hotwaxmedia.com/webtools/control/ViewRelations?entityName=SecurityGroup if you look at https://demo.hotwaxmedia.com/webtools/control/ArtifactInfo and search for security you will see all the artifacts that are used. Should give you a better idea on how they are implemented. JohnBrown sent the following on 5/1/2008 10:44 AM: > HI Guys, > > I have a question. Is there a particular reason why the permission which is > added manually ( i.e. not selected from the permissions list) on Security-> > permission tab is NOT get saved to SecurityPermission entity where all the > permissions are stored? It appears that manually added permission just > stored in SecurityGroupPermission to make a mapping to group, but not to > SecurityPermission. While normally it would require foreign key constraint > SecurityGroupPermission - > SecurityPermission on permissionId field? > > Please, let me know. Thanks. |
|
|
In reply to this post by masionas
There is a one-nofk relation between SecurityGroupPermission -->
SecurityPermission on permissionId field. I think, this is the reason its not giving fk error. If we going to add new security group and than want to add permission(s) using Ui, It should also add this permission to SecurityPermission, Since this is the entity which holds the list of Security Permission in system. Is there any specific reason it is not done in Ui. Vikas On Thu, May 1, 2008 at 11:14 PM, JohnBrown <[hidden email]> wrote: > > HI Guys, > > I have a question. Is there a particular reason why the permission which > is > added manually ( i.e. not selected from the permissions list) on > Security-> > permission tab is NOT get saved to SecurityPermission entity where all the > permissions are stored? It appears that manually added permission just > stored in SecurityGroupPermission to make a mapping to group, but not to > SecurityPermission. While normally it would require foreign key constraint > SecurityGroupPermission - > SecurityPermission on permissionId field? > > Please, let me know. Thanks. > -- > View this message in context: > http://www.nabble.com/security-permission-tp16993344p16993344.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > > |
|
|
Yes, that is what I mean. The manually added permission for whatever reason did not go to SecurityPermission entity which holds the list of permissions.
|
|
|
Hey Guys,
So is it a bug or feature that aded permission does not get saved to SecurityPermission entity?
|
|
|
Hi John,
In this case, I think it is a mistake. It shouldn't be a "one-nofk" relation. Should be a "one" relation. Not sure why there is any reason for this to be "one-nofk". This isn't the usual "[primary key, fromDate]" composite key issue. That would have a reason for ditching the FK. The SecurityGroupPermission entity doesn't have fromDate/thruDate. I don't think it is trying to keep an audit trail by ditching the FK. Jonathon JohnBrown wrote: > Hey Guys, > > So is it a bug or feature that aded permission does not get saved to > SecurityPermission entity? > > > JohnBrown wrote: >> Yes, that is what I mean. The manually added permission for whatever >> reason did not go to SecurityPermission entity which holds the list of >> permissions. >> >> >> Vikas Mayur-2 wrote: >>> There is a one-nofk relation between SecurityGroupPermission --> >>> SecurityPermission on permissionId field. >>> I think, this is the reason its not giving fk error. >>> >>> If we going to add new security group and than want to add permission(s) >>> using Ui, It should also add this permission to SecurityPermission, Since >>> this is the entity which holds the list of Security Permission in system. >>> Is >>> there any specific reason it is not done in Ui. >>> >>> Vikas >>> >>> >>> On Thu, May 1, 2008 at 11:14 PM, JohnBrown <[hidden email]> wrote: >>> >>>> HI Guys, >>>> >>>> I have a question. Is there a particular reason why the permission which >>>> is >>>> added manually ( i.e. not selected from the permissions list) on >>>> Security-> >>>> permission tab is NOT get saved to SecurityPermission entity where all >>>> the >>>> permissions are stored? It appears that manually added permission just >>>> stored in SecurityGroupPermission to make a mapping to group, but not to >>>> SecurityPermission. While normally it would require foreign key >>>> constraint >>>> SecurityGroupPermission - > SecurityPermission on permissionId field? >>>> >>>> Please, let me know. Thanks. >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/security-permission-tp16993344p16993344.html >>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>> >>>> >>> >> > |
|
|
It is VERY explicitly designed to be a one-nofk, in other words in the SecurityGroupPermission the SecurityPermission being referred to does not have to exist. If you don't create it, it won't exist, but either way the permission settings (in SecurityGroupPermission) and the permission checking code don't care at all. The main reason for this is the support for entity-specific permissions, and there would be thousands of those so we don't want to create them explicitly. -David On May 8, 2008, at 10:28 PM, Jonathon -- Improov wrote: > Hi John, > > In this case, I think it is a mistake. It shouldn't be a "one-nofk" > relation. Should be a "one" relation. Not sure why there is any > reason for this to be "one-nofk". > > This isn't the usual "[primary key, fromDate]" composite key issue. > That would have a reason for ditching the FK. > > The SecurityGroupPermission entity doesn't have fromDate/thruDate. I > don't think it is trying to keep an audit trail by ditching the FK. > > Jonathon > > JohnBrown wrote: >> Hey Guys, >> So is it a bug or feature that aded permission does not get saved to >> SecurityPermission entity? >> JohnBrown wrote: >>> Yes, that is what I mean. The manually added permission for whatever >>> reason did not go to SecurityPermission entity which holds the >>> list of >>> permissions. >>> >>> >>> Vikas Mayur-2 wrote: >>>> There is a one-nofk relation between SecurityGroupPermission --> >>>> SecurityPermission on permissionId field. >>>> I think, this is the reason its not giving fk error. >>>> >>>> If we going to add new security group and than want to add >>>> permission(s) >>>> using Ui, It should also add this permission to >>>> SecurityPermission, Since >>>> this is the entity which holds the list of Security Permission in >>>> system. >>>> Is >>>> there any specific reason it is not done in Ui. >>>> >>>> Vikas >>>> >>>> >>>> On Thu, May 1, 2008 at 11:14 PM, JohnBrown <[hidden email]> >>>> wrote: >>>> >>>>> HI Guys, >>>>> >>>>> I have a question. Is there a particular reason why the >>>>> permission which >>>>> is >>>>> added manually ( i.e. not selected from the permissions list) on >>>>> Security-> >>>>> permission tab is NOT get saved to SecurityPermission entity >>>>> where all >>>>> the >>>>> permissions are stored? It appears that manually added >>>>> permission just >>>>> stored in SecurityGroupPermission to make a mapping to group, >>>>> but not to >>>>> SecurityPermission. While normally it would require foreign key >>>>> constraint >>>>> SecurityGroupPermission - > SecurityPermission on permissionId >>>>> field? >>>>> >>>>> Please, let me know. Thanks. >>>>> -- >>>>> View this message in context: >>>>> http://www.nabble.com/security-permission-tp16993344p16993344.html >>>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>>> >>>>> >>>> >>> > |
|
|
I don't understand. Explain?
Jonathon David E Jones wrote: > > It is VERY explicitly designed to be a one-nofk, in other words in the > SecurityGroupPermission the SecurityPermission being referred to does > not have to exist. > > If you don't create it, it won't exist, but either way the permission > settings (in SecurityGroupPermission) and the permission checking code > don't care at all. > > The main reason for this is the support for entity-specific permissions, > and there would be thousands of those so we don't want to create them > explicitly. > > -David > > > On May 8, 2008, at 10:28 PM, Jonathon -- Improov wrote: > >> Hi John, >> >> In this case, I think it is a mistake. It shouldn't be a "one-nofk" >> relation. Should be a "one" relation. Not sure why there is any reason >> for this to be "one-nofk". >> >> This isn't the usual "[primary key, fromDate]" composite key issue. >> That would have a reason for ditching the FK. >> >> The SecurityGroupPermission entity doesn't have fromDate/thruDate. I >> don't think it is trying to keep an audit trail by ditching the FK. >> >> Jonathon >> >> JohnBrown wrote: >>> Hey Guys, >>> So is it a bug or feature that aded permission does not get saved to >>> SecurityPermission entity? >>> JohnBrown wrote: >>>> Yes, that is what I mean. The manually added permission for whatever >>>> reason did not go to SecurityPermission entity which holds the list of >>>> permissions. >>>> >>>> >>>> Vikas Mayur-2 wrote: >>>>> There is a one-nofk relation between SecurityGroupPermission --> >>>>> SecurityPermission on permissionId field. >>>>> I think, this is the reason its not giving fk error. >>>>> >>>>> If we going to add new security group and than want to add >>>>> permission(s) >>>>> using Ui, It should also add this permission to SecurityPermission, >>>>> Since >>>>> this is the entity which holds the list of Security Permission in >>>>> system. >>>>> Is >>>>> there any specific reason it is not done in Ui. >>>>> >>>>> Vikas >>>>> >>>>> >>>>> On Thu, May 1, 2008 at 11:14 PM, JohnBrown <[hidden email]> >>>>> wrote: >>>>> >>>>>> HI Guys, >>>>>> >>>>>> I have a question. Is there a particular reason why the permission >>>>>> which >>>>>> is >>>>>> added manually ( i.e. not selected from the permissions list) on >>>>>> Security-> >>>>>> permission tab is NOT get saved to SecurityPermission entity where >>>>>> all >>>>>> the >>>>>> permissions are stored? It appears that manually added permission >>>>>> just >>>>>> stored in SecurityGroupPermission to make a mapping to group, but >>>>>> not to >>>>>> SecurityPermission. While normally it would require foreign key >>>>>> constraint >>>>>> SecurityGroupPermission - > SecurityPermission on permissionId field? >>>>>> >>>>>> Please, let me know. Thanks. >>>>>> -- >>>>>> View this message in context: >>>>>> http://www.nabble.com/security-permission-tp16993344p16993344.html >>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>>>> >>>>>> >>>>> >>>> >> > > |
|
|
Hi John,
Well, I didn't get a response for that. But in answer to you regarding whether it's a bug or design, I would say it's design. In much of OFBiz, FK constraints are ditched, possibly for certain programming conveniences. One example is the numerous "[primary key, fromDate]" composite keys. There is a proper way to do this, but perhaps David can better explain the rationale behind ditching FKs in those many areas. I'm not saying it's right. The SecurityGroupPermission could have a third field "flexiblePermission" that could hold anything (eg. "myOwnRecord_123_WRITE" or "myOwnRecord_456_READ"). It should still have an FK where FKs are possible, so it points without errors to entity SecurityPermission.permissionId. That is, assuming I got David's initial explanation right. (That would easily give us 2 explicit kinds of SecurityGroupPermissions: real and interpreted.) Employ FKs to limit programming mistakes wherever possible (prevent inconsistent DB state). Forego FKs where absolutely impossible to use FKs. So in answer to your question, I'd say it's not a bug, but a design. Chris Howe mentioned this quite a few times, about keeping primary keys clean and not incorrectly coupled to interpreted application data. But Chris is probably a database designer. Whatever works in OFBiz is useful. Jonathon Jonathon -- Improov wrote: > I don't understand. Explain? > > Jonathon > > David E Jones wrote: >> >> It is VERY explicitly designed to be a one-nofk, in other words in the >> SecurityGroupPermission the SecurityPermission being referred to does >> not have to exist. >> >> If you don't create it, it won't exist, but either way the permission >> settings (in SecurityGroupPermission) and the permission checking code >> don't care at all. >> >> The main reason for this is the support for entity-specific >> permissions, and there would be thousands of those so we don't want to >> create them explicitly. >> >> -David >> >> >> On May 8, 2008, at 10:28 PM, Jonathon -- Improov wrote: >> >>> Hi John, >>> >>> In this case, I think it is a mistake. It shouldn't be a "one-nofk" >>> relation. Should be a "one" relation. Not sure why there is any >>> reason for this to be "one-nofk". >>> >>> This isn't the usual "[primary key, fromDate]" composite key issue. >>> That would have a reason for ditching the FK. >>> >>> The SecurityGroupPermission entity doesn't have fromDate/thruDate. I >>> don't think it is trying to keep an audit trail by ditching the FK. >>> >>> Jonathon >>> >>> JohnBrown wrote: >>>> Hey Guys, >>>> So is it a bug or feature that aded permission does not get saved to >>>> SecurityPermission entity? >>>> JohnBrown wrote: >>>>> Yes, that is what I mean. The manually added permission for whatever >>>>> reason did not go to SecurityPermission entity which holds the list of >>>>> permissions. >>>>> >>>>> >>>>> Vikas Mayur-2 wrote: >>>>>> There is a one-nofk relation between SecurityGroupPermission --> >>>>>> SecurityPermission on permissionId field. >>>>>> I think, this is the reason its not giving fk error. >>>>>> >>>>>> If we going to add new security group and than want to add >>>>>> permission(s) >>>>>> using Ui, It should also add this permission to >>>>>> SecurityPermission, Since >>>>>> this is the entity which holds the list of Security Permission in >>>>>> system. >>>>>> Is >>>>>> there any specific reason it is not done in Ui. >>>>>> >>>>>> Vikas >>>>>> >>>>>> >>>>>> On Thu, May 1, 2008 at 11:14 PM, JohnBrown <[hidden email]> >>>>>> wrote: >>>>>> >>>>>>> HI Guys, >>>>>>> >>>>>>> I have a question. Is there a particular reason why the >>>>>>> permission which >>>>>>> is >>>>>>> added manually ( i.e. not selected from the permissions list) on >>>>>>> Security-> >>>>>>> permission tab is NOT get saved to SecurityPermission entity >>>>>>> where all >>>>>>> the >>>>>>> permissions are stored? It appears that manually added permission >>>>>>> just >>>>>>> stored in SecurityGroupPermission to make a mapping to group, but >>>>>>> not to >>>>>>> SecurityPermission. While normally it would require foreign key >>>>>>> constraint >>>>>>> SecurityGroupPermission - > SecurityPermission on permissionId >>>>>>> field? >>>>>>> >>>>>>> Please, let me know. Thanks. >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://www.nabble.com/security-permission-tp16993344p16993344.html >>>>>>> Sent from the OFBiz - User mailing list archive at Nabble.com. >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >> > > |
|
|
On May 10, 2008, at 6:46 AM, Jonathon -- Improov wrote: > Chris Howe mentioned this quite a few times, about keeping primary > keys clean and not incorrectly coupled to interpreted application > data. But Chris is probably a database designer. Personally I'd rather go with recommendations from someone like Joe Celko (or many other great experts, teachers, and authors like him)... Meaningless (ie artificial) primary keys are usually a very poor alternative to a well defined composite primary key. -David |
|
|
Hi David,
Sorry for late reply. Busy. And mailbox hung. :) > Personally I'd rather go with recommendations from someone like Joe > Celko (or many other great experts, teachers, and authors like him)... > Meaningless (ie artificial) primary keys are usually a very poor > alternative to a well defined composite primary key. I think we may have misunderstood each other. We may also have misunderstood Joe Celko and his take on artificial vs natural keys. Celko's preference for natural keys DOES NOT involve dumping referential integrity and risking database inconsistency. According to Celko, there are these kinds of keys: natural, artificial and surrogate (among others). See http://www.intelligententerprise.com/030320/605celko1_1.jhtml His first preference is natural keys, of course. But before we think that [firstName, lastName, fromDate] is a natural key, note that this particular table (possibly Person?) really only naturally uses "firstName" and "lastName" as _unique_ identifiers for records. How? Why? This is evidenced by the many [firstName, lastName] references to the records of such table (one example out of many). Also, we really don't want 2 persons with the same name, do we? Who are we kidding? :) (Ok, herein lies another big snag/limitation for this current data model, but let's please keep our vehement opinions to ourselves, unless we truly believe we can foster real understanding with each other.) But it IS a natural key, we want to argue? The unique identifier is really those 3 fields, true. Sadly, because "fromDate" is likely to be changed (perhaps user makes a mistake, and wants to re-enter), it is not a good key. And that is the most potent argument against using such "forced" natural keys, that real-world data do change. Also Chris Howe's main argument against using data-based keys. Still, at risk of stating the dumb obvious, we really don't want 2 persons with the same name. The fromDate thruDate fields are really for audit trails. The change propagation required when a part of a key value changes is obvious. Check out concepts like "coupling", "decoupling", etc. Let me know if I need to unravel my babble here. I don't think Celko would want a key whose values need to change. Celko's preferences for keys, in decreasing order (I can't remember where i read his personal comment): 1. Truly natural keys, eg ISBN. (These keys really DO NOT change.) 2. Natural key consisting of data record values. (Yup, the dreaded composite key with many values, values that may change over time.) 3. Surrogate key. (Big Catch here! Celko outlined several nifty tricks to generate such keys from data record values. One eg is hashing. Main idea is that keys must not be artificial and meaningless, but must be computably verifiable. Verify for what? Verify to validate that key indeed does belong to its attached data record.) The main contention is between the 2nd and 3rd preferences in the "artificial vs natural" debate. In truth, real-world data model designs find scenarios for preferential use of both. If we really want Celko's brand of natural keys, we would want to find attributes that DO NOT change. A person's name can change; the fromDate certainly may change due to entry errors. I'm not an expert on Celko styles, but isn't this a scenario where a cheap surrogate key would be a good stop-gap measure? After all, OFBiz is full of truly artificial keys (SequenceUtil in entity component). Or should we ask Celko if referential integrity is really an over-hyped concept? :) John Brown doesn't seem to think so. I would be shot if I stated so. Jonathon David E Jones wrote: > > On May 10, 2008, at 6:46 AM, Jonathon -- Improov wrote: > >> Chris Howe mentioned this quite a few times, about keeping primary >> keys clean and not incorrectly coupled to interpreted application >> data. But Chris is probably a database designer. > > Personally I'd rather go with recommendations from someone like Joe > Celko (or many other great experts, teachers, and authors like him)... > Meaningless (ie artificial) primary keys are usually a very poor > alternative to a well defined composite primary key. > > -David > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |