Comments

berdir’s picture

Assigned: Unassigned » berdir

My early thread patches contained actions for the first two points. Not sure how to handle the third...

I will create a first patch...

naheemsays’s picture

ilo also had some similar suggestions, no idea if they were just mockups though.

As for the third, maybe a popup window asking for the name?

berdir’s picture

I am unsure.. it should be possible to add the same autocomplete field to the action form but we may have to handle it differently, for example only add tags, and not remove them, as we can't display those that are currently used.

Of course, the ultimative goal is something like gmail.com, but that's not easy to implement.

naheemsays’s picture

Status: Active » Needs work
StatusFileSize
new1.56 KB

The part of the patch that was for the tagging from the filter list is attached - for me the the "more actions..." gets replaced by a tag name, so its not fully working.

Also, ilo's issue on the same thing asking for changes: #380534: per thread(s) Actions mechanism should be refactored from which some things may be good to pass over, in particular the list $argument and also the $account variables.

I did try to experiment with this to add the tags as a separate dropdown, but I did not understand the code enough to figure it out yet.

naheemsays’s picture

Issue tags: +filter, +pmsg ux

tagging

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new6.87 KB

A first patch to get things rolling..

Only implements 1., we may want to split these up into multiple patches maybe, as I'm not sure how to handle the other things yet...

I had to move some code of privatemsg_list_submit() into a helper function but it wasn't that hard after I was able to understand my own code again :)

liam mcdermott’s picture

Status: Needs review » Needs work

And here's a quick review to get the ball rolling (haven't bothered testing the code yet though):

+ // Only execute something if we have a valid callback and <strong>atleast</strong> one checked thread.

This little spelling mistake was already there, but still, may as well fix it.

+function privatemsg_operation_execute($operation, $threads) {

No function documentation. :)
Should this be _privatemsg_operation_execute as it's a helper?

+ // Check if that operation has defined a undo callback

No full stop! :)

+  if (isset($operation['undo callback']) && $undo_function = $operation['undo callback']) {
+  // Add in callback arguments if present.
+    if (isset($operation['undo callback arguments'])) {

Shouldn't this comment be indented once more?

+}
+/**

When I'm coding, in my bike shed, I like to put a blank line between the end of the last function and the function documentation of the next one. :-!

+  foreach ($threads as $thread) {
+    if (db_result(db_query('SELECT COUNT(*) FROM {pm_tags_index} WHERE tag_id = %d AND (uid = %d AND thread_id = %d)', $tag_id, $user->uid, $thread)) == 0) {
+      drupal_set_message(sprintf('INSERT INTO {pm_tags_index} (tag_id, uid, thread_id) VALUES (%d, %d, %d)', $tag_id, $user->uid, $thread));
+      db_query('INSERT INTO {pm_tags_index} (tag_id, uid, thread_id) VALUES (%d, %d, %d)', $tag_id, $user->uid, $thread);
+    }
+  }

This is a bit scary, some documentation would make it less-so. :) Also, what's that drupal_set_message(sprintf( [...] )); statement doing there, is that a bit of debug left over?

Without running the code, I can roughly tell that the user selects a bunch of messages using the checkboxes, then adds a tag using a text box. The code then iterates through each thread setting the tag. The code looks pretty sound IMO.

naheemsays’s picture

Can't see much else "wrong" - only one request - when you do reroll, can you move the privatemsg_filter_thread_tag function higher up the page, just under the privatemsg_filter_add_tag_submit function added in the same patch?

(The comment that liammcdermot needed would be on the lines of "Only add a tag for this message if the thread has not already been tagged with this tag" or better.)

also:

+    $undo = l(t('undone'), 'messages/undo/action', array('query' => drupal_get_destination()));
+    
+    drupal_set_message(t('The previous action can be !undo.', array('!undo' => $undo)));

That is from before, but I doubt it is really translateable, so you may want to change it to something that can be (maybe only have the link set as an outside parameter and have "undone." ?)

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new6.93 KB

Re-rolled.

Fixed all things pointed out in the review, I think.

naheemsays’s picture

Status: Needs review » Reviewed & tested by the community

ok, tested and this and it does what it says on the tin.

One thing to note though - this patch does NOT contain any way to mass remove tags from existing threads - that has to be done the old fashioned per thread way as before.

However since that functionality is also complicated, I think it should be in a separate patch. where different approaches can be discussed/debated properly.

So setting this to rtbc.

litwol’s picture

Nbz mind starting a new thread to initiate effort regarding your last comment?

litwol’s picture

Status: Reviewed & tested by the community » Needs work

Side note of reviewing this:

Inbox/message listing UI does not have any kind of indication which tag a message has. Perpahs we could use gmail's method (yet again) with little X that removes tag, but that works only for JS enabled browsers. Remind me what is our policy on JS support and graceful degradation (i really should remember this... sorry.. possibly even add notice to project page).

The above consists of 2 points: 1) *important* show which tags thread has , 2) less important have ajaxy X thing that remove tags (on 2nd thought this is really not important).
^ Not sure this should be part of this patch. Most likely not.

Non-code patch review: So i applied it and i got a select box in message listing page where i can mass add tags to messages, and it works... What else am i supposed to see? Also i think DSM of the mass-tagg needs to say which tag was applied to those 'n' threads. For consistency sake, Do we want to offer an undo feature like we have for 'set read/unread' ?

Perhaps some one need to write a QA sheet (oooooo so official :-D managerial bs.) with points that supposed to appear with the patch. Cheers.

naheemsays’s picture

I think some of the usability stuff is already covered in another patch: #523064: Display tags in thread list - it lists all the tags that a thread has been tagged with.

Yes an undo feature and also a mentioning of which tag was used would be an improvement, but the former may also need the removing tags from a thread patch to be made ready, so I think this patch only needs the string fix as it is getting complicated and hard to follow (for me) and if we cover more stuff, it might become almost impossible to review properly.

naheemsays’s picture

StatusFileSize
new12.46 KB

updated patch to also add the tag removal options - has a bit of refactoring of existing code too. (my changes are restricted to privatemsg_filter.module)

Current bugs:

1. When saving the tags in a thread, there are too many messages.
2. It does not mention which tags have been used to tag the threads.

naheemsays’s picture

Status: Needs work » Needs review
StatusFileSize
new12.82 KB

undo actions added and the confirm message also works now as it did - still useless and it is set before the actual tag is applied, so it assumes the following actions will work correctly. I cannot see how this can be done any other way.

berdir’s picture

Status: Needs review » Needs work
+++ privatemsg_filter/privatemsg_filter.module	25 Aug 2009 18:11:51 -0000
@@ -91,6 +91,94 @@
+ * @param $tags A single tag or an array of tags.

That is missing a newline :)

+++ privatemsg_filter/privatemsg_filter.module	25 Aug 2009 18:11:51 -0000
@@ -91,6 +91,94 @@
+ * @param $threads A single thread id or an array of thread ids.
+ * @param $tag_id Id of the tag.
+ */
+function privatemsg_filter_add_tags($threads, $tag_id, $account = NULL) {

newlines again. Regarding the function name, you use "tags", but it only possible to save a single tag. Maybe rename to ".._tag" ? tags does make more sense for remove, since you can optionally remove all tags there.

Can't find anything else here, nice cleanup.

This review is powered by Dreditor.

naheemsays’s picture

Status: Needs work » Needs review
StatusFileSize
new12.79 KB

rerolled to fix those concerns.

berdir’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Needs review » Patch (to be ported)

Added to 6.x-1.x-dev. Will port to D7 later (If anyone wants to try, go for it!)

naheemsays’s picture

Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Patch (to be ported) » Needs review
StatusFileSize
new1.14 KB

quick fix where the $user was used instead of $account in a couple of places.

berdir’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Needs review » Patch (to be ported)

Fixed, back to old status.

berdir’s picture

Status: Patch (to be ported) » Fixed
StatusFileSize
new14.95 KB

Added to 7.x-1.x-dev.

Attached is the updated patch that just just has been commited.

Status: Fixed » Closed (fixed)
Issue tags: -filter, -pmsg ux

Automatically closed -- issue fixed for 2 weeks with no activity.