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.
