Non-core contributed modules

Anthony, this is a Plugin. View discussion: http://moodle.org/mod/forum/discuss.php?d=65462

Toni - I skimmed the discussion and would be happy to help get your code into CVS. Can I ask you to upload either a zip version of the file here so that I can evaluate it? Also, let me know for which version of Moodle the code that you upload is intended for. Once I have the code you want me to look at I will work on installing it and doing some simple testing. I will then evaulate where best to put the code in CONTRIB and then we can work on getting you the appropriate access for the CVS server. Peace - Anthony

Anthony,

I'm hoping that Martin does me write access in contrib module. when I approve commit the eMail code.

Toni - Please read and follow the instructions at: http://docs.moodle.org/en/Development:Guidelines_for_contributed_code. As Moodle's CONTRIB CoordinatorI have seen your request for CVS access; however, before I approve it I like to look at the code and test it. That allows me to determine the best place to put the code in CVS, make any suggestions, etc. Please upload the code here so that we can proceed. Thanks - Anthony

Anthony, this eMail version is for Moodle 1.9.

eMail is a tool of private communication between members of the same site of Moodle, particularly among members of the same course. eMail offers the advantage that only depends on the Moodle for its own operation, leaving behind all the problems leading to a mail service separate from installing Moodle, for example, spam problems.

The characteristics are:

• Send mail, with copies or BCC.
• Add attachments.
• Searching for:

• Folders.
• Courses.
• Users.
• Type of message (to, cc or bcc).
• For sent mails.
• For received mails.

• Management subfolders (Inbox, Sendbox and bin).
• Draft folder.
• Listings of my courses, to provide better access to them.
• Block post pending read.
• Sort and paging mails.
• Overview of all mails from all courses.(General view).
• Send mail (in personal mail xxxx@xxxx.com) staff from the new mail received from him.
• Ability to associate personal folders courses.
• Preferences.
• eMail can be configured through the configuration of the block (email_list)

How to install

• Download eMail (attach this).
• Unpack the archive using: tar -xzvf eMail-VERSION.tar.gz. You will now be left with a directory called "eMail", containing 3 folders ("email", "email_list" and "lang").
• cd email/ and copy:

• "email" into your moodle folder. For example, if your moodle folder called "moodle", copy "email" in there. You can use: cp email/ path_to_moodle/
• "email_list" into blocks folder, using: cp email/blocks/email_list path_to_moodle/blocks/
• "lang" contain language translations. Copy corresponding files into your package languages. For exemple: cp lang/en_utf8/* path_to_moodle/lang/en_utf8/ or cp lang/es_utf8/* path_to_moodle_DATA/lang/es_utf8/

• Go to your Moodle, login in which admin, and click in Notifications (admin block).

• Add email_list block.
• Enter to eMail, and send, create folder or define your preferences.

• If you can login which admin, you can go to email_list settings, and define general settings for use it.

If you have any problem, please said me.

Thanks,
Toni

Toni - I am starting to look at this now. I started by looking at the INSTALL file. One thought I had about the language files was that if you wished you could add the extralocation to your get_string calls which would then prevent users from having to move the language files. It is just a matter of convenience but I think ultimately it makes your code more modular as you could legitimately have it in one folder under root. The get_string function is defined as:

function get_string($identifier, $module='', $a=NULL, $extralocations=NULL) {

Alternatively, you could put the lang files in the block if they are really only used by the block. Your code is an example of what I have been referring to as a package since it does not fall into the typical categories. It is a plugin but it is more than a simple block because of the code outside the block folder. Technically it should be broken up in CVS (as it is) but I want to see if there is a way of keeping it together.

I ran into a similar issue when I was working with the MRBS block. Ultimately, I opted to make put the MRBS code which was initially under wwwroot as a subdirectory of the block. I'm not sure if that would work for you. Then you would have the structure of:

/block/email_list
/block/email_list/db
/block/email_list/email
/block/email_list/lang

I'm interested in any thoughts you might have about this. Before we add it to CVS I want to make sure we have the paths nailed down as CVS is somewhat rigid in how it handles directories.

Peace - Anthony

Anthony,

The initial conception of eMail is like the calendar, then it is only for the site and the user can access by the blocks, which eMail now is only one, to access to it, but in the future may be more.

Lang folder contain two translation files (email_block and email), that can be moved to their respective folders (email/lang and blocks/email_list/lang). Then eMail would have the structure of:

/block/email_list
/block/email_list/db
/block/email_list/lang

/email
/email/lang

Block email_list don't need DB structure, but I was the only place where it could preceed to intall the plugin. Really the db folder should be within in the email folder.

The "problem" who I see is that moving email folder inside the email_list block folder is that it takes away the sense of having a single internal mail system.

Toni

Toni - From what you describe, I do not see a downside to moving the email folder underneath the block. You can still define the block not to have multiple instances. In other words, its context would remain that of the front page. Each teacher would have the option of adding the email_list block to their course but it would essentially point back to that main one. I'm open to arguments (for lack of a better word) to the contrary, but it seems that having everything under that block directory is the way to go. Can you think of any functional downsides? Would you be willing to test moving it and see if we can get the desired behavior with it there? Let me know if you need any help. I'd at least like to experiment and see how that might work (or not) for you. Please know I'm just trying to be helpful and thinking long term what will be easier to maintain and what is the most Moodle-like way of handling this and it really strikes me as having a great deal in common with the MRBS block that I initially put outside the block and then discovered it worked just as well inside it. Functionally I don't think you will notice a difference but it will make it easier for folks to install and for us to maintain on CVS. Feel free to give it some thought, play around, and let me know if you come across any obstacles. Peace - Anthony

Hi Anthony,

I'm working in your suggestions, but I will take a few days (Now, I'm bundled with something else).

At the level of functionality there is no problem (pass into block folder – is very easy --). Although, really, I can not imagine a block of the blog, calendar or grade (there is general services) ... because there is not problem

Rgs for your suggestions,
Toni

Toni - I agree that ideally there should not be a problem with just having the email folder in wwwroot; however, there are some things about blocks and modules that take place automatically - like lang, db files, and cron that might necessitate making your code a patch rather than a plugin so I am trying to set things up from the beginning so that we can avoid any troubles with the integration. The gradebook code is obviously an entirely separate project; however, I would argue that calendar itself is a block and that that code could be moved. I'll bring this up with the core developers and see what they think. Peace - Anthony

p.s. - Thanks for your work incorporating some of my suggestions. Please use the ones that you see as helpful and ignore the others.

Hi Anthony,

This version includes your suggestions.

Rgs,
Toni

Toni - I have installed the RC version. I have debugging set to show all errors and I did receive a PHP Notice:

Notice: Undefined property: stdClass::$id in /home/arborrow/Moodle/code/19stable/blocks/email_list/email/lib.php on line 2376

when I created a block on the front page.

Further information found includes:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND s.readed = 0' at line 7

SELECT count FROM mdl_email_mail m LEFT JOIN mdl_email_send s ON m.id = s.mailid LEFT JOIN mdl_email_foldermail fm ON m.id = fm.mailid WHERE s.userid = 2 AND s.course = 7 AND fm.folderid = AND s.readed = 0

• line 686 of lib/dmllib.php: call to debugging()
• line 379 of lib/dmllib.php: call to get_recordset_sql()
• line 2379 of blocks/email_list/email/lib.php: call to count_records_sql()
• line 78 of blocks/email_list/block_email_list.php: call to email_get_number_unreaded()
• line 814 of blocks/moodleblock.class.php: call to block_email_list->get_content()
• line 822 of blocks/moodleblock.class.php: call to block_list->is_empty()
• line 338 of lib/blocklib.php: call to block_list->_print_block()
• line 267 of index.php: call to blocks_print_group()

Looks like the value for the fm.folderid = part did not get passed into the sql statement.

You may want to do something like:

if (!empty($folder->id)) { $wheresql = " WHERE s.userid = $userid AND s.course = $courseid AND fm.folderid = $folder->id AND s.readed = 0"; } else { $wheresql = " WHERE s.userid = $userid AND s.course = $courseid AND s.readed = 0"; }

just to make sure that you do not get an error when there is no $folder->id.

When I tried to create a new email (after adding the check above) I received:

Notice: Trying to get property of non-object in /home/arborrow/Moodle/code/19stable/blocks/email_list/email/mail_edit_form.php on line 61

Again, I would replace that with:

if (!empty($oldmail->id)) { $mform->addElement('hidden', 'id', $oldmail->id); }

In general I would encourage you to do a little more checking and testing with debugging mode on to help avoid these types of notices. I'll go ahead and upload the code. Some of these will serve as nice simple corrections to test your CVS access. Let me know if you have any questions and thanks for your willingness to share you time, talent, and code with the Moodle community.

Peace - Anthony

I also moved the INSTALL and DEVELOPERS files inside the email_list folder for complete modularity. Peace - Anthony

To avoid any confusion, I added the txt extension to the INSTALL and DEVELOPERS files.

Toni - I have bumped your privileges in the tracker so that you can manage the issues related to the email_list block. I created a component in the CONTRIB section of the tracker where users can file suggestions, bug reports, etc. I have also approved your CVS request so you should now have write access to contrib/plugins/blocks/email_list. Let me know if you have any questions or need anything else. Peace - Anthony

I'm resolving this now that it is in CVS. Let me know what you need in terms of handling the different branches.

Thanks Anthony,

Everything is correctly. I'm reporting to me any bugs.

Rgs,
Toni

Toni - Yep, I saw your latest commits so it looks like all is well. Thanks for deleting those .cvsignore files. I meant to and then forgot before committing. Don't hesitate to let me know if there is anything I can do to be of help. Peace - Anthony

FYI - There was a typo on the commit comment that incorrectly links the initial commit of the email_list files to CVS so that they are linked to CONTRIB-538 instead of CONTRIB-568. My apologies for any inconvenience. Peace - Anthony

Closing all of my resolved issues. Peace - Anthony