Make "inbox" and "sent" menu items optional in the filter Module

There is no purpose for them other than that people kept on asking for them.

inbox and sent are provided by the privatemsg_filter submodule and there may be scope to provide on and off switches for them.

People wanted a UI they were familiar with and that involved having an inbox.

Hm...

Facts:
- The rules for inbox display are actually quite simple: All threads, that contain messages that were sent to you, are displayed in your inbox.
- If a thread contains unread messages, the view will automatically "jump" to the first unread message
- What you are proposing will not work once #660092: Use tag for inbox handling is commited, because you can only tag threads, not messages.
- As nbz said, inbox/sent is fully handled by the privatemsg_filter.module, so by disabling it, you are left with a single "Messages" list. Now, you might still want to use other features provided by that module.

Possibilities:
- Generally, I'm not saying that what we have is the best possible solution but it seems to work for many/most people as you are the first complaining about ;)
- A first, easy step might be to add a setting to disable/enable inbox/sent but still be able to have the privatemsg_filter.module enabled. You are welcome to create a new issue about that and write a patch, *but* I'd suggest to base it on #660092: Use tag for inbox handling because that *will* be commited and will totally break how such a patch would look like
- You are welcome to propose ideas but don't expect that others have the time to create patches based on that. So you are invited to do that or pay others to do it ;) If not, I suspect not much will happen here...

I'm happy to discuss this, but I'm failing to see why this is a bug or even a critical one.

(Don't take my answers as rants or aggressive, I'm usually just direct and my english isn't perfect... )

I understand that, but many users won't. It's very confusing because usually you don't receive threads in your mail boxes: you receive messages. "Thread" in traditional e-mail is simulated concept: mail clients *can* guess and group by threads but they still show individual messages in mailboxes.

And you have asked these "many users" about that? ;) To be honest, I do have issues with statements like that. Users aren't always like we think they are :)

Also, imho, privatemsg inbox works pretty much *exactly* (even more so with the new "Archive" button from the linked issue) like Gmail, which does display only threads in the overview (By exactly, I mean the concept, gmail's UI is obviously far more advanced and "better" than ours). Not everyone likes gmail (I love it ;)), but I assume the developers of it have thought a lot about UX and the way it works).

Also, what you're saying about the simulated concept is true for email clients but it's not for Privatemsg. We don't need to guess, whe know which messages belong to each other. But that isn't relevant here...

Most people don't care about usability - it's a fact :)

True, but what were the reasons for the dozens of people that wanted a inbox/sent messages feature if not usability?

That depends on if you treat usability problems as bugs. I do :)

Hm.. depends on the problem, I'd say :). Generally, I think of a bug as *something* that is *broken*. I don't think that "confusing" or "Many users won't understand this" classifies as broken. And certainly not as "critically broken".

regarding #2 above, attached is an example of how gmail does this which I find to be clear and simple.

Includes:
1) logged in user
2) sender's name
3) most recent subject
4) snippet of most recent thread message body
5) date

Important to note (using the example of Mary and Joe, when Mary send's a reply to Joe):
For Mary, the 'thread' should not be moving up to the top of the inbox but should only move to the top of the list under the Sent Mail as its a reply that is sent. For Joe, the 'thread' should not be moving to the top of the list in the Sent mail, but moved to the top of the list in the Inbox folder as it is an unread message that is received.

Is this currently the way privatemsg works?

i forgot the attachment =)

Updating the title.

I think we should have a setting to disable these two but still have the rest of the filter module available.

The attached patch adds a setting which allows to enable Inbox/Sent messages. Does someone have a better suggestion for the title description of the checkbox?

#15: enable_inbox_setting.patch queued for re-testing.

Will test this...

Hey Berdir,

I tried to apply the patch in #15, but the patch failed against the latest 6.x-2.x-dev. Actually, I first tried it against 6.x-2.x-dev with the duplicate_recipient3 patch installed (that failed), then I reversed the duplicate_recipient3 patch and tried again. That failed too. Here's the error message I got:

Hunk #1 FAILED at 83.
Hunk #2 FAILED at 127.
Hunk #3 succeeded at 146 (offset 1 line).
Hunk #4 succeeded at 169 (offset 1 line).
2 out of 4 hunks FAILED -- saving rejects to file privatemsg_filter/privatemsg_filter.module.rej

--Ben

Berdir,

Also, one idea for you: I realize that the patch adds a setting which allows you to enable Inbox/Sent messages, but what about a setting to disable the "All Messages" tab? For instance, I think a common use case would be to have an Inbox and Sent Messages tabs.... but then why do you necessarily need an All Messages tab? It could be redundant in some cases because it merely repeats all the messages in Inbox and Sent Messages on one list. Just an thought...

--ben

Well, yes, that would be possible, but once you archive messages in the Inbox, "All messages" is the only way to get them back.

Here's a re-roll of the patch.

As a hint, if yo are unsure if a patch still applies or not, simply click Re-test to have it tested again.

Thanks for the hint! I see what you're saying about "All Messages" now... But question: How do you archive messages? I didn't realize you could do that...

I'll test the latest patch!

--Ben

Oh, I see the "Archive" button now... I guess I just really never noticed before.

So I guess if we were going to allow site administrators to disable the "All Messages" tab, then we would need to disable the archive button too. That brings up an interesting question: Should there really be an "Archive Messages" permission that if granted enables both the archive button and the "All Messages" tab? And for that matter, should "All Messages" be re-named "Archive"? Anyway, just some food for thought from a usability perspective...

--Ben

Berdir,

The patch in #20 worked pretty well. I was able to enable and disable the "Inbox" and "Sent Messages" lists/tabs successfully. However, I did notice a few small things:

A. The "Enable "Inbox" and "Sent messages" lists" checkbox was unchecked by default after applying the patch, but the "Inbox" and "Sent Messages" pages were still visible by default (as they should be since this is how the module currently works). Checking and un-checking the box brought about the desired functionality, but it seems like the box should be checked by default since checked is the default state.

B. I found this message to be a little confusing: "The Privatemsg filter module can add an "Inbox" and a "Sent messages" list as local tasks to the Private messages page. This setting allows to disable them." I would change this to something like:

"By default, the Privatemsg filter module adds "Inbox" and "Sent messages" tabs to the Private Messages page. By unchecking this box, you can disable these additional tabs."

C. Under "Choose the default list option" we may want the additional note: "This setting only has an effect if "Enable 'Inbox' and 'Sent messages' lists" is checked above."

Cheers,
Ben

- Renaming All messages to Archive is an interesting idea, the problem however is: It is not really an archive because it contains all messages, not just those that were archived. So it could imho be just as confusing.

Food for thought:
- What about providing inbox, sent, all, archived (maybe others, like trash but that would be a follow-up) and then provide a table to control the order, which are enabled and which is the default. Obviously, site admins could break the whole thing by not enabling anything or only sent but that's not our problem ;)
- We could also add the other tabs to that selection, like view/send (not allowed to disable them) and blocked users.
- nbz also started an issue about moving the inbox/sent/tag handling back into privatemsg.module to avoid all that hook_menu_alter() stuff. privatemsg_filter could for example just provide the UI, only the filtering or be removed alltogether.

A: That is strange, it should be enabled by default and according to the code, it is. It also was for me when testing.

B: Will change that when I re-roll

C: See above, what about making the whole thing more flexible?

Berdir,

I love your idea about making all of the tabs/lists much more flexible and sortable. Very cool. I think Private Message has evolved into multiple potential use cases (individual messages, bulk admin messages, tokenized messages, etc.) so this would help us provide options that site administrators could use as needed. So it would be great to be able to enable/disable as needed. Any complications between D6 and D7 versions of this? We should try to pick a way to do this in D6 that is similar to how we would do it in D7 (since D7 is the release of the future).

And yes, I like the idea of adding the other tabs (Write New Message, Blocked Users, etc.) to the admin re-ordering page. It would be kind of like the Field API's "Manage Fields" page in D7, right?

As for moving inbox/sent/tag handling back into privatemsg.module, I'd be for anything that can help improve performance and scalability. Would that have any performance benefit? I do view the custom tags and the filtering as something very different than the default inbox/sent/all lists.

Finally, in regard to A, it's possible that since I had problems applying the old patch (and it sort of half applied and had to be reversed) that it created that issue. I think after trying to apply it I saw the checkbox and may have clicked. So it's probably not worth worrying about since we're making the whole thing more flexible anyway. I'll just be sure to test the defaults again on the next version of the patch.

Cheers,
Ben

#15: enable_inbox_setting.patch queued for re-testing.

Just bumping this so I don't lost track of it...

This issue is being closed because it is against a branch for a version of Drupal that is no longer supported.
If you feel that this issue is still valid, feel free to re-open and update it (and any possible patch) to work with the 7.x-1.x branch (bug fixes only) or the 7.x-2.x branch.
Thank you.