[GH-ISSUE #398] Configurable custom actions (buttons) #330

Open
opened 2026-02-25 21:34:46 +03:00 by kerem · 7 comments
Owner

Originally created by @marclaporte on GitHub (May 6, 2020).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/398

Cypht has standard actions (delete, archive, etc.). Let's take this up a notch.

I do the same actions again and again. It would be nice to configure these actions. A bit like macros.

Part of the logic for filters: https://github.com/jasonmunro/cypht/issues/9 but manual trigger of actions.

Ex.:

  • move email to a folder XYZ in another account
  • forward to ABC and delete
  • forward to DEF and archive

Thanks!

Originally created by @marclaporte on GitHub (May 6, 2020). Original GitHub issue: https://github.com/cypht-org/cypht/issues/398 Cypht has standard actions (delete, archive, etc.). Let's take this up a notch. I do the same actions again and again. It would be nice to configure these actions. A bit like macros. Part of the logic for filters: https://github.com/jasonmunro/cypht/issues/9 but manual trigger of actions. Ex.: * move email to a folder XYZ in another account * forward to ABC and delete * forward to DEF and archive Thanks!
Author
Owner

@dumblob commented on GitHub (May 6, 2020):

@marclaporte you mean something like a button run now next to each filter chain?

<!-- gh-comment-id:624508649 --> @dumblob commented on GitHub (May 6, 2020): @marclaporte you mean something like a button **run now** next to each filter chain?
Author
Owner

@marclaporte commented on GitHub (May 14, 2020):

@dumblob: yes, that as well. Any set of actions really.

<!-- gh-comment-id:628314006 --> @marclaporte commented on GitHub (May 14, 2020): @dumblob: yes, that as well. Any set of actions really.
Author
Owner

@dumblob commented on GitHub (May 14, 2020):

@marclaporte hm, I mean, having a button run now next to each filter is very easy to implement, but if there are any other actions (which? I think there do not exist any other meaningful actions except for sending emails), it'd get more complicated to implement.

<!-- gh-comment-id:628472084 --> @dumblob commented on GitHub (May 14, 2020): @marclaporte hm, I mean, having a button **run now** next to each filter is very easy to implement, but if there are any other actions (which? I think there do not exist any other meaningful actions except for [sending emails](https://github.com/jasonmunro/cypht/issues/115 )), it'd get more complicated to implement.
Author
Owner

@marclaporte commented on GitHub (May 14, 2020):

Maybe I am misunderstanding. Can you elaborate on "filter chain"?

"which?": This is a long term goal: Parse emails for structured data and move to a database (http://doc.tiki.org/Trackers). Imagine invoices by email that are added to the accounting system.

I would like a button to bounce an email back to sender, simulating a non existant account.

Some more ideas here:
http://james.apache.org/mailet/standard/mailet-report.html

For the short term, I want buttons like "move to accounting inbox", "move to accounting archive"

<!-- gh-comment-id:628941325 --> @marclaporte commented on GitHub (May 14, 2020): Maybe I am misunderstanding. Can you elaborate on "filter chain"? "which?": This is a long term goal: Parse emails for structured data and move to a database (http://doc.tiki.org/Trackers). Imagine invoices by email that are added to the accounting system. I would like a button to bounce an email back to sender, simulating a non existant account. Some more ideas here: http://james.apache.org/mailet/standard/mailet-report.html For the short term, I want buttons like "move to accounting inbox", "move to accounting archive"
Author
Owner

@marclaporte commented on GitHub (May 14, 2020):

Also, one of our goals is to support the use case of generic mailboxes like info@, support@, accountspayable@, etc. Please see: http://doc.tiki.org/Groupmail

Actions could be:

  • Add a threaded discussion about this email to coordinate on how to handle/reply.
  • Convert to a task

I realize a lot of this will go beyond the use case of standalone Cypht. Configurable buttons could have 10 possible actions in standalone and 20 when embedded within an app like Tiki. And sooner or later, other web apps will follow our footsteps for JMAP and programmable emails!

<!-- gh-comment-id:628945686 --> @marclaporte commented on GitHub (May 14, 2020): Also, one of our goals is to support the use case of generic mailboxes like info@, support@, accountspayable@, etc. Please see: http://doc.tiki.org/Groupmail Actions could be: * Add a threaded discussion about this email to coordinate on how to handle/reply. * Convert to a task I realize a lot of this will go beyond the use case of standalone Cypht. Configurable buttons could have 10 possible actions in standalone and 20 when embedded within an app like Tiki. And sooner or later, other web apps will follow our footsteps for JMAP and programmable emails!
Author
Owner

@dumblob commented on GitHub (May 15, 2020):

@marclaporte now I see what you mean. IMHO that has not much to do with Cypht, but rather with modules which Cypht already supports. Cypht itself has no need for such actions - they don't exist now, so there is no need for any buttons/... (i.e. no user interface).

But of course, you're free to write your own extension modules for Cypht and you'll get your buttons in the UI as well.

I doubt there is anything important to do in this front - Cypht is already quite extensible, so a generic support for "custom actions" is already baked in. You just need to get it moving by writing your very own modules (as the actions you mentioned are extremely specific and such module is IMHO not suited for inclusion in this repository).

Btw. "filter chains" is the "expected" outcome of https://github.com/jasonmunro/cypht/issues/9#issuecomment-623271697 - and my proposal here was to add one more button to trigger them manually in addition to triggering them automatically as soon as the user logs in and Cypht starts fetching new emails.

<!-- gh-comment-id:629297289 --> @dumblob commented on GitHub (May 15, 2020): @marclaporte now I see what you mean. IMHO that has not much to do with Cypht, but rather with modules which Cypht already supports. Cypht itself has no need for such actions - they don't exist now, so there is no need for any buttons/... (i.e. no user interface). But of course, you're free to write your own extension modules for Cypht and you'll get your buttons in the UI as well. I doubt there is anything important to do in this front - Cypht is already quite extensible, so a generic support for "custom actions" is already baked in. You just need to get it moving by writing your very own modules (as the actions you mentioned are extremely specific and such module is IMHO not suited for inclusion in this repository). Btw. "filter chains" is the "expected" outcome of https://github.com/jasonmunro/cypht/issues/9#issuecomment-623271697 - and my proposal here was to add one more button to trigger them manually in addition to triggering them automatically as soon as the user logs in and Cypht starts fetching new emails.
Author
Owner

@marclaporte commented on GitHub (Sep 15, 2025):

Cypht is already quite extensible, so a generic support for "custom actions" is already baked in. You just need to get it moving by writing your very own modules (as the actions you mentioned are extremely specific and such module is IMHO not suited for inclusion in this repository).

I don't want to write and maintain custom code. I want to be able to add and modify these custom actions as I do for filters.

In all mail clients with filters, there are at least two parts:

  • filtering messages (ex.: email from ABC)
  • the actions (ex.: move to folder XYZ)

So here we would add a new option for filtering (add as a "custom action")

  • name of custom action (what goes on the button)
  • description (Some notes so I can add more context)
  • maybe others (ex.: order of button)

And this would add custom action buttons in the interface, usable on one email or many (select some emails via checkboxes and the custom action buttons appear like for the "move" and "copy" actions).

Benefits:

  • Nothing is added to the UI unless user wants a custom action
  • Custom actions reuse existing interface and code
  • End users gain flexibility, even without coding

Btw. "filter chains" is the "expected" outcome of #9 (comment) - and my proposal here was to add one more button to trigger them manually in addition to triggering them automatically as soon as the user logs in and Cypht starts fetching new emails.

  • FYI, if Sieve is available, the filter chain will run on the server and user doesn't even need to log in. We created https://github.com/cypht-org/php-sieve-manager for this.
  • Since Sieve is not available on some mail servers, for Cypht in Tiki, we added a way to put filters on a cron job: https://doc.tiki.org/Email-filters
  • About a way to trigger manually existing filters. Something like "run now": Sounds like a good idea. I would push the idea even further: a dry run (Tell me what would happen if I ran this filter)
<!-- gh-comment-id:3290376093 --> @marclaporte commented on GitHub (Sep 15, 2025): > Cypht is already quite extensible, so a generic support for "custom actions" is already baked in. You just need to get it moving by writing your very own modules (as the actions you mentioned are extremely specific and such module is IMHO not suited for inclusion in this repository). I don't want to write and maintain custom code. I want to be able to add and modify these custom actions as I do for filters. In all mail clients with filters, there are at least two parts: - filtering messages (ex.: email from ABC) - the actions (ex.: move to folder XYZ) So here we would add a new option for filtering (add as a "custom action") - name of custom action (what goes on the button) - description (Some notes so I can add more context) - maybe others (ex.: order of button) And this would add custom action buttons in the interface, usable on one email or many (select some emails via checkboxes and the custom action buttons appear like for the "move" and "copy" actions). Benefits: - Nothing is added to the UI unless user wants a custom action - Custom actions reuse existing interface and code - End users gain flexibility, even without coding > Btw. "filter chains" is the "expected" outcome of [#9 (comment)](https://github.com/cypht-org/cypht/issues/9#issuecomment-623271697) - and my proposal here was to add one more button to trigger them manually in addition to triggering them automatically as soon as the user logs in and Cypht starts fetching new emails. - FYI, if Sieve is available, the filter chain will run on the server and user doesn't even need to log in. We created https://github.com/cypht-org/php-sieve-manager for this. - Since Sieve is not available on some mail servers, for Cypht in Tiki, we added a way to put filters on a cron job: https://doc.tiki.org/Email-filters - About a way to trigger manually existing filters. Something like "run now": Sounds like a good idea. I would push the idea even further: a dry run (Tell me what would happen if I ran this filter)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cypht#330
No description provided.