I created a blank project, and the same thing happened again.
I think it is the default behavior of Persistance Permission Resolver.
Is that correct ?
Well it seems like i should move to Drols with RuleBased Permission Resolver
lol yeah exactly! thats what happened to my accountpermission class and some how the delete to some other object was making a delete call to AccountPermission table. which was very annoying.. I did it some other way i think.
I think i ran a delete sql native query to by pass the delete routine from the EntityHome.
but it sounds amazingly stupid how will it do that.
No one answers on these forums that much. looks like Seam 2 is already dead and no one is even bothering to resuscitate it.
I've never used the jpa permission store but i can imagine that this behavior is absolutely correct.
I would say it works like this (without having the knowledge):
You create an object and give permission to a user to edit it. Seam stores the object and also stores the objectpermission for the user. This you should see also in your logs.? If you now delete this object seam is clever enough and removes also the permission object. Hopefully, else you would most probably run into a foreignkey issue.
So i would say this is normal :)
ok.. thanks for the reply... does seem like a possible answer. but what in case there is nothing related in the permission store related to THAT specific object..
What you say is plausible and seems like a good explanation but in my case at least there were no permissions for the object that I was trying to delete and may be thats the reason it was trying to delete it but in my case the accountpermission table was on a totally different schema where the user had no access to it would end up in an exception. So for me either I had to deal with an exception which I was not expecting or just remove it by passing the permission store and throwing a native query to the DB.
I had a similar topic opened on this forum some time back for the same issue, i dont think any body answered I guess, but the details are there.
What you say is may be true and is doing a smart delete as well but some time too much smartness gets in your way and it was deleting any reference in the account permission whether it exists or not.
there should be a cascading option also defined for THAT level i think. may be thats a good idea.