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 <[EMAIL PROTECTED]>
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.
