Hi
I am applying for the 'Attachment Improvements' project for this years GSoC.
Presently, the attachments module lacks the feature of reassigning attachments from one post to another.
The implementation of this feature was proposed in the post "[RFC|Merged] Attachments management" (URL: viewtopic.php?f=84&t=33288). In the previous idea, it was suggested that the feature be implemented by specifying valid post IDs. But it was decided not to use that method as users need not need to know or understand what a "post id" is. Another solution was to implement post selection. But that was lots of work for such a simple functionality.
My proposed solution is to implement attachments as easily linkable/unlink-able objects. We can have a pool of unlinked attachments which can be re-attached to other posts as per requirement. Here, instead of bringing up the whole post selection for reassigning an attachment, we can separate the task to two parts- Add and Remove attachments. In the topic-view mode of MCP, we can add these two operations to the action-list. A moderator can simply select the post from which he wants to remove the attachments and select the remove action. Similarly, when he chooses the Add option, we can display a list of unattached attachments from which he can choose the required one.
I believe it will be easier to implement because when the user chooses to remove attachments, we can simply search the attachments table and update the post_msg_id to some invalid value.(say -1). Similarly the list of unassigned attachments can be obtained by querying for those entries with -1 post_msg_id. Then, we can reassign the newly selected post_msg_id for 'add attachment' option. This can be fine-grained to add/remove individual attachments by considering the attach_id. We could also add a column to the attachments table to keep track of the last post to which an attachment was attached or a comma separated list of posts to which an attachment was attached (i.e. attachment- history) . This could help easily implement features like 'Restore attachment' etc.
The benifits of the new solution are:
The moderator can now remove the attachments of a post without having to delete it. And he can, if required, add the attachment to some other post later on. This can also be implemented at a topic level so that all attachments of a particular topic can be removed. This can come handy in situations such as
> to restructure attachments
> to delete a post but keep its attachments
>temporarily suspend attachments for filtering
> suspend attachments of reported posts
This method also seems considerably easy to implement.
Please suggest whether this idea is useful and/or practical.
[RFC] Attachment improvements
Re: [RFC] Attachment improvements
All in all this sounds doable and useful to me. Looking forward to a patch implementing this.
I don't believe the used column type allows -1 on all databases we support. So you will have to research if this is really possible or come up with an alternative.rahulr92 wrote:I believe it will be easier to implement because when the user chooses to remove attachments, we can simply search the attachments table and update the post_msg_id to some invalid value.(say -1).
If we want to store history we should do so properly in a separate table with information on posts, time of removal etc. and not in a comma separated list of values.rahulr92 wrote:This can be fine-grained to add/remove individual attachments by considering the attach_id. We could also add a column to the attachments table to keep track of the last post to which an attachment was attached or a comma separated list of posts to which an attachment was attached (i.e. attachment- history) . This could help easily implement features like 'Restore attachment' etc.
Re: [RFC] Attachment improvements
I understand that the column is made unsigned in some cases. When I came to think of it, there seems to be a better solution. There is already an 'is_orphan' column in the attachments table which we use in cases where files were uploaded but posts were not submitted. We can simply modify it and make a file an orphan, thereby detaching it. It has an added advantage that we can use the already existing 'Orphaned Attachments' listing feature in ACP under 'Posting'. Also, 'is_orphan' condition is already being checked for in most posting functions. So the amount of code to be written can be reduced.naderman wrote:I don't believe the used column type allows -1 on all databases we support. So you will have to research if this is really possible or come up with an alternative.
A attachment_history table will be implemented with attachment id, post id, time of removal, moderator who removed the attachment, any removal comments etc.naderman wrote:If we want to store history we should do so properly in a separate table with information on posts, time of removal etc. and not in a comma separated list of values.
Please suggest further modifications to this idea, if required.
Re: [RFC] Attachment improvements
If any moderator removes/moves an attachment, other MODs and Admins should be able to review the change.
When you do so, it would be nice to have a feature such that admins can track changes, as well as review changes made my MODs. This is just a rough suggestion, but I think you get the Idearahulr92 wrote:A attachment_history table will be implemented with attachment id, post id, time of removal, moderator who removed the attachment, any removal comments etc.
Please suggest further modifications to this idea, if required.
There is a text here !