[RFC] Attachment improvements

Note: We are moving the topics of this forum and it will be deleted at some point

Publish your own request for comments/change or patches for the next version of phpBB. Discuss the contributions and proposals of others. Upcoming releases are 3.2/Rhea and 3.3.
Post Reply
rahulr92
Registered User
Posts: 4
Joined: Sat Mar 24, 2012 7:18 pm

[RFC] Attachment improvements

Post by rahulr92 » Wed Mar 28, 2012 9:02 am

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.

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Karlsruhe, Germany
Contact:

Re: [RFC] Attachment improvements

Post by naderman » Thu Mar 29, 2012 6:51 pm

All in all this sounds doable and useful to me. Looking forward to a patch implementing this.
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).
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: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.
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
Registered User
Posts: 4
Joined: Sat Mar 24, 2012 7:18 pm

Re: [RFC] Attachment improvements

Post by rahulr92 » Fri Mar 30, 2012 6:28 pm

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.
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: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.
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.

_hsr
Registered User
Posts: 42
Joined: Mon Mar 26, 2012 7:06 am

Re: [RFC] Attachment improvements

Post by _hsr » Mon Apr 02, 2012 5:28 am

If any moderator removes/moves an attachment, other MODs and Admins should be able to review the change.
rahulr92 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.
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 Idea :D
There is a text here !

Post Reply