Skip to content
Snippets Groups Projects
  1. Apr 07, 2005
  2. Mar 22, 2005
  3. Mar 21, 2005
  4. Mar 20, 2005
  5. Mar 10, 2005
  6. Mar 06, 2005
  7. Feb 14, 2005
  8. Feb 08, 2005
    • mjollnir_'s avatar
      First cut of email to module (or core) processing. · bb64b51a
      mjollnir_ authored
      This patch contains:
      
      * email_to_user will set the envelope sender to a special bounce processing address (based on $CFG settings)
      * email_to_user will accept (and set) a reply-to header, to be generated by the module calling the function.
      
      * new functions:
      
      	* generate_email_processing_address - ALWAYS use this to generate the reply-to header. reply-to header will look like this:
      
      	(LIMIT: 64 chars total)
      	prefix - EXACTLY four chars
      	encodeded, packed, moduleid (0 for core) (2 chars)
      	up to 42 chars for the modules to put anything they want it (can contain userid (or, eg for forum, postids to reply to), or anything really. 42 chars is ABSOLUTE LIMIT)
      	16 char hash (half an md5) of the first part of the address, together with a site "secret"
      
      	* moodle_process_email - any non-module email processing goes here (currently used for processing bounces)
      
      * bounce handling:
      
      	* config settings for bounce threshold and ratio (and whether to handle bounces at all)
      	* if too many bounces occur against any given user, user_not_fully_set_up will force an email address change
      	* associated functions (over_bounce_threshold, set_send_count, set_bounce_count)
      
      * handling emails to noreply address (see below)
      
      * new script - admin/process_email.php
      
      	This script needs to be called from your mail program for anything starting with the 4 char prefix described above (and optionally, the noreply address)
      	It will bounce emails to the noreplyaddress, with a friendly "this is not a real email address" message
      
      	It will break down and unencode the email address into moduleid and validate the half md5 hash, and call $modname_process_email (if it exists). Arguments to these functions are: $modargs (any part of the email address that isn't the prefix, modid or the hash) and the contents of the email (read from STDIN).
      
      * associated string changes/additions
      
      * changes in config-dist.php to give clues as to how to set this up.
      
      MODULE WRITERS!
      
      take a look at new functions moodle_process_email and generate_email_processing_address  in moodlelib.php for ideas about how to
      
      	* encode and unencode the arguments your module needs to do the processing
      	* how to deal with multiple "actions" for any given module.
      
      Martin Langhoff <martin@catalyst.net.nz> will be writing up some PROPER documentation, containing amongst other things config settings for different mail servers (this was developed against Postfix).  Feel free to email me with any feedback on the code or design, penny@catalyst.net.nz.  Or post on the developer fourm.
      bb64b51a
  9. Dec 26, 2004
  10. Sep 27, 2004
  11. Sep 06, 2004
  12. Sep 04, 2004
  13. Aug 31, 2004
  14. Aug 23, 2004
  15. Aug 21, 2004
  16. Jun 20, 2004
  17. May 24, 2004
  18. May 15, 2004
  19. May 03, 2004
  20. Apr 27, 2004
  21. Mar 12, 2004
  22. Mar 10, 2004
  23. Feb 18, 2004
  24. Feb 17, 2004
  25. Feb 10, 2004
  26. Feb 09, 2004
    • moodler's avatar
      TEXT CACHING · d363047e
      moodler authored
      ------------
      
      I have a site which really needs this, so I went ahead with it already.
      
      This add-on will cache formatted texts in the database and use them
      for a specified timeperiod.
      
      By default it is disabled.   Enable it with:
      
        $CFG->cachetext = 600;   // in seconds
      d363047e
  27. Feb 08, 2004
  28. Jan 30, 2004
  29. Jan 27, 2004
  30. Jan 26, 2004
  31. Dec 07, 2003
  32. Nov 04, 2003
  33. Oct 29, 2003
  34. Oct 13, 2003
    • moodler's avatar
      NEW EXPERIMENTAL FEATURE: text filters. · e67b9e31
      moodler authored
      This new feature allows arbitrary text filters to be added to
      any HTML that is printed (forum posts, resources etc) ... anything
      that uses the standard format_text function.
      
      The first one properly supported is the glossary dynamic linking
      feature.
      e67b9e31
  35. Sep 15, 2003
Loading