We need to add actions there to:
1. Add tag to selected threads.
2. Remove tag from selected threads
3. Create and add tag.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | privatemsg_filter_tags_admin3_d7.patch | 14.95 KB | berdir |
| #20 | privatemsg_filter.patch | 1.14 KB | naheemsays |
| #18 | privatemsg_filter_actions6.patch | 12.79 KB | naheemsays |
| #16 | privatemsg_filter_actions5.patch | 12.82 KB | naheemsays |
| #15 | privatemsg_filter_actions4.patch | 12.46 KB | naheemsays |
Comments
Comment #1
berdirMy early thread patches contained actions for the first two points. Not sure how to handle the third...
I will create a first patch...
Comment #2
naheemsays commentedilo 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?
Comment #3
berdirI 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.
Comment #4
naheemsays commentedThe 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.
Comment #5
naheemsays commentedtagging
Comment #6
berdirA 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 :)
Comment #7
liam mcdermott commentedAnd 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 callbackNo full stop! :)
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. :-!
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.
Comment #8
naheemsays commentedCan'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:
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." ?)
Comment #9
berdirRe-rolled.
Fixed all things pointed out in the review, I think.
Comment #10
naheemsays commentedok, 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.
Comment #11
litwol commentedNbz mind starting a new thread to initiate effort regarding your last comment?
Comment #12
naheemsays commenteddone: #534036: Add ability to mass remove tags via message listing actions.
Comment #13
litwol commentedSide 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.
Comment #14
naheemsays commentedI 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.
Comment #15
naheemsays commentedupdated 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.
Comment #16
naheemsays commentedundo 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.
Comment #17
berdirThat is missing a newline :)
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.
Comment #18
naheemsays commentedrerolled to fix those concerns.
Comment #19
berdirAdded to 6.x-1.x-dev. Will port to D7 later (If anyone wants to try, go for it!)
Comment #20
naheemsays commentedquick fix where the $user was used instead of $account in a couple of places.
Comment #21
berdirFixed, back to old status.
Comment #22
berdirAdded to 7.x-1.x-dev.
Attached is the updated patch that just just has been commited.