Forum OpenACS Development: Creating a Trash for generic objects

Collapse
1: Creating a Trash for generic objects
Posted by Luis de la Fuente on 09/29/05 06:33 PM
I'm working in a package with which you can move objects, copy them and ...¿delete? I'm studying this issue now. The objects with which i work are FAQs, FORUMs, ASSESSMENTs, STATIC-PORTLETs, NEWs and FOLDERs. By now, the datamanager package is able to copy and move objects.

I would like to ask about my idea to create a trash:

- Create a new object_type, by inserting a row into acs_object_types. It will be 'trash', with 'acs_object' as supertype.

- Create an instance of this object by inserting a roy into acs_objects. Obviously, this new row will have 'trash' as object_type. Package_id and context_id will be both NULL.

Thus, to send an object (e.g. FAQ), the way is moving the contenxt_id to the trash.

This way will make any object as invisible and provides an easy way to recover it. What would you think about this??

Thanks in advance

Collapse
2: Re: Creating a Trash for generic objects (response to 1)
Posted by Rocael Hernández Rizzardini on 09/30/05 07:06 PM
Although the TRASH concept is quite interesting, it is not that simple to implement it, specially since the key issue will be how to deal with the specific applications.
Collapse
3: Re: Creating a Trash for generic objects (response to 1)
Posted by Dave Bauer on 09/30/05 07:17 PM
The idea is good, but the implementation is completely wrong.

Context_id determines permissions inheritance. You can't go changing the permissions of the object without considereing the consequences. When you add an item back from the trash the permissions may be changed again.

So you would really need to think about how this was implemented.

Also packages in general do not use the context_id to determine if an object appears. In general either the package_id or some sort of parent object (cr_items.parent_id in the content repository) is referenced.

One of the ways I have been thinking about fixing this is to make context_id be used as the parent_id for an object hierarchy. Right now you can not rely on this.

Collapse
4: Re: Creating a Trash for generic objects (response to 1)
Posted by Dave Bauer on 09/30/05 07:29 PM
Ok I had an idea :)

Basically lose inherited permissions when an item is put in the trash (with the changing of context_id). This makes sense since the object is "moving" but we need to make sure that the "owner" of the object has permission to get it back out of the trash, and noone else or only others who have admin over the object.

For exmaple, in forums, a user may have admin over the forums package, and possibly should be able to remove any item frm the trash that was from that forum. Since the admin privilege is inherited, it would need to be explictily granted when the item is moved to the Trash.

Anyway, it looks like the trash operation should use some callbacks on insert into the trash and removal frm the trash so any type specific actions can be taken. In addition we would need a type specific way to remove an item from the trash and figure out where it goes after it is removed.

Collapse
5: Re: Creating a Trash for generic objects (response to 1)
Posted by Luis de la Fuente on 10/03/05 04:15 PM
Well, you're rigth with the problem of inheritance of permissions. However, only de site administrator is able to delete objects.

This specification may change, but now the package is being developed following this way.