Option to disable reading commands from the e-mail body

You're right, there's no way to do this at the moment. I've been trying to think of a good way to improve the configuration of commands w.r.t. permissions and defaults. Here's the best idea I have so far- on the parser configuration page, a table that looks like...

Command  | Anon. Default | Auth. Default | Override in body
---------------------------------------------------------
[status] | [0]           | [1]           | [ ] anon [x] auth [ ] admin
[sticky] | [1]           | [1]           | [x] anon [x] auth [x] admin
...

It's not perfect, but I think it would be a good compromise that handles most people's needs. On the one hand you might say it's not complex enough, since it doesn't allow differentiating beyond just anon/auth users for default values. On the other hand, it could also be made simpler by getting rid of these separate defaults altogether; the only time I can imagine people using this is as shown - to unpublish unauthorized posts. So I'm wondering if we should just have one default, and move the option to unpublish unauthorized posts elsewhere... Additionally instead of having separate permissions for every command, there could just be one permission (as in hook_perm() ) for 'override mailhandler commands'.

Right now, I am actually leaning towards making it simpler- that would mean removing the separate default commands currently available for anon/auth users, adding a checkbox somewhere to unpublish unauthorized posts, and adding a permission to allow roles to override commands by putting them in the body (enabled by default). Would that work for you?

Yes, there would just be a single 'default commands' option that would apply to all users.

Hey penguin25- sorry for the delayed response, I've just been working on a lot of other issues.

I've been thinking about this a lot more and I've come to a conclusion. I don't want to make this module any more complicated than it already is, and I'm afraid that slathering on another layer of permissions might do just that. The way I see it, Mailhandler is just an alternative to using the web-based node creation form. Thus, if a module allows you to set default parameters per-role, or restricts certain roles from changing default parameters (i.e. the permissions system), then it should apply to both web-created content and email-created content.

Thus, the Feeds Node Processor should be responsible for applying these defaults and restrictions, not Mailhandler.

I would appreciate hearing your use case so we can brainstorm how this might actually work for you, and what modifications to Feeds might be necessary.

I hope you understand, and I welcome any better ideas, as long as they don't unduly increase the complexity of the module.

(changed the version to 7.x-2.x, as any new features will be developed there first)

I am glad to see you recently set this to active.

Here is my use case:

My Q+A site allows people to email us questions and replies to our answers. Sometimes the user sends a message where one or more of the lines matches the regexp in MailhandlerCommandsDefault.class.php's getCommands. No "available commands" are set in my importer.

But getCommands doesn't just return the commands in the message, it strips them from the body.

If MailhandlerCommandsDefault.class.php could use getCommands to only get commands instead of to get commands and strip potential commands from the body text, my use case would be satisfied.

Alternatively, offer a raw body field to the importer mappings.

Thanks for considering!

Seems like providing a raw body field is the easiest solution?

I think the best way forward is to add a global permission 'override default commands', and enable it by default for authenticated users. I know some people might like more granular permissions, but I'm hoping this strikes the right balance between complexity and flexibility.

I also changed this to a major bug, because I think it's not clear enough that anonymous users can currently override default commands (such as publishing their own nodes) if they just know the correct command.

The patch above seems to be for 6.x and unfortunately the issue still persists in 7.x. I wonder is there any temporary solution to suppress custom commands from displaying in node body?