while acl_node entries get deleted

those acl table entries will never be used again (new nodes get new nid) thus they are orphan entries

is it responsibility of acl module to erase those ?

CommentFileSizeAuthor
#1 950482_2_content_access.patch645 bytesgiorgosk

Comments

giorgosk’s picture

Status: Active » Needs review
StatusFileSize
new645 bytes

this fixes the problem
I did not seem to find a better way to do it (from the acl api)

salvis’s picture

Status: Needs review » Needs work

This is very inefficient. Please open an issue in the ACL queue and supply patches (for D7 and D6) with a new function acl_delete_acls_by_name($module, $names), where $names is an array.

good_man’s picture

Status: Needs work » Closed (won't fix)

This ACL issue, I'm closing this now, reopen if you have new info.

crea’s picture

Title: on node delete acl table entries not deleted » on node delete acl table entries not deleted
Project: Content Access » ACL
Priority: Minor » Normal
Status: Closed (won't fix) » Active

Still relevant

salvis’s picture

Project: ACL » Content Access

ACL is just an API module. It provides services to create records and services to delete records.

Every client module that uses the former should also use the latter. ACL will not try to guess the intentions of the client.

If the ACL API needs to be enhanced, then see #2.

crea’s picture

@good_man, salvis
I hope you guys agree on a solution. It's a shame when issues get silently closed.

crea’s picture

Title: on node delete acl table entries not deleted » Content Access should delete own node ACLs when node is deleted

Implementing module taking care about it's own ACLs makes sense. So I agree with salvis.
Content Access should delete his own per-node ACL in nodeapi delete hook. ACL module can't do that because it can't know if implementing module wants to reuse ACL or not.

gisle’s picture

Issue summary: View changes
Status: Active » Closed (won't fix)