[Mahara-contributors] [Bug 1720883] Re: Add disclaimer to reports regarding earliest recorded data
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1720883 Title: Add disclaimer to reports regarding earliest recorded data Status in Mahara: Fix Committed Bug description: This will be useful for reports using event_log data as admins could clean out old results to save space and or switch it on/off via config settings To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1720883/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1693062] Re: Placement of message when secret URLs are turned off needs correcting
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1693062 Title: Placement of message when secret URLs are turned off needs correcting Status in Mahara: Fix Committed Bug description: Steps to reproduce: 1) Turn off aloowing public pages be navigating to site options>General settings>Allow public pages to NO and save it. 2)Navigate to pages & collections> select a page> click on edit this page> share Result : You have to see this error message " Your institution or site administrator has disabled public pages and secret URLs. Any secret URLs you see listed here are currently inactive." The alignment of the above message is improper ( see attachemnet ) To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1693062/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1681284] Re: SmartEvidence matrix page - need the ability to expand / collapse the sections of the matrix
Patch: https://reviews.mahara.org/#/c/7602/ -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1681284 Title: SmartEvidence matrix page - need the ability to expand / collapse the sections of the matrix Status in Mahara: In Progress Bug description: With the creation of matrices there are 'sections' the lines in grey in attached image and there are 'examples', which are subsections of the 'sections'. If the framework matrix is quite long it would be useful to be able to expand/collapse the 'sections', i.e. show/hide the 'examples' rows of a section. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1681284/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1681282] Re: warning message when using japanese language pack
Hi all, Mahara language strings are actually sprintf() format strings. That's why the placeholder is "%s". Thus if you want to print a literal "%" character, you have to sprintf-escape it by doing two of them: "%%". So the fix here is to update the Japanese language pack so that this language-string has a %% instead of a %. Cronが動作していません。cronのセットアップに関するインストラクションはhttps://wiki.mahara.org/wiki/System_Administrator%%27s_Guide/Installing_Mahara;>installation guideをご覧ください。あなたがすでにcronをセットアップしている場合、直近の1つまたはそれ以上の処理が正しく実行されませんでした。 ... or in this case, you could alternately update the Japanese language pack to replace the "%27" with a an apostrophe "'". That's what we did in the English language pack, as a less-brittle fix for this particular string. I'll update the wiki page about lang strings ( https://wiki.mahara.org/wiki/Developer_Area/Language_strings#Plural_strings ). Currently it mentions sprintf(), but it doesn't explicitly say that lang strings are sprintf() format strings, or that you have to escape literal % characters. Cheers, Aaron -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1681282 Title: warning message when using japanese language pack Status in Mahara: In Progress Status in Mahara 17.10 series: Confirmed Bug description: Install japanese language pack go to admin/index.php refresh the page you will see a warning message: [WAR] b4 (lib/mahara.php:1470) sprintf(): Too few arguments This is happening because the function sprintf has a string parameter containing a '%' symbol that makes the function expect an extra string, but the symbol is in fact part of an URL. parameter string: Cronが動作していません。cronのセットアップに関するインストラクションはhttps://wiki.mahara.org/wiki/System_Administrator%27s_Guide/Installing_Mahara;>installation guideをご覧ください。あなたがすでにcronをセットアップしている場合、直近の1つまたはそれ以上の処理が正しく実行されませんでした。 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1681282/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1681282] Re: warning message when using japanese language pack
Oh yeah, here's the PHP documentation page about sprintf(). The "%%" part is obscurely explained there as: Each conversion specification consists of a percent sign (%), followed by one or more of these elements, in order: ... 6. A type specifier that says what type the argument data should be treated as. Possible types: % - a literal percent character. No argument is required. They do make it a bit clearer in one of the examples where there's a code comment that says "// notice the double %%, this prints a literal '%' character". -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1681282 Title: warning message when using japanese language pack Status in Mahara: In Progress Status in Mahara 17.10 series: Confirmed Bug description: Install japanese language pack go to admin/index.php refresh the page you will see a warning message: [WAR] b4 (lib/mahara.php:1470) sprintf(): Too few arguments This is happening because the function sprintf has a string parameter containing a '%' symbol that makes the function expect an extra string, but the symbol is in fact part of an URL. parameter string: Cronが動作していません。cronのセットアップに関するインストラクションはhttps://wiki.mahara.org/wiki/System_Administrator%27s_Guide/Installing_Mahara;>installation guideをご覧ください。あなたがすでにcronをセットアップしている場合、直近の1つまたはそれ以上の処理が正しく実行されませんでした。 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1681282/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1677063] Re: PHP7 deprecated constructor for xmldb
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1677063 Title: PHP7 deprecated constructor for xmldb Status in Mahara: Fix Committed Bug description: On upgrade I get these errors in error.log PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; XMLDBpostgres has a deprecated constructor in /home/robertl/code/mahara- devel/mahara/htdocs/lib/xmldb/classes/generators/postgres/postgres.class.php on line 31 We need to update the lib/xmldb/ files so classes are constructed correctly eg Replace public function XMLDBpostgres($host, $queryPort) with public function __construct($host, $queryPort) To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1677063/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1486309] Re: Call stack errors on site statistics
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1486309 Title: Call stack errors on site statistics Status in Mahara: Fix Committed Bug description: When I logged in as a Site Staff user and I went to Site information>user search>site statistics and the page shows a page of errors I have attached a screen shot so you can see. Linux Post gres Firefox If you need any more info then ask Dean To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1486309/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1603206] Re: Anonymously placed comments end up with system user
** Changed in: mahara/15.10 Status: Confirmed => In Progress ** Changed in: mahara/16.04 Status: Confirmed => In Progress ** Changed in: mahara/16.10 Status: Confirmed => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1603206 Title: Anonymously placed comments end up with system user Status in Mahara: Fix Committed Status in Mahara 15.04 series: Won't Fix Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: Seen on a 15.10 site for example, but possibly also 15.04 on mahara.org Comments placed anonymously on a page send a notification to the "System User". The real person doesn't get notified and it's a way for spammers to leave comments that aren't seen. Gregor for example reported that he didn't get informed about spam comments on https://mahara.org/user/anzeljg/windowslive-blocktype (or the artefact) and thus couldn't remove them unless he was on the page and saw the comments. I don't get System User emails, but suspect that this might be a similar issue. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1603206/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1603206] Re: Anonymously placed comments end up with system user
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1603206 Title: Anonymously placed comments end up with system user Status in Mahara: Fix Committed Status in Mahara 15.04 series: Won't Fix Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: Seen on a 15.10 site for example, but possibly also 15.04 on mahara.org Comments placed anonymously on a page send a notification to the "System User". The real person doesn't get notified and it's a way for spammers to leave comments that aren't seen. Gregor for example reported that he didn't get informed about spam comments on https://mahara.org/user/anzeljg/windowslive-blocktype (or the artefact) and thus couldn't remove them unless he was on the page and saw the comments. I don't get System User emails, but suspect that this might be a similar issue. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1603206/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1582778] Re: Multibyte UTF8 characters (e.g. Japanese text) jumbled when submitted with image
** Summary changed: - Japanese text jumbled when submitted with image + Multibyte UTF8 characters (e.g. Japanese text) jumbled when submitted with image ** Tags added: i18n utf8 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1582778 Title: Multibyte UTF8 characters (e.g. Japanese text) jumbled when submitted with image Status in Mahara: Fix Released Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Released Bug description: When a Japanese user writes Japanese text in the editor and posts it, it is typically fine. However, adding an image causes any Japanese text to be jumbled (just appears as a string of ). Server Mahara version 16.04.1 Apache on Linux with Postgres Tested on Clients Windows 10 + Chrome Ubuntu 16.04 + Chromium and Firefox To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1582778/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1639635] Re: Multibyte UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing
*** This bug is a duplicate of bug 1582778 *** https://bugs.launchpad.net/bugs/1582778 ** Summary changed: - Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing + Multibyte UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1639635 Title: Multibyte UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing Status in Mahara: Fix Released Bug description: As reported on the forum: https://mahara.org/interaction/forum/topic.php?id=7723=31207 A user reported that Greek characters with accent marks (ό έ ά) get turned into question marks (? ? ?) if they're in a TinyMCE text box, and the user embeds images into that text box. It only happens when images are involved, which suggests it's a bug in the TinyMCE embedded image processor, possibly from us failing to use multibyte string functions. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1639635/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1639635] Re: Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing
*** This bug is a duplicate of bug 1582778 *** https://bugs.launchpad.net/bugs/1582778 Okay, it looks like this bug is a duplicate of Bug 1582778. It was fixed 15.10.4, 16.04.1, and 16.10.0, and can't be reproduced in any of those releases. The bug reported described their environment as: OS: Ubuntu 14.04 Apache: 2.4.7 PGSQL: 9.3.14 PHP: 5.5.52 Mahara: 15.10.1 So that explains why they are still seeing this issue. ** Changed in: mahara Milestone: 16.10.1 => None ** Changed in: mahara Status: In Progress => Fix Released ** This bug has been marked a duplicate of bug 1582778 Japanese text jumbled when submitted with image -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1639635 Title: Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing Status in Mahara: Fix Released Bug description: As reported on the forum: https://mahara.org/interaction/forum/topic.php?id=7723=31207 A user reported that Greek characters with accent marks (ό έ ά) get turned into question marks (? ? ?) if they're in a TinyMCE text box, and the user embeds images into that text box. It only happens when images are involved, which suggests it's a bug in the TinyMCE embedded image processor, possibly from us failing to use multibyte string functions. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1639635/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1639635] Re: Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing
The user shared with us a Mahara page showing the affected text. Looking at it in a hex viewer, I can see that the affected Greek letters are two-byte UTF-8 characters, in the parts where they're displaying correctly, and one-byte "?" characters where they're displaying incorrectly. So that actually suggests it may not just be something like these characters getting split by an unfortunate str_replace(), but that we've got some text processing function that is filtering them out. ά : ce ac ( http://www.mclean.net.nz/ucf/?c=U+03AC ) έ : ce ad ( http://www.mclean.net.nz/ucf/?c=U+03AD ) ό : cf 8c ( http://www.mclean.net.nz/ucf/?c=U+03CC ) ? : 3f ( http://www.mclean.net.nz/ucf/?c=U+003F ) ** Attachment added: "imagetest - ATS2020.html" https://bugs.launchpad.net/mahara/+bug/1639635/+attachment/4773657/+files/imagetest%20-%20ATS2020.html -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1639635 Title: Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing Status in Mahara: In Progress Bug description: As reported on the forum: https://mahara.org/interaction/forum/topic.php?id=7723=31207 A user reported that Greek characters with accent marks (ό έ ά) get turned into question marks (? ? ?) if they're in a TinyMCE text box, and the user embeds images into that text box. It only happens when images are involved, which suggests it's a bug in the TinyMCE embedded image processor, possibly from us failing to use multibyte string functions. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1639635/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1639635] [NEW] Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing
Public bug reported: As reported on the forum: https://mahara.org/interaction/forum/topic.php?id=7723=31207 A user reported that Greek characters with accent marks (ό έ ά) get turned into question marks (? ? ?) if they're in a TinyMCE text box, and the user embeds images into that text box. It only happens when images are involved, which suggests it's a bug in the TinyMCE embedded image processor, possibly from us failing to use multibyte string functions. ** Affects: mahara Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Tags: i18n utf8 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1639635 Title: Two-part UTF-8 characters in a TinyMCE text field, turned into question marks by embedded image processing Status in Mahara: In Progress Bug description: As reported on the forum: https://mahara.org/interaction/forum/topic.php?id=7723=31207 A user reported that Greek characters with accent marks (ό έ ά) get turned into question marks (? ? ?) if they're in a TinyMCE text box, and the user embeds images into that text box. It only happens when images are involved, which suggests it's a bug in the TinyMCE embedded image processor, possibly from us failing to use multibyte string functions. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1639635/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1635441] [NEW] Profile artefacts sometimes out of sync with "usr" table fields
Public bug reported: There are five profile fields, that are replicated into columns in the usr table, and artefacts in the artefact table. On the PHP side of things four of them use the "ArtefactTypeCachedProfileField" class: 1. firstname 2. lastname 3. preferredname 4. studentid The fifth one is the "email" field, which is a little bit different because a user can have multiple email addresses. Each of these is stored as an artefact, and their "primary" email address (the one we actually send emails to) is also replicated in the usr.email field. We also have an additional table, "artefact_internal_profile_email", which has additional data about each email address. The problem is, in existing databases some of this data is out of sync. Sometimes we find bugs that have caused this (for instance Bug 1630753 and Bug 1630764). Other times, we can't replicate the issue at all. We could resolve this issue by normalizing the data. That is, keep it in only *one* place in the database, either the usr table or the artefact table. For performance reasons, it would probably be better to "de- artefact" them, because these fields are all frequently accessed by, for instance, the display_name() function. Removing them from the "usr" table would require us to run database joins against the artefact table, which is often huge and could slow things down. In comparison, removing them as artefacts would just complicate the Elasticsearch plugin and the User Profile block a little bit. ** Affects: mahara Importance: Low Status: Confirmed ** Changed in: mahara Importance: Undecided => Low -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1635441 Title: Profile artefacts sometimes out of sync with "usr" table fields Status in Mahara: Confirmed Bug description: There are five profile fields, that are replicated into columns in the usr table, and artefacts in the artefact table. On the PHP side of things four of them use the "ArtefactTypeCachedProfileField" class: 1. firstname 2. lastname 3. preferredname 4. studentid The fifth one is the "email" field, which is a little bit different because a user can have multiple email addresses. Each of these is stored as an artefact, and their "primary" email address (the one we actually send emails to) is also replicated in the usr.email field. We also have an additional table, "artefact_internal_profile_email", which has additional data about each email address. The problem is, in existing databases some of this data is out of sync. Sometimes we find bugs that have caused this (for instance Bug 1630753 and Bug 1630764). Other times, we can't replicate the issue at all. We could resolve this issue by normalizing the data. That is, keep it in only *one* place in the database, either the usr table or the artefact table. For performance reasons, it would probably be better to "de-artefact" them, because these fields are all frequently accessed by, for instance, the display_name() function. Removing them from the "usr" table would require us to run database joins against the artefact table, which is often huge and could slow things down. In comparison, removing them as artefacts would just complicate the Elasticsearch plugin and the User Profile block a little bit. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1635441/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1529775] Re: MySql concat string needs to be used instead of ||
The main gotcha to this, is that if you're debugging a Mahara instance
that's running in MySQL, and you copy out one of the SQL queries
generated by Mahara and try to run it manually in a separate MySQL
client.
If you do that, and the query uses ||, it'll error out unless you have
first manually run
SET SQL_MODE='POSTGRESQL';
The full list of things we do when setting up a connection to a MySQL
DB, is in the "configure_dbconnection()" function in htdocs/lib/dml.php.
It's actually:
SET NAMES 'utf8';
SET SQL_MODE='POSTGRESQL';
SET CHARACTER SET utf8;
SET SQL_BIG_SELECTS=1;
And if you're using $CFG->dbtimezone, we also do
SET time_zone='{$CFG->dbtimezone}';
So if you notice discrepancies when running Mahara-generated SQL queries
in a MySQL client, one thing to try is to run all of those in the client
and see if it makes a difference.
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1529775
Title:
MySql concat string needs to be used instead of ||
Status in Mahara:
Won't Fix
Bug description:
Mahara 15.10
OS: Ubuntu 14.04
DB: Mysql 5.5
Browser: any
I've noticed that in htdocs/search/internal/lib.php, the SQL used to
concatenate strings is '||'.
For example, line 275:
$sql = $alias . '.' . $field . ' ' . db_ilike() . " '%' || ? || '%'";
Unfortunately, this doesn't always work with Mysql. In order for this to work
we would need to set PIPES_AS_CONCAT
Please refer to the documentation:
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_pipes_as_concat
Otherwise, strings need to be concatenated using: 'CONCAT'.
This function is also available in Postgres.
So, perhaps we should be using CONCAT instead of '||'.
So, the above line 275 would be:
$sql = $alias . '.' . $field . ' ' . db_ilike() . " concat('%', ? , '%')";
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1529775/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1529775] Re: MySql concat string needs to be used instead of ||
As Robert mentioned, we do "SET SQL_MODE='POSTGRESQL'" when using MySQL.
This is equivalent to the "PIPES_AS_CONCAT" directive Ghada mentioned,
as well as several other options:
Equivalent to PIPES_AS_CONCAT, ANSI_QUOTES, IGNORE_SPACE,
NO_KEY_OPTIONS, NO_TABLE_OPTIONS, NO_FIELD_OPTIONS.
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_postgresql
** Changed in: mahara
Status: Confirmed => Invalid
** Changed in: mahara
Milestone: 16.10.0 => None
** Changed in: mahara
Status: Invalid => Won't Fix
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1529775
Title:
MySql concat string needs to be used instead of ||
Status in Mahara:
Won't Fix
Bug description:
Mahara 15.10
OS: Ubuntu 14.04
DB: Mysql 5.5
Browser: any
I've noticed that in htdocs/search/internal/lib.php, the SQL used to
concatenate strings is '||'.
For example, line 275:
$sql = $alias . '.' . $field . ' ' . db_ilike() . " '%' || ? || '%'";
Unfortunately, this doesn't always work with Mysql. In order for this to work
we would need to set PIPES_AS_CONCAT
Please refer to the documentation:
http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_pipes_as_concat
Otherwise, strings need to be concatenated using: 'CONCAT'.
This function is also available in Postgres.
So, perhaps we should be using CONCAT instead of '||'.
So, the above line 275 would be:
$sql = $alias . '.' . $field . ' ' . db_ilike() . " concat('%', ? , '%')";
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1529775/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1625380] Re: Able to select a standard from Collection Edit page
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1625380 Title: Able to select a standard from Collection Edit page Status in Mahara: Fix Committed Bug description: Tested in Chrome, Firefox, Safari and IE Edge for php5 Pre req: Confirm that standard is pre selected via SE map/matrix (Collection>matrix>annotation) From standard drop down menu, pre selected is highlighted and not able to select a diff standard Test step: From Page>Edit this page>Annotation (enter Annotation) Standard drop down menu>select a standard (different from existing) Save To confirm that the change is accepted: Collection>matrix>Annotation You should not be able to update the standard once it had already been selected as the annotation wouldn't fit anymore. This is a bug. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1625380/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1629147] Re: Error message about non-existent framework url
** Changed in: mahara
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1629147
Title:
Error message about non-existent framework url
Status in Mahara:
Fix Committed
Bug description:
Mahara 16.10dev
This might be related to bug #1629144
When I want to delete a copied page from a collection that has
SmartEvidence, I get the following error message on the page deletion
page:
[WAR] 64 (lib/collection.php:950) Undefined property:
Collection::$frameworkurl
Call stack (most recent first):
log_message("Undefined property: Collection::$frameworkurl", 8, true,
true, "/home/kristina/code/1610stable/htdocs/lib/collecti...", 950) at
/home/kristina/code/1610stable/htdocs/lib/errors.php:513
error(8, "Undefined property: Collection::$frameworkurl",
"/home/kristina/code/1610stable/htdocs/lib/collecti...", 950, array(size 6)) at
/home/kristina/code/1610stable/htdocs/lib/collection.php:950
Collection->get_url() at
/home/kristina/code/1610stable/htdocs/view/delete.php:30
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1629147/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1568619] Re: Open Badge details aren't accessible with screenreader
** Also affects: mahara/17.04 Importance: Undecided Status: New ** Changed in: mahara/17.04 Status: New => Fix Committed ** Changed in: mahara/17.04 Importance: Undecided => High ** Changed in: mahara/17.04 Milestone: None => 17.04.0 ** Changed in: mahara/16.04 Status: Confirmed => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1568619 Title: Open Badge details aren't accessible with screenreader Status in Mahara: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Status in Mahara 17.04 series: Fix Committed Bug description: Mahara 16.04dev When you have an Open Badge in a page and you just use a screenreader and click on the Open Badge image, the modal with the information about the badge does not appear. I suspect the on.click Javascript is the culprit. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1568619/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1630753] Re: Webservices create user has problems with preferredname and studentid fields
** Changed in: mahara/15.04 Status: Confirmed => In Progress ** Changed in: mahara/15.10 Status: Confirmed => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1630753 Title: Webservices create user has problems with preferredname and studentid fields Status in Mahara: Fix Committed Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Bug description: This issue was fixed for 16.10+ but needs to be backported to earlier versions using webservices We need the studentid and preferredname parts of commit 4bc12f6abbc832fbcd9766518796ae4a45351034 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1630753/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1630753] Re: Webservices create user has problems with preferredname and studentid fields
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1630753 Title: Webservices create user has problems with preferredname and studentid fields Status in Mahara: Fix Committed Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Bug description: This issue was fixed for 16.10+ but needs to be backported to earlier versions using webservices We need the studentid and preferredname parts of commit 4bc12f6abbc832fbcd9766518796ae4a45351034 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1630753/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1630764] Re: Webservices update user has problems with preferredname and studentid fields
** Changed in: mahara/15.04 Status: Confirmed => In Progress ** Changed in: mahara/15.10 Status: Confirmed => In Progress ** Changed in: mahara/16.04 Status: Confirmed => Fix Committed ** Changed in: mahara/16.10 Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1630764 Title: Webservices update user has problems with preferredname and studentid fields Status in Mahara: Fix Committed Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: Fix Committed Status in Mahara 16.10 series: Fix Committed Bug description: This is like bug 1630753 but this also needs to be fixed for 16.10+ as well To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1630764/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1568613] Re: The screenreader "Remove" doesn't do anything
Hi Robert, Is this something we can upstream back to the Select2 project? Cheers, Aaron ** Changed in: mahara/16.10 Status: In Progress => Fix Committed ** Changed in: mahara/16.04 Status: Confirmed => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1568613 Title: The screenreader "Remove" doesn't do anything Status in Mahara: Fix Committed Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: Fix Committed Bug description: Mahara 16.04dev When you want to remove a tag (in the new tag search) or a person (when sending a message) just using a screenreader, clicking the "Remove" item doesn't do anything. The tag / user is not removed. Remove "interesting" It's just a screenreader issue and works fine for sighted. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1568613/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1631808] Re: Feature: Simplesamlphp support for clustered memcache session store
Patch for master: https://reviews.mahara.org/#/c/7092/ ** Summary changed: - Feature: Simplesamlphp support for clustered memcache session store + Simplesamlphp support for clustered memcache session store ** Changed in: mahara Status: New => In Progress ** Changed in: mahara Importance: Undecided => High ** Changed in: mahara Milestone: None => 16.10.0 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1631808 Title: Simplesamlphp support for clustered memcache session store Status in Mahara: In Progress Bug description: In Mahara 16.10's simplesamlphp auth plugin, we use memcache for simplesamlphp's session store. But it only supports one memcache server. For a clustered hosting environment, we need it to support multiple memcache servers (similar to how the PHP memcache sessions plugin does). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1631808/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1631808] [NEW] Simplesamlphp support for clustered memcache session store
Public bug reported: In Mahara 16.10's simplesamlphp auth plugin, we use memcache for simplesamlphp's session store. But it only supports one memcache server. For a clustered hosting environment, we need it to support multiple memcache servers (similar to how the PHP memcache sessions plugin does). ** Affects: mahara Importance: High Status: In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1631808 Title: Simplesamlphp support for clustered memcache session store Status in Mahara: In Progress Bug description: In Mahara 16.10's simplesamlphp auth plugin, we use memcache for simplesamlphp's session store. But it only supports one memcache server. For a clustered hosting environment, we need it to support multiple memcache servers (similar to how the PHP memcache sessions plugin does). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1631808/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1533377] Re: Remove Persona (browserid) auth plugin by Nov 2016, because Mozilla is ending Persona support
** Changed in: mahara Status: Confirmed => In Progress ** Changed in: mahara Assignee: (unassigned) => Aaron Wells (u-aaronw) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1533377 Title: Remove Persona (browserid) auth plugin by Nov 2016, because Mozilla is ending Persona support Status in Mahara: In Progress Bug description: Mozilla has recently announced that they're ending support for the Persona authentication service, in November 2016.: https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers Mahara has long shipped with a Persona (formerly "Browserid") auth plugin. We'll need to remove this plugin from the 16.10 release, and come up with a way to help existing sites migrate their users away from Persona. We should also consider how to help out the stable release sites in migrating users away from Persona. The Nov 2016 shutdown will be very close to the 16.10 release date, so asking sites to upgrade to 16.10 to use any migration tool will be fairly demanding, particularly since 15.04 will still be covered by its extended support lifetime. So for 15.04, 15.10, and 16.04 sites, an optional Persona migration plugin is probably the best option. That way the functionality will be available to sites that need it, without shipping new features in minor upgrades. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1533377/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1626315] Re: Wishlist: Apache-compatible 404 error response page
See https://httpd.apache.org/docs/2.4/custom-error.html for information about the format of the error response page. I believe Drupal auto-creates a .htaccess file with ErrorDocument directives and other setups. They also use one for clean urls, which is something we might consider. Of course, we can't actually write a .htaccess file in the wwwroot, because we mandate a non-writable wwwroot. Although increasingly other projects are switching away from a read-only wwwroot, in order to allow the application to update itself. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1626315 Title: Wishlist: Apache-compatible 404 error response page Status in Mahara: Confirmed Bug description: Due to receiving a few security reports about it, we've recently re- styled the 404 response pages for most of the Mahara project sites. The reports we received pointed out that the default Apache 404 response page prints the url-decoded (but still html-escaped) query portion of the URL on the page. This could result in attackers printing arbitrary text onto the page, with spaces and such, which conceivably could be part of a phishing attack. To keep thing simple, we replaced it with a static empty page that doesn't include any details about the requested query. However, ideally we'd want to print out a page more like Google's 404 page: 1. Styled in the site's theme 2. Contains the requested URL, but in a way that clearly sets it apart (i.e., url-encoded so that spaces are transformed into %20, and possibly truncated if it's quite long.) 3. Maybe translated as well. We could achieve this by shipping a PHP script with Mahara, which a Mahara site admin could then configure their Apache server to use for its 404 error document, via this directive: ErrorDocument 404 /errors/404.php We might also provide a "sample.htaccess" file, sitting at the top level of the project (outside the htdocs directory) to show people how to set this up. (We used to include a .htaccess file in Mahara's htdocs by default, but this could cause crashes if people were using different servers or different versions of Apache). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1626315/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1626315] [NEW] Wishlist: Apache-compatible 404 error response page
Public bug reported: Due to receiving a few security reports about it, we've recently re- styled the 404 response pages for most of the Mahara project sites. The reports we received pointed out that the default Apache 404 response page prints the url-decoded (but still html-escaped) query portion of the URL on the page. This could result in attackers printing arbitrary text onto the page, with spaces and such, which conceivably could be part of a phishing attack. To keep thing simple, we replaced it with a static empty page that doesn't include any details about the requested query. However, ideally we'd want to print out a page more like Google's 404 page: 1. Styled in the site's theme 2. Contains the requested URL, but in a way that clearly sets it apart (i.e., url-encoded so that spaces are transformed into %20, and possibly truncated if it's quite long.) 3. Maybe translated as well. We could achieve this by shipping a PHP script with Mahara, which a Mahara site admin could then configure their Apache server to use for its 404 error document, via this directive: ErrorDocument 404 /errors/404.php We might also provide a "sample.htaccess" file, sitting at the top level of the project (outside the htdocs directory) to show people how to set this up. (We used to include a .htaccess file in Mahara's htdocs by default, but this could cause crashes if people were using different servers or different versions of Apache). ** Affects: mahara Importance: Wishlist Status: Confirmed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1626315 Title: Wishlist: Apache-compatible 404 error response page Status in Mahara: Confirmed Bug description: Due to receiving a few security reports about it, we've recently re- styled the 404 response pages for most of the Mahara project sites. The reports we received pointed out that the default Apache 404 response page prints the url-decoded (but still html-escaped) query portion of the URL on the page. This could result in attackers printing arbitrary text onto the page, with spaces and such, which conceivably could be part of a phishing attack. To keep thing simple, we replaced it with a static empty page that doesn't include any details about the requested query. However, ideally we'd want to print out a page more like Google's 404 page: 1. Styled in the site's theme 2. Contains the requested URL, but in a way that clearly sets it apart (i.e., url-encoded so that spaces are transformed into %20, and possibly truncated if it's quite long.) 3. Maybe translated as well. We could achieve this by shipping a PHP script with Mahara, which a Mahara site admin could then configure their Apache server to use for its 404 error document, via this directive: ErrorDocument 404 /errors/404.php We might also provide a "sample.htaccess" file, sitting at the top level of the project (outside the htdocs directory) to show people how to set this up. (We used to include a .htaccess file in Mahara's htdocs by default, but this could cause crashes if people were using different servers or different versions of Apache). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1626315/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1625361] Re: Use password check on /admin/users/edit.php
I thought this was a design decision. An admin is most likely setting a temporary password for another user, or (in my case) setting up a test password for dev purposes. In those cases, it's more convenient not to have the password restrictions in place. Although, I'd be happy if we added the password restrictions everywhere, *but* added a config-defaults.php setting to optionally disable them. (Moodle has this. You can put "$CFG->passwordpolicy=0;" in your config.php, and it will disable password restrictions.) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1625361 Title: Use password check on /admin/users/edit.php Status in Mahara: Confirmed Bug description: When you change your password on your personal account settings page or via the force password screen, it goes through a password checker to determine some basic security and length of the password. These checks are not performed on when changing the password on /admin/users/edit.php as admin. For example: I can enter the password "mahara" on that screen, but can't use it on /account/index.php because it's deemed too simple. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1625361/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1184465] Re: Add version numbers to language packs
** Description changed: As I touched on in https://bugs.launchpad.net/mahara/+bug/1180544 , there's currently no way for a user looking at the langpacks site ( http://langpacks.mahara.org/ ) to tell whether there's been an update to their language pack. Therefore, it would be useful if we added version numbers to the language packs. These could be placed in lang/langconfig.php, something like this: $string['release'] = '1.7.1'; // The Mahara release number this langpack was created for $string['version'] = '2013052700'; // Incremented on each new release of the langpack, using the current date. And the name of the langpack file could be changed to something along the lines of "vi-1.7_STABLE-2013052700.tar.gz". + + A related idea would be to have specific langpack releases tied to + Mahara minor version releases, to support the case where a language + string's name is changed in a minor version. In that case, you wouldn't + want to upgrade your langpacks before your Mahara version has been + upgraded. In that case you'd want langpack releases for each minor + version, as well as maybe a "nightly" langpack release. + + vi-1.7.3.tar.tgz + vi-1.7.4.tar.tgz + vi-1.7_STABLE-2013052700.tar.gz -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1184465 Title: Add version numbers to language packs Status in Mahara: Confirmed Bug description: As I touched on in https://bugs.launchpad.net/mahara/+bug/1180544 , there's currently no way for a user looking at the langpacks site ( http://langpacks.mahara.org/ ) to tell whether there's been an update to their language pack. Therefore, it would be useful if we added version numbers to the language packs. These could be placed in lang/langconfig.php, something like this: $string['release'] = '1.7.1'; // The Mahara release number this langpack was created for $string['version'] = '2013052700'; // Incremented on each new release of the langpack, using the current date. And the name of the langpack file could be changed to something along the lines of "vi-1.7_STABLE-2013052700.tar.gz". A related idea would be to have specific langpack releases tied to Mahara minor version releases, to support the case where a language string's name is changed in a minor version. In that case, you wouldn't want to upgrade your langpacks before your Mahara version has been upgraded. In that case you'd want langpack releases for each minor version, as well as maybe a "nightly" langpack release. vi-1.7.3.tar.tgz vi-1.7.4.tar.tgz vi-1.7_STABLE-2013052700.tar.gz To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1184465/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622858] Re: Can't access user notifications settings in mobile layout
I added some screenshots to avoid any confusion about what I'm talking about. 1. The first screenshot shows the User Settings page at full width, with the user notifications link circled in red. 2. In the next screenshot, the window has been narrowed, and some of the links in the upper-left header are now just icons. But the Notifications link is still there. 3. In the third screenshot, the window has been narrowed enough that theme has collapsed into the "mobile" layout. Most of the navigation links are now hidden in the "hamburger" menu. No link to the User Notifications page can be found, on the page or in the hamburger. I'm not sure where the Notifications link (and other potential links in the same menu) should be displayed, in mobile mode. It doesn't seem like it belongs in the hamburger menu, because the hamburger isn't really meant to change from one page to the next (I think). Perhaps it would make the most sense to just put the links underneath the page header, similar to where they are in the non-mobile layout. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622858 Title: Can't access user notifications settings in mobile layout Status in Mahara: Confirmed Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Confirmed Bug description: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622858/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622858] Re: Can't access user notifications settings in mobile layout
** Attachment added: "Theme at mid-width (text labels in upper right are now just icons). Settings subnav circled." https://bugs.launchpad.net/mahara/+bug/1622858/+attachment/4740433/+files/Settings%20-%20Mahara%20-%20Mozilla%20Firefox_136.png -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622858 Title: Can't access user notifications settings in mobile layout Status in Mahara: Confirmed Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Confirmed Bug description: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622858/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622858] Re: Can't access user notifications settings in mobile layout
** Attachment added: "Theme at narrowest width. No access to settings subnav." https://bugs.launchpad.net/mahara/+bug/1622858/+attachment/4740434/+files/Settings%20-%20Mahara%20-%20Mozilla%20Firefox_137.png -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622858 Title: Can't access user notifications settings in mobile layout Status in Mahara: Confirmed Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Confirmed Bug description: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622858/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1620879] Re: Allow users to self-issue webservice access tokens
As Robert pointed out, the webservice/apptokens.php page, "Settings -> Web services", is a big, wide table, which overlaps the sidebars. It also has a bunch of messy hard-coded HTML in it which should probably be extracted out into a Smarty template. (This is probably because it was ported from a Moodle HTML generator class originally.) We should really redesign it to be less tabular and more flexible. For now, I've just disabled the display of the sidebars on that page. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1620879 Title: Allow users to self-issue webservice access tokens Status in Mahara: New Bug description: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1620879/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622858] [NEW] Can't access user notifications settings in mobile layout
Public bug reported: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. ** Affects: mahara Importance: High Status: Confirmed ** Affects: mahara/15.04 Importance: Low Status: Confirmed ** Affects: mahara/15.10 Importance: Low Status: Confirmed ** Affects: mahara/16.04 Importance: Low Status: Confirmed ** Affects: mahara/16.10 Importance: High Status: Confirmed ** Tags: mobile ** Description changed: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. + + In Bug 1620879 I'm adding a "Web services" link at the same nav label as + "Settings" and "Notifications", to allow users to manage their + webservices authorizations. Since these users are already on mobile + devices, it becomes more important that they're able to access this + submenu on mobile. ** Also affects: mahara/16.10 Importance: Undecided Status: New ** Also affects: mahara/15.10 Importance: Undecided Status: New ** Also affects: mahara/15.04 Importance: Undecided Status: New ** Also affects: mahara/16.04 Importance: Undecided Status: New ** Changed in: mahara/16.10 Importance: Undecided => High ** Changed in: mahara/16.04 Importance: Undecided => Low ** Changed in: mahara/15.10 Importance: Undecided => Low ** Changed in: mahara/15.04 Importance: Undecided => Low ** Changed in: mahara/16.10 Milestone: None => 16.10.0 ** Changed in: mahara/16.04 Milestone: None => 16.04.4 ** Changed in: mahara/15.10 Milestone: None => 15.10.6 ** Changed in: mahara/15.04 Milestone: None => 15.04.10 ** Changed in: mahara/16.10 Status: New => Confirmed ** Changed in: mahara/16.04 Status: New => Confirmed ** Changed in: mahara/15.10 Status: New => Confirmed ** Changed in: mahara/15.04 Status: New => Confirmed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622858 Title: Can't access user notifications settings in mobile layout Status in Mahara: Confirmed Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Confirmed Bug description: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part
[Mahara-contributors] [Bug 1622858] Re: Can't access user notifications settings in mobile layout
To replicate: 1. Open Mahara in a mobile browser, on in a desktop browser window that has been shrunk narrow enough that the normal tab navigation disappears and is replaced by the "hamburger" menu navigation. 2. Log in as any user 3. In the top bar of the page, click the gear icon (between the person icon [profile] and envelope icon [inbox]) 4. You should now be on the user's "Settings" page. Expected result: Somewhere on the page is a navigation link to "Notifications", to take you to the user's notifications settings page. Actual result: There is no visible "Notifications" link on the page. ** Tags added: mobile ** Description changed: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. - In Bug 1620879 I'm adding a "Web services" link at the same nav label as + In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622858 Title: Can't access user notifications settings in mobile layout Status in Mahara: Confirmed Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Confirmed Bug description: While working on Bug 1620879, I noticed that the user settings subnavigation links aren't accessible when Mahara's responsive theme shifts to the narrower "mobile" layout. This is true in 15.04 through 16.10dev. Prior to Bug 1620879, the subnavigation links in question are just "Settings" ( "account/index.php" )and "Notifications" ( htdocs/account/activity/preferences/index.php ). You can get to the "Settings" page easily enough in mobile by clicking the settings gear icon in the page header. But in desktop mode, the main user settings page has a subnav (generated by the "right_nav()" function in htdocs/lib/web.php) that lets you switch from "Settings" to "Notifications". In mobile, that subnav doesn't display, and it's not part of the "hamburger" menus either. In Bug 1620879 I'm adding a "Web services" link at the same nav level as "Settings" and "Notifications", to allow users to manage their webservices authorizations. Since these users are already on mobile devices, it becomes more important that they're able to access this submenu on mobile. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622858/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622788] Re: Update the dependencies error for ssphp
On further research, since we are downloading the release tarball we do *not* need to run "composer --update". The .tar.gz file that we download is built using the bin/build- release.sh script in the simplesamlphp git repo: https://github.com/simplesamlphp/simplesamlphp/blob/f5ff7c4643b9b784957f5e1fbf86fc740cd6b78a/bin /build-release.sh The build script clones a new repo based on the tag for the release. Then it runs "composer install" to get all the basic simplesamlphp dependencies, *and* "composer require" to install a big list of optional plugins. "composer require" does two things. It downloads the actual packages and their dependency files to the specified location, and it updates the composer.json file. So that means that, indeed, the tarball actually does contain all its PHP files already. So we can skip running "composer update" after upgrading it. The SimpleSAMLPHP OpenID plugins are the only ones that need GMP. So we can change the listing for that to an optional depedency, only required if you want to use SimpleSAMLPHP as an OpenID IdP consumer. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622788 Title: Update the dependencies error for ssphp Status in Mahara: New Bug description: Here are some more things that need to be installed before 'make ssphp' will run. php5-gmp and php-sqlite so we need to update our error messages to suit To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622788/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622788] Re: Update the dependencies error for ssphp
Whoops, half-sentence in the above comment. The htdocs/auth/saml/extlib/simplesamlphp/composer.json file comes from the SimpleSamlPHP release tarball that we download. We're sort of using a semi-composer method for managing SimpleSAMLPHP. We're not managing it as a proper composer dependency (in which case we'd just have "simplesamlphp" in our root-level composer.json file and do "composer --install"). Instead we download a specific release tarball, unzip it, and run composer --update against it. Do we actually need to do that? I would have thought that the whole point of downloading a release tarball, is that we don't need to run any composer commands afterward? -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622788 Title: Update the dependencies error for ssphp Status in Mahara: New Bug description: Here are some more things that need to be installed before 'make ssphp' will run. php5-gmp and php-sqlite so we need to update our error messages to suit To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622788/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622788] Re: Update the dependencies error for ssphp
Okay, it looks like these dependencies come from when we run composer --update against the composer.json file at htdocs/auth/saml/extlib/simplesamlphp/composer.json. This file, (I think) comes from One thing we can do is change the Makefile line to add "--no-dev". That will remove the "development-only" dependencies including sqlite. Since we're not doing development *on* SimpleSAMLPHP, we don't need the dev dependencies. The need for GMP comes from openid/php-openid. That's not present in the composer.json from the SimpleSAMLPHP git repository, so it seems to be added by their build process. There is a build script in their repo, so maybe I'll check and see if I can figure out if it's fiddling with the composer.json. May be it's flattening the dependencies list or something, or aggregating multiple composer.json files in different directories? -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622788 Title: Update the dependencies error for ssphp Status in Mahara: New Bug description: Here are some more things that need to be installed before 'make ssphp' will run. php5-gmp and php-sqlite so we need to update our error messages to suit To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622788/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622788] Re: Update the dependencies error for ssphp
Here's the list of SimpleSAML php depedencies from their manual: https://simplesamlphp.org/docs/stable/simplesamlphp-install#section_3 Some webserver capable of executing PHP scripts. PHP version >= 5.3.0. Support for the following PHP extensions: Always required: date, dom, hash, libxml, openssl, pcre, SPL, zlib When using encryption or digital signatures: mcrypt When authenticating against LDAP server: ldap When authenticating against RADIUS server: radius When saving session information to memcache-server: memcache When using database: Always: PDO Database driver: (mysql, pgsql, ...) Because we're not using it as an identity provider, we don't need ldap or radius. We're currently using memcache as the session provider, so that's the "memcache" dependency. We're not using the database for sessions or IdP, so we don't need any of the DB libraries (including sqlite). Although it might be a good idea to switch our simplesamlphp setup to use the DB for sessions instead of memcache, in order to reduce the number of dependencies? Or maybe to detect whether the Mahara site itself is using standard PHP sessions, or memcache sessions. I think Piers believed there was some kind of conflict with using PHP sessions, but I'm not sure if that was only a problem if you were doing it in a multi-hosted environment, or if it just didn't work at all... -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622788 Title: Update the dependencies error for ssphp Status in Mahara: New Bug description: Here are some more things that need to be installed before 'make ssphp' will run. php5-gmp and php-sqlite so we need to update our error messages to suit To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622788/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1622788] Re: Update the dependencies error for ssphp
That list may be incomplete, though, because it doesn't mention the GMP (GNU Multiple Precision Arithmetic Library) at all. Then again, maybe it's only used by one of the extensions? -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1622788 Title: Update the dependencies error for ssphp Status in Mahara: New Bug description: Here are some more things that need to be installed before 'make ssphp' will run. php5-gmp and php-sqlite so we need to update our error messages to suit To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1622788/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation rejects top-level domains longer than 4 characters
** Changed in: mahara/16.04 Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation rejects top-level domains longer than 4 characters Status in Mahara: Fix Committed Status in Mahara 15.04 series: Won't Fix Status in Mahara 15.10 series: Won't Fix Status in Mahara 16.04 series: Fix Committed Status in Mahara 16.10 series: Fix Committed Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1620879] Re: Allow users to self-issue webservice access tokens
So, the one undetermined issue with users self-issuing tokens, is access control. In Moodle there's a capability for this, and also any user who is a site admin is *not* allowed to self-issue tokens through the REST interface, for security purposes. (Admins can still self-generate tokens through the web UI) We can easily add the restriction on admin users if we want, but the bigger question is, how do we decide which normal users can self-issue webservices tokens? Currently, the closest thing we have is the "webservice" auth method. However, this isn't quite what we need. It is written to allow "robot" users, which authenticate to webservices via a username and password, but cannot log in to Mahara via the normal methods. We could use its presence or absence in an institution to determine whether the institution as a whole allows webservices, but I don't think that's a good idea because it would confuse admins as to the purpose of this auth plugin. The last thing we want is admins assigning users the "webservice" auth to try to let them use the app, and then discovering the users can no longer log in to Mahara. We also have per-institution connection manager setup. However, this also isn't appropriate, because the connection manager is only for configuring *outgoing* connections, i.e. Mahara using webservices to retrieve data from another service provider. In the token-issuing scenario, Mahara is instead accepting *incoming* connections. So probably what would make the most sense, would be to turn this into another per-institution setting with a sitewide default. Ideally it'd be as granular as the connection manager; so individual institutions could enable/disable individual user-token-issuing for each service group. However, it could start with a simple institution-level "on-off": "Allow individual users to access webservices (for mobile applications)" That said... since we're so late in the 16.10 release process we should probably go the simplest route. And the drop-dead simplest thing would be to piggyback this on the existing "Allow mobile uploads" sitewide admin setting. So for that route, we would hard-code the token-issuing scripts to *only* allow access to the Mahara mobile app service group, and access would be contingent on the "Allow mobile uploads" setting. (Or perhaps add a DB flag to service groups in the database to indicate that they are "mobile uploads"). So, I'll probably go that route. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1620879 Title: Allow users to self-issue webservice access tokens Status in Mahara: New Bug description: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1620879/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1620879] Re: Allow users to self-issue webservice access tokens
See https://github.com/agwells/mahara/tree/mobile for my work in progress on this. The following API changes need to be included (hopefully these can squeak into 16.10.0). Most of these are cribbed from how the functionality works in Moodle (because our Webservices module is port of the Moodle webservices module): 1. Addition of the two token-generation scripts, one REST-based for the in-app-form scenario; the other a standard webpage for the embedded- iframe SSO scenario. 2. Add a "shortname" to WS service groups, that the token generation scripts can use to unambiguously refer to which service group they want a token for. 3. Use the presence or absence of a "component" value for WS service groups, to indicate whether the service group was created by a plugin, or manually created by a human. The "component" should indicate which plugin created them. 3a. Block the UI from adding/removing functions from plugin-created service groups. 3b. Update all the "example" service groups that currently ship with Mahara, so that they no longer have a "component" value 4. Implement any necessary functions and/or service groups for the mobile app. (The clean way of doing this would be to make the app do everything through the new webservices system, and get rid of the old /api/mobile directory. The quick-and-dirty way of doing this would be to create a function in the new webservice, for generating the tokens used by /api/mobile. [So yes, that would mean the app gets a token for the *new* webservices, then uses that to get a token for the *old* webservices.]) 5. Determine the access control; which users are allowed to self- generate webservice tokens? Moodle does this via its capabilities system, which there is no direct equivalent of in Moodle. The current webservices permissions don't exactly work for this. See follow-up note for more details. 6. Give users the ability to inspect and cancel their self-issued webservices tokens. (This mainly means, changing the permissions and navigation menus for webservice/apptokens.php, which is currently an admin-only script that handles this behavior.) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1620879 Title: Allow users to self-issue webservice access tokens Status in Mahara: New Bug description: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1620879/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1620879] [NEW] Allow users to self-issue webservice access tokens
Public bug reported: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. ** Affects: mahara Importance: Undecided Status: New -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1620879 Title: Allow users to self-issue webservice access tokens Status in Mahara: New Bug description: For the generation 2 Mahara mobile app ( https://github.com/maharaproject/mahara-mobile ), we want users to be able to generate the access tokens they need via the app itself, rather than the current process where users have to log in to Mahara in a web browser, go to their account settings page, scroll to the bottom and manually create an access token (typing in its value themselves), then launch the mobile app and write that same access token into the mobile app. Instead, we envision a process the same as the Moodle Mobile app. The user is presented with a username/password field, they enter their credentials there, and the app then does the dirty work of talking to the Mahara server, requesting the access token, and storing it. In order to support SSO options, there also needs to be an alternative flow, where the app opens an embedded iframe that displays the Mahara login form, and returns the access token value back to the app when done. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1620879/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1572825] Re: voki externalmedia embed code changed
I clicked on the "share" link on that URL that Robert posted. But it looks like the "embed" option for Voki is only available for paid subscribers. http://www.voki.com/site/create?VkId=12647331=8c148a281882347e6b50d4d6c97b12fd=sharing Do we know anyone with a paid account we can use for testing? -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1572825 Title: voki externalmedia embed code changed Status in Mahara: Incomplete Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Incomplete Bug description: A recent support post on the Mahara forums has highlighted that the externalmedia flags the voki URL invalid: https://mahara.org/interaction/forum/topic.php?id=4007=0=10#post30536 It appears that the links have changed and will require an update in Mahara. Previous voki bug: https://bugs.launchpad.net/mahara/+bug/905097 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1572825/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1572825] Re: voki externalmedia embed code changed
Hm, or maybe we could email Voki tech support and ask them for a demo embed code? -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1572825 Title: voki externalmedia embed code changed Status in Mahara: Incomplete Status in Mahara 15.04 series: Confirmed Status in Mahara 15.10 series: Confirmed Status in Mahara 16.04 series: Confirmed Status in Mahara 16.10 series: Incomplete Bug description: A recent support post on the Mahara forums has highlighted that the externalmedia flags the voki URL invalid: https://mahara.org/interaction/forum/topic.php?id=4007=0=10#post30536 It appears that the links have changed and will require an update in Mahara. Previous voki bug: https://bugs.launchpad.net/mahara/+bug/905097 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1572825/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1620416] Re: Use of assign_by_ref() is not clear as to what is required
Here's the function declarations (in
htdocs/lib/dwoo/mahara/Dwoo_Mahara.php):
/**
* implements smarty api to assign data
*/
public function assign($key, $value) {
$this->_data[$key] = $value;
}
/**
* implements smarty api to assign data
*/
public function assign_by_ref($key, &$value) {
$this->_data[$key] =& $value;
}
I guess it makes sense, the difference is that assign_by_ref() passes
the parameter by reference (note the "&") and assign() passes it the PHP
default way, by value.
There are generally two reasons why you might pass a parameter by
reference in PHP. The primary reason is if you want the function to be
able to modify its parameters, usually as a way to return multiple
values. But in the case of Dwoo, that's unlikely to be useful because we
compile these templates last and we only use them for display purposes.
The other reason is for optimization. If a parameter is very large, then
you might want to pass it by reference in order to avoid having to make
a copy of it. That's probably where PHP 4 comes into this, as well. In
PHP 4, passing an object as a parameter would make a copy of the object.
In PHP 5 the handling of objects changed, so that variables hold a
pointer to the object instead of the actual object-in-memory itself.
Consequently, in PHP5 objects passed to functions are already handled
rather similarly to if they were passed by reference. (Though not
exactly the same. See here for the gory details:
http://php.net/manual/en/language.oop5.references.php ). So we don't
need $smarty->assign_by_ref() to handle objects anymore.
Additionally, using references for optimization is very 2008. PHP
engines from 5+ are optimized so that passing by value is actually
*faster* unless you're passing *very* large strings or arrays, and even
then it's only a modest speed improvement noticeable if you're doing it
thousands of times per page. We have at most a couple dozen
$smarty->assign() calls on a page. (See
http://stackoverflow.com/questions/178328/in-php-5-0-is-passing-by-
reference-faster ) So now the universal advice is to *only* use pass-by-
reference if you need to modify parameters, not as an attempt at
optimization.
So where does that leave us? Well, since we don't want Dwoo templates
modifying the values passed to them, we really should be using
$smarty->assign() everywhere instead of $smarty->assign_by_ref(). It
probably would be an okay idea to clean up all the old
$smarty->assign_by_ref() calls and change them to $smarty->assign(). The
one possible exception is if we're passing an enormous array to smarty,
like something that could cause an out-of-memory error if it were
duplicated. Although even then, it would probably be best to use other
means to avoid having that whole array in memory in the first place,
like using a file iterator or a database results pointer.
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1620416
Title:
Use of assign_by_ref() is not clear as to what is required
Status in Mahara:
New
Bug description:
In Mahara we have a bunch of $smarty->assign_by_ref('item',
$variable);
It was originally added to smarty/dwoo due to the following
"The assign_by_ref() original intention in Smarty 2 was to work around
the object-by-copy behavior of PHP4."
"The _by_ref methods have been introduced in Smarty2 mainly to be able
to pass objects to the templates in PHP4. In PHP5 these are passed
alway as a reference."
But it doesn't look like we use them in a true reference sort of way
What I mean is, this example shows referenced vs not referenced
'title' variable:
$smarty = smarty();
$title = 'cats';
$smarty->assign('title', $title);
$smarty->assign_by_ref('titleref', $title);
$title = 'dogs';
$smarty->display('template.tpl');
In the template it will display 'cat' as title and 'dogs' as titleref
rather than 'cat'.
We don't support PHP4 and so should clean up the code and make the
assign_by_ref() calls simply assign() where appropriate to make the
code clear as to what we are wanting.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1620416/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation rejects top-level domains longer than 4 characters
The older version of phpmailer in 15.10_STABLE and 15.04_STABLE doesn't validate email addresses tightly enough. Since this is only a medium- priority bug, I'm going to kill the backport to those versions. Anyone who's interested in fixing this for 15.04 or 15.10 yourself, you could probably start with my 15.04 patch, which centralizes all the email validation into the "sanitize_email()" function in htdocs/lib/mahar.php. Then just change the implementation of sanitize_email() to something that works for you, perhaps a regex or FILTER_VALIDATE_EMAIL. ** Changed in: mahara/15.04 Status: In Progress => Won't Fix ** Changed in: mahara/15.10 Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation rejects top-level domains longer than 4 characters Status in Mahara: Fix Committed Status in Mahara 15.04 series: Won't Fix Status in Mahara 15.10 series: Won't Fix Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: Fix Committed Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation rejects top-level domains longer than 4 characters
Our testers found that the PHPMailer email validation accepts a few addresses that are actually invalid: em...@example.com (Joe Smith) email@example em...@example.web email@111.222.333.4 However, it did not reject any valid addresses. So we could potentially tighten up the validation in the future, but I think preventing false- rejections is more important. Plus, Mahara sends out confirmation email messages whenever a user self-updates their email address, so that's a kind of "ultimate test" for validity. ** Changed in: mahara/16.10 Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation rejects top-level domains longer than 4 characters Status in Mahara: Fix Committed Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: Fix Committed Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
Test instructions: It seems that not all email fields in Mahara are actually validate at the time of input. One that I have verified to be validated, is the one on the admin's "Account settings" screen when viewing the account settings for another user. A useful utility for checking whether an email address is a valid format is https://isemail.info . For the specific use-case described in this bug, you can use the domain name "example.supplies", which uses the newish ".supplies" TLD. 1. Log in as admin 2. Create a new Mahara user with username "user1" 3. Go to Administration -> Users -> User search 4. Locate "user1" and click on their username, to bring up their "Account settings" screen. 5. Set the "Primary email" field to "user1@example.supplies" (or another exotic but valid email address) 6. Click "Save changes" Expected result: The email is updated Actual result: The form is rejected with the message "Email address is invalid". ** Summary changed: - Email validation bug (long domains) + Email validation rejects top-level domains longer than 4 characters -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation rejects top-level domains longer than 4 characters Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
Patch for master: https://reviews.mahara.org/#/c/6876/4 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation bug (long domains) Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1364705] Re: Save another 17 seconds off a 1000 user export by caching the value of $updated in LeapExportElementInternal's assign_smarty_vars function.
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1364705 Title: Save another 17 seconds off a 1000 user export by caching the value of $updated in LeapExportElementInternal's assign_smarty_vars function. Status in Mahara: Fix Committed Bug description: This bug/patch lets us save another 17 seconds off a 1000 user export by caching the value of $updated in LeapExportElementInternal's assign_smarty_vars function. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1364705/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1525736] Re: update_record() doesn't allow for a column listed in the 'where' object to be updated
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1525736 Title: update_record() doesn't allow for a column listed in the 'where' object to be updated Status in Mahara: Fix Committed Bug description: If I have a where object like: stdClass Object ( [localusr] => 11 [authinstance] => 2 ) And data object like: stdClass Object ( [remoteusername] => 'n...@void.com' [authinstance] => 4 [localusr] => 11 ) It will only update the remoteusername and not the authinstance as well? The reason for this is that inside update_record() is a foreach loop to remove any data fields if they match where fields But we probably don't need to do that. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1525736/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614805] Re: Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader
** Changed in: mahara/16.10 Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614805 Title: Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader Status in Mahara: Fix Committed Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: Fix Committed Bug description: In Bug 1614298 there were some differences of behavior between the CLI upgrader and the web upgrader, due to how they handled the out-of- sequence installation of the module/webservices plugin. This plugin is installed in the core lib/db/upgrade.php file, by a call to plugin_upgrade(), in order to make sure it gets installed instead of leaving it as an optional user-initiated installation. The CLI upgrader operates by running "check_upgrades()" at the beginning, which then looks at every component and plugin in Mahara to see which ones need to be upgraded. The return data includes the "installed" version number (retrieved from the database) and the "new" version number (from the version.php files on the filesystem). It then passes this data to "upgrade_mahara($data)", which loops over the array and runs the installer for each component. As a result, the webservices plugin was listed as needing upgrading, and then it got installed during the "core" upgrade step by the call to "upgrade_plugin()", and again by upgrade_mahara() when it looped through the listed plugins needing installation. The version number passed to the upgrade function by upgrade_mahara() was based on the initial call to check_upgrades() at the start of the script, causing the same upgrade block in the plugin's db/upgrade.php script to be executed twice. The AJAX upgrader didn't have this problem, because it re-checks the status of each plugin before running the upgrade function for that plugin. First the parent script calls "check_plugins()" to find all the plugins that need to be upgraded. Then it sends a request to upgrade.json.php for each upgrade component. And then upgrade.json.php calls check_plugins() again. It does this in order to retrieve the full data about the plugin; but it has the side effect of preventing the double-upgrading of plugins that were upgraded or installed out of order by core. It'd be best if both installation routes performed the same. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614805/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1451328] Re: Timezone identifier support for PHP on Windows
We've also had a report of this coming from an Amazon cloud server running a lightweight Linux distro that uses "musl" for its C standard library instead of glibc: https://en.wikipedia.org/wiki/Musl Apparently glibc includes several formatting options (such as %l) that are not part of the POSIX standard: http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1451328 Title: Timezone identifier support for PHP on Windows Status in Mahara: Triaged Bug description: Last login column for users search is blank (and does not sort in the correct order) also the warning saying 'PHP on your website host does not return a useful value for the timezone identifier (%z) .' on the admin page is not a fix for the problem and unfortunately some of us are not able to change from hosting on a Windows server. I am wondering if Mahara is using strftime resulting in the time zone identifier returning 'New Zealand Standard Time' in Windows rather than Linux' +1200 is part of the problem. I have searched the forums but not found a fix. Server: Windows 2012 R2 Mahara version: 15.04.0 and 1.9.4 IIS: 8.5 (both servers) also had same problem on a WAMP environment PHP version: 5.5.3 and 5.5.8 MySQL version: 5.5.40 on both servers To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1451328/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1451328] Re: Timezone identifier support for PHP on Windows
See also https://wiki.mahara.org/wiki/System_Administrator's_Guide/Installing_Mahara/Installing_Mahara_in_Wampserver for advice on how to workaround this with a local lang file. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1451328 Title: Timezone identifier support for PHP on Windows Status in Mahara: Triaged Bug description: Last login column for users search is blank (and does not sort in the correct order) also the warning saying 'PHP on your website host does not return a useful value for the timezone identifier (%z) .' on the admin page is not a fix for the problem and unfortunately some of us are not able to change from hosting on a Windows server. I am wondering if Mahara is using strftime resulting in the time zone identifier returning 'New Zealand Standard Time' in Windows rather than Linux' +1200 is part of the problem. I have searched the forums but not found a fix. Server: Windows 2012 R2 Mahara version: 15.04.0 and 1.9.4 IIS: 8.5 (both servers) also had same problem on a WAMP environment PHP version: 5.5.3 and 5.5.8 MySQL version: 5.5.40 on both servers To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1451328/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1451328] Re: Timezone identifier support for PHP on Windows
If anyone who is really committed to running Mahara on a non-standard platform would like to fix this, I think the only really robust solution would be to switch from strftime() to date() or DateFormat, both of which use a different formatting standard that apparently is *not* OS- dependent. The main downside to that, is that it would make all of the datetime formats in our language files obsolete, because the format is completely different. So all the translated langpacks would need to be updated or they would stop working. (Potentially that update could be automated.) There's also the simpler possibility of removing all the incompatible format strings from our core lang files. But I wouldn't want to upstream that because it would leave us printing leading zeroes in front of all of our hours and days of the month, e.g. "July 04, 07:30pm". (We could write more code to strip out those leading zeroes, but that would be hacky and brittle.) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1451328 Title: Timezone identifier support for PHP on Windows Status in Mahara: Triaged Bug description: Last login column for users search is blank (and does not sort in the correct order) also the warning saying 'PHP on your website host does not return a useful value for the timezone identifier (%z) .' on the admin page is not a fix for the problem and unfortunately some of us are not able to change from hosting on a Windows server. I am wondering if Mahara is using strftime resulting in the time zone identifier returning 'New Zealand Standard Time' in Windows rather than Linux' +1200 is part of the problem. I have searched the forums but not found a fix. Server: Windows 2012 R2 Mahara version: 15.04.0 and 1.9.4 IIS: 8.5 (both servers) also had same problem on a WAMP environment PHP version: 5.5.3 and 5.5.8 MySQL version: 5.5.40 on both servers To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1451328/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1606094] Re: Changing the file quota for users in an institution, can send notifications to users in other institutions
Thank you to SWITCH Information Technology Services in Switzerland for reporting this bug. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1606094 Title: Changing the file quota for users in an institution, can send notifications to users in other institutions Status in Mahara: Fix Committed Status in Mahara 15.04 series: Fix Released Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: On the institution config screen, there's a setting called "Update user quotas" that will do a one-time application of the institution's current "default quota" value to all existing users of the institution. At the same time, if you're using the "quota almost exceeded" notification emails, it will check each user whose quota has just been changed and send them a notification if they're near the threshold. The first part of this works fine. It does indeed update the quota for members of the changed institution, and nobody else. But there's a bug in the second part, that sends out the notifications. Instead of only checking the users in the institution, it checks *every* user in the site, and sends a notification to any of them who are near the threshold for the changed institution. This is not only annoying to users who aren't in the institution, but also confusing, because the email will tell them that their quota is the size of the changed institution's quota, when in fact their quota has not changed. To replicate: 1. Clean Mahara install 2. Log in as admin 3. Upload a 1MB file into your File -> Contents area 4. Create an institution. Save the institution. 5. Click the "edit" link for the institution. 6. Set "Default quota" to 100 Kilobytes. 7. Set "Update user quotas" to "On" 8. Click "Submit" Expected result: The admin user should not receive a notification, because they're not in that institution and their quota has not changed. Actual result: The admin user receives a notification about being over their quota, but their quota has not actually changed from the default 50MB. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1606094/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1613483] Re: Update PDFjs to 1.4.20
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1613483 Title: Update PDFjs to 1.4.20 Status in Mahara: Fix Committed Bug description: Since 1.1.1040, there have been several bug fixes and few features. We would highly update this. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1613483/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
Hm, actually for constistency's sake, because all these email addresses ultimately get validate by PHPMailer, we should probably validate them via PHPMailer's validateAddress instead. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation bug (long domains) Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
After doing a quick survey of what other PHP projects are doing (including our own PHPMailer library), I think for now we should probably just use FILTER_VALIDATE_EMAIL throughout. As mentioned above, this is an improvement, but with the following known flaws: 1. No support for one-part domains (root@localhost) 2. No support for email addresses containing unicode characters (See https://en.wikipedia.org/wiki/International_email ) PHPMailer now includes a function to punycode the domain-part of an email address if it contains unicode, but it's not exposed as a static function, apparently because it's reliant on knowing the character set of the PHPMailer instance. None of the big PHP projects currently support email addresses with unicode in the local part (before the "@"), although there are bugs raised with several of them, so we'll probably need to revisit this in a few years. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation bug (long domains) Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
Alternately, we could copy Moodle (again) and use a really liberal
regex. Moodle 3.1 uses this one, which is nearly unchanged from 2001!
The most recent functional update to it was in 2006, when it was changed
to reject email addresses where the alias ends in a ".".
Basically, this regex checks for a list of acceptable characters for the
alias, a "@", and a list of acceptable characters for the domain that
includes at least one "."
/**
* Validates an email to make sure it makes sense.
*
* @param string $address The email address to validate.
* @return boolean
*/
function validate_email($address) {
return (preg_match('#^[-!\#$%&\'*+\\/0-9=?A-Z^_`a-z{|}~]+'.
'(\.[-!\#$%&\'*+\\/0-9=?A-Z^_`a-z{|}~]+)*'.
'@'.
'[-!\#$%&\'*+\\/0-9=?A-Z^_`a-z{|}~]+\.'.
'[-!\#$%&\'*+\\./0-9=?A-Z^_`a-z{|}~]+$#',
$address));
}
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1615280
Title:
Email validation bug (long domains)
Status in Mahara:
In Progress
Status in Mahara 15.04 series:
In Progress
Status in Mahara 15.10 series:
In Progress
Status in Mahara 16.04 series:
In Progress
Status in Mahara 16.10 series:
In Progress
Bug description:
This one has existed since 2006, but only become an issue with the
opening up of TLDs over the past few years.
(https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains)
Currently the email validation in pieform limits the TLD to between 2-4
characters (see pieform_rule_email() in
htdocs/lib/pieforms/pieform/rules/email.php.)
That means people from .horse, for example, can't register. Changing the
regex fixed my immediate problem, haven't tested how the other email validation
points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so
might be better.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1615280] Re: Email validation bug (long domains)
Thanks for reporting this! I wasn't even aware that Mahara had code that was trying to validate email addresses via a simple regex like that. The code in question is pretty old, originally written in 2007 and last updated in 2009 (to allow a "+" sign in the alias part of the email address.) Of course since then, the number of top-level domain names has exploded. There used to be only a few rare ones longer than four characters; now there are dozens: https://en.wikipedia.org/wiki/List_of_Internet_top- level_domains#ICANN-era_generic_top-level_domains. I find a few issues mentioned with PHP's "FILTER_VALIDATE_EMAIL" option, specifically: 1. Requires a "." in the domain name, so it fails on eg "root@localhost" 2. Doesn't work with emails containing non-ASCII characters. You can convert the domain part to punycode first, but I'm not sure if that works for the alias part. On the other hand, both of those bugs are present in the current implementation! So switching to FILTER_VALIDATE_EMAIL would at least be an improvement. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1615280 Title: Email validation bug (long domains) Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: This one has existed since 2006, but only become an issue with the opening up of TLDs over the past few years. (https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains) Currently the email validation in pieform limits the TLD to between 2-4 characters (see pieform_rule_email() in htdocs/lib/pieforms/pieform/rules/email.php.) That means people from .horse, for example, can't register. Changing the regex fixed my immediate problem, haven't tested how the other email validation points react. They use FILTER_VALIDATE_EMAIL and PHPMailer::ValidateAddress, so might be better. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1615280/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614645] Re: TinyMCE not showing on mobile in 16.04
*** This bug is a duplicate of bug 1576643 *** https://bugs.launchpad.net/bugs/1576643 Hi Stephane, Thanks for the follow-up! I'm glad to hear the problem was already fixed. :) Cheers, Aaron ** Changed in: mahara Status: Incomplete => Invalid ** This bug has been marked a duplicate of bug 1576643 TinyMCE is not available on the iPad -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614645 Title: TinyMCE not showing on mobile in 16.04 Status in Mahara: Invalid Bug description: This is a bug reported by a user. Tinymce does not show in mobile device browsers. It used to show if device detection was turned off. We upgraded to 16.04 and now tinymce doesn't show anymore (on mobile device browsers). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614645/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614805] Re: Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader
To test: 1. Install Mahara 15.04 2. Check out the gerrit patch for the improved upgrader (in 16.10dev) 3. Run the command-line upgrader. Expected result: No errors If you're using my Mahara DevTools ( https://github.com/agwells/mahara- devtools ) you can just use its "maharaupgrade.sh" to do the CLI upgrader. Otherwise, you can run: sudo -u www-data php htdocs/admin/cli/upgrade.php (I find it's best to run the CLI upgrader sudo'ed to the www-data user so that the permissions in the dataroot don't get messed up.) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614805 Title: Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: In Bug 1614298 there were some differences of behavior between the CLI upgrader and the web upgrader, due to how they handled the out-of- sequence installation of the module/webservices plugin. This plugin is installed in the core lib/db/upgrade.php file, by a call to plugin_upgrade(), in order to make sure it gets installed instead of leaving it as an optional user-initiated installation. The CLI upgrader operates by running "check_upgrades()" at the beginning, which then looks at every component and plugin in Mahara to see which ones need to be upgraded. The return data includes the "installed" version number (retrieved from the database) and the "new" version number (from the version.php files on the filesystem). It then passes this data to "upgrade_mahara($data)", which loops over the array and runs the installer for each component. As a result, the webservices plugin was listed as needing upgrading, and then it got installed during the "core" upgrade step by the call to "upgrade_plugin()", and again by upgrade_mahara() when it looped through the listed plugins needing installation. The version number passed to the upgrade function by upgrade_mahara() was based on the initial call to check_upgrades() at the start of the script, causing the same upgrade block in the plugin's db/upgrade.php script to be executed twice. The AJAX upgrader didn't have this problem, because it re-checks the status of each plugin before running the upgrade function for that plugin. First the parent script calls "check_plugins()" to find all the plugins that need to be upgraded. Then it sends a request to upgrade.json.php for each upgrade component. And then upgrade.json.php calls check_plugins() again. It does this in order to retrieve the full data about the plugin; but it has the side effect of preventing the double-upgrading of plugins that were upgraded or installed out of order by core. It'd be best if both installation routes performed the same. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614805/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614805] [NEW] Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader
Public bug reported: In Bug 1614298 there were some differences of behavior between the CLI upgrader and the web upgrader, due to how they handled the out-of- sequence installation of the module/webservices plugin. This plugin is installed in the core lib/db/upgrade.php file, by a call to plugin_upgrade(), in order to make sure it gets installed instead of leaving it as an optional user-initiated installation. The CLI upgrader operates by running "check_upgrades()" at the beginning, which then looks at every component and plugin in Mahara to see which ones need to be upgraded. The return data includes the "installed" version number (retrieved from the database) and the "new" version number (from the version.php files on the filesystem). It then passes this data to "upgrade_mahara($data)", which loops over the array and runs the installer for each component. As a result, the webservices plugin was listed as needing upgrading, and then it got installed during the "core" upgrade step by the call to "upgrade_plugin()", and again by upgrade_mahara() when it looped through the listed plugins needing installation. The version number passed to the upgrade function by upgrade_mahara() was based on the initial call to check_upgrades() at the start of the script, causing the same upgrade block in the plugin's db/upgrade.php script to be executed twice. The AJAX upgrader didn't have this problem, because it re-checks the status of each plugin before running the upgrade function for that plugin. First the parent script calls "check_plugins()" to find all the plugins that need to be upgraded. Then it sends a request to upgrade.json.php for each upgrade component. And then upgrade.json.php calls check_plugins() again. It does this in order to retrieve the full data about the plugin; but it has the side effect of preventing the double-upgrading of plugins that were upgraded or installed out of order by core. It'd be best if both installation routes performed the same. ** Affects: mahara Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.04 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.10 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.04 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.10 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Also affects: mahara/16.10 Importance: Undecided Status: New ** Also affects: mahara/16.04 Importance: Undecided Status: New ** Also affects: mahara/15.04 Importance: Undecided Status: New ** Also affects: mahara/15.10 Importance: Undecided Status: New ** Changed in: mahara/16.10 Milestone: None => 16.10.0 ** Changed in: mahara/16.04 Milestone: None => 16.04.4 ** Changed in: mahara/15.10 Milestone: None => 15.10.6 ** Changed in: mahara/15.04 Milestone: None => 15.04.10 ** Changed in: mahara/15.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.10 Importance: Undecided => Medium ** Changed in: mahara/16.04 Importance: Undecided => Medium ** Changed in: mahara/15.10 Importance: Undecided => Medium ** Changed in: mahara/15.04 Importance: Undecided => Medium ** Changed in: mahara/16.10 Status: New => In Progress ** Changed in: mahara/16.04 Status: New => In Progress ** Changed in: mahara/15.10 Status: New => In Progress ** Changed in: mahara/15.04 Status: New => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614805 Title: Make out-of-sequence plugin upgrades consistent in CLI upgrader & web upgrader Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: In Bug 1614298 there were some differences of behavior between the CLI upgrader and the web upgrader, due to how they handled the out-of- sequence installation of the module/webservices plugin. This plugin is installed in the core lib/db/upgrade.php file, by a call to pl
[Mahara-contributors] [Bug 1614645] Re: TinyMCE not showing on mobile in 16.04
https://mahara.org is actually still running 15.04. (You can check by looking for the "generator" meta tag in the page's source: https://mahara.org)" /> ). So it should exhibit the old behavior, where TinyMCE is disabled on mobile if you have device detection on, and TinyMCE is enabled on mobile if you have device detection off. http://demo.mahara.org is on 16.04, so it should have the new behavior, in which device detection has *no* effect on whether or not we use TinyMCE. Instead, usage of TinyMCE is entirely controlled by the site & user-level "HTML editor" settings. Having "HTML editor" set to "off" either at the site level or the user level, will disable TinyMCE. It should probably be labelled "rich text editor" instead, to make it clearer that it's referring to TinyMCE. Cheers, Aaron -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614645 Title: TinyMCE not showing on mobile in 16.04 Status in Mahara: Incomplete Bug description: This is a bug reported by a user. Tinymce does not show in mobile device browsers. It used to show if device detection was turned off. We upgraded to 16.04 and now tinymce doesn't show anymore (on mobile device browsers). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614645/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614645] Re: tinymce on mobile
I tested this out on demo.mahara.org just now (which is running 16.04.3) and was not able to replicate: 1. Log in to demo.mahara.org 2. Go to user account settings and set "Device detection" to "No" 3. Create a page Result: TinyMCE displays correctly, in the page's description field ** Changed in: mahara Status: New => Incomplete ** Summary changed: - tinymce on mobile + TinyMCE not showing on mobile in 16.04 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614645 Title: TinyMCE not showing on mobile in 16.04 Status in Mahara: Incomplete Bug description: This is a bug reported by a user. Tinymce does not show in mobile device browsers. It used to show if device detection was turned off. We upgraded to 16.04 and now tinymce doesn't show anymore (on mobile device browsers). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614645/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614645] Re: tinymce on mobile
Hi again Stephane, Some questions to help replicate this: 1. To confirm, you're seeing TinyMCE on desktop browsers, but not mobile browsers? 2. Which mobile browsers did you test this in? Is it happening in all of them or just some? 3. On the "Administration -> Site configuration" page, under "General" settings, what value do you have for "HTML editor"? 4. If you've got "HTML editor" set to "User-defined", do these users have the "HTML editor" checkbox set to "Yes" in their account settings? Cheers, Aaron -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614645 Title: tinymce on mobile Status in Mahara: New Bug description: This is a bug reported by a user. Tinymce does not show in mobile device browsers. It used to show if device detection was turned off. We upgraded to 16.04 and now tinymce doesn't show anymore (on mobile device browsers). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614645/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1606725] Re: Accessibility - Search button
Should we backport this to 16.04? ** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1606725 Title: Accessibility - Search button Status in Mahara: Fix Committed Bug description: Mahara: master A 'Search' button next to the 'Search' text field in the top right corner of the screen is recommended to improve usability and accessibility. Not all users may be aware that they need to hit the 'Enter' button to perform a search. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1606725/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614645] Re: tinymce on mobile
Hi Stephane, That's strange, we actually add a patch in 16.04.2 to make TinyMCE display in mobile browsers *all* the time, whether device detection is on or off: https://bugs.launchpad.net/mahara/+bug/1576643 I'll take a look... Cheers, Aaron ** Changed in: mahara Assignee: (unassigned) => Aaron Wells (u-aaronw) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614645 Title: tinymce on mobile Status in Mahara: New Bug description: This is a bug reported by a user. Tinymce does not show in mobile device browsers. It used to show if device detection was turned off. We upgraded to 16.04 and now tinymce doesn't show anymore (on mobile device browsers). To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614645/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614352] Re: "group_homepage_url() not defined" error on "Portfolio -> Pages" screen
Hm, it looks like I was only able to make this happen if the multirecipientnotification module isn't installed and enabled. But it should be impossible to get to 16.04.3 without installing and enabling that module, because we force-installed it in version 2014092300, and we force-enabled it in 2016030600... I'll ask the forum poster for more information about their upgrade process. Perhaps there's a scenario we missed. ** Changed in: mahara Status: New => Incomplete ** Changed in: mahara Milestone: None => 16.04.4 ** Changed in: mahara Assignee: (unassigned) => Aaron Wells (u-aaronw) -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614352 Title: "group_homepage_url() not defined" error on "Portfolio -> Pages" screen Status in Mahara: Incomplete Bug description: See https://mahara.org/interaction/forum/topic.php?id=7692=0=10 This one's similar to bug 1544381, except the user reports that they experience it on the "Portfolio -> Pages" screen. I haven't been able to replicate the problem yet, though. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614352/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1614352] [NEW] "group_homepage_url() not defined" error on "Portfolio -> Pages" screen
Public bug reported: See https://mahara.org/interaction/forum/topic.php?id=7692=0=10 This one's similar to bug 1544381, except the user reports that they experience it on the "Portfolio -> Pages" screen. I haven't been able to replicate the problem yet, though. ** Affects: mahara Importance: Undecided Status: New -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1614352 Title: "group_homepage_url() not defined" error on "Portfolio -> Pages" screen Status in Mahara: New Bug description: See https://mahara.org/interaction/forum/topic.php?id=7692=0=10 This one's similar to bug 1544381, except the user reports that they experience it on the "Portfolio -> Pages" screen. I haven't been able to replicate the problem yet, though. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1614352/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1613478] Re: Update Elastica library to 2.3.1
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1613478 Title: Update Elastica library to 2.3.1 Status in Mahara: Fix Committed Bug description: The current version of Elastica is 2.0.0, we should update it to 2.3.1 as it has lots of bug fixes and support for newer Elasticsearch 1.7.3+. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1613478/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1594615] Re: Replace PEAR::XML_Feed_Parser by the PHP XML standard library
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1594615 Title: Replace PEAR::XML_Feed_Parser by the PHP XML standard library Status in Mahara: Fix Committed Bug description: Version master(16.10) It would be good to replace PEAR::XML_Feed_Parser by the PHP XML standard library Ref: http://www.the-art-of-web.com/php/feed-reader/ To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1594615/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1613392] Re: PostgreSQL insert error into site_content with multibyte language packs.
I was finally able to replicate this! I had assumed the "\x..."
formatting in the original error stack was generated by var_dump(), but
then I realized, perhaps that was the actual content of the lang string.
And sure enough, copying the original string with all the "\x..."s in
it, instead of the decoded Japanese glyphs, replicated the error.
And I was able to minimize it down to that suspect \x81\xa7 character.
1. Modify htdocs/lang/en.utf8/install.php so that
'loggedouthomedefaultcontent' is this:
$string['loggedouthomedefaultcontent'] = "\x81\xa7";
2. Log in. Create a new institution.
Expected result: You create a new institution.
Actual result: Error stack containing this message: Failed to get a recordset:
postgres8 error: [-1: ERROR: invalid byte sequence for encoding "UTF8": 0x81]
The error went goes away if you do any of these:
- Replace with "\xe3\x81\xa7" (で) http://www.mclean.net.nz/ucf/?c=U+3067
- Replace with "で"
- Replace with "\xe8\x86\xa7" (膧) http://www.mclean.net.nz/ucf/?c=U+81A7
- Replace with "膧"
So it does seem to be an issue with the lang file itself, not with
Mahara. The code change shouldn't be necessary so long as lang files
contain only valid UTF-8. User input becomes UTF-8 encoded via the
browser, due to the "" tag we put on every page. I suppose there is still the
possibility of data from other sources having incompatible encoding,
like RSS feeds or Leap2a files. But we'll cross that bridge when we come
to it.
Cheers,
Aaron
** Changed in: mahara
Status: Incomplete => Invalid
** Changed in: mahara
Status: Invalid => Won't Fix
** Changed in: mahara
Status: Won't Fix => Invalid
** Changed in: mahara
Status: Invalid => Won't Fix
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1613392
Title:
PostgreSQL insert error into site_content with multibyte language
packs.
Status in Mahara:
Won't Fix
Bug description:
When we try to add a new institution using Japanese language menu, we
have an error message "Mahara: Site unavailable A nonrecoverable error
occurred. This probably means you have encountered a bug in the
system" and can't add the institution.
And Apache error log says as below:
[error] [client xxx.xxx.xxx.xxx] [WAR] 18 (lib/errors.php:820) HINT: This
error can also happen if the byte sequence does not match the encoding expected
by the server, which is controlled by "client_encoding".] in adodb_throw(INSERT
INTO "site_content" ("name", "content", "ctime", "mtime", "institution") VALUES
(?, ?, ?, ?, ?),
[Mahara-contributors] [Bug 1612481] Re: "Exact user search" doesn't work intuitively with names containing spaces
Hm, just realize that I accidentally used "||" as both concatenation and OR in the above SQL snippet. What I meant to say was that if you wanted to compare the entire search query against the firstname, lastname, and a concatenation of them both (in both orders to account for internationalization), it'd be something like this: u.firstname = OR u.lastname = OR u.lastname || ' ' || u.firstname = OR u.firstname || ' ' || u.lastname = -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1612481 Title: "Exact user search" doesn't work intuitively with names containing spaces Status in Mahara: Confirmed Bug description: Steps to replicate: Make sure that the setting "Exact user searches" set to Yes on admin/extensions/pluginconfig.php?plugintype=search=internal Create a user with multi word lastname, e.g Bla Bla Bla Navigate to /admin/users/search.php Type this in search form: Bla Bla Bla Expected result: User is in the search results, because you've typed their exact last name. Actual result: User is not in the search results Workaround: Enclose the firstname and/or lastname *by itself* in double quotes. e.g., for the user Aaron von Wells, search for: Aaron "von Wells" To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1612481/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1612481] Re: "Exact user search" doesn't work intuitively with names containing spaces
Hi Dmitri,
It worked for me on the admin page. I'll use [square brackets] to
enclose strings below, to try to avoid confusion when I'm talking about
strings that contain double quotes.
1. Clean install of Mahara
2. Log in as admin
3. Go to Content -> Profile and change my first name to: [Ad min]
4. Go to the Administration -> Extensions -> Search/Internal config page and
verify that exact search is on.
5. Go to Administration -> Users -> User search (admin/users/search.php) and
search for ["Ad min"]
Result: The admin user shows up in the search results.
I agree that it's still bad usability, though. I think many users would
expect [ad min user] or ["ad min user"] to work, but in fact you have to
enclose the first name and/or last name *by itself* in quote marks,
which I would probably not have thought of doing, and there isn't even a
help bubble on the page to explain that we support the quote mark search
operator.
Currently the behavior is this:
1. PluginSearchInternal::split_query_string() splits the search query
into search terms. Any quote-enclosed strings become a search term. The
remaining non-quoted text is split up by space characters into separate
search terms.
2. PluginSearchInternal::match_user_field_expression() writes a SQL
expression to compare each applicable database field to each search
term.
2a. If exact search is on, it does an exact match: lower() =
lower()
2b. If exact search is off, it does a wildcard match: lower()
like lower('%%')
So what Kristina said is not exactly true. An "exact search" for [Jon
Smith] will actually pull up Jon Paul, and Mike Smith. It just excludes
Jonathan Smithson.
That said, it's tricky to come up with a way to support [ad min user]
while still honoring the original exact search use case, which I guess
is roughly "Each part of the search query must be an exact match to a
part of the user's name". I can think of two ideas:
1. Robert's suggestion of adding search terms for all adjacent
combinations of space-separated unquoted elements in the query. So [a b
c] would yield these search terms: [a], [b], [c], [a b], [b c], and [a b
c]. The downside is that the number of search terms scales geometrically
with the number of spaces in the search query. Also, it may be tricky to
handle partly-quoted search queries such as [a "b c" d], although that's
a corner case.
2. Compare the entire search query against a concatenation of the
firstname and lastname fields. So the SQL would be something like
"u.firstname = || u.lastname = || u.firstname ||
u.lastname = || u.lastname || u.firstname = ". (For
quoted search terms, we could just remove the quote marks.) This would
be hard to fit into the existing code, though, which handles each search
field quite separately.
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1612481
Title:
"Exact user search" doesn't work intuitively with names containing
spaces
Status in Mahara:
Confirmed
Bug description:
Steps to replicate:
Make sure that the setting "Exact user searches" set to Yes on
admin/extensions/pluginconfig.php?plugintype=search=internal
Create a user with multi word lastname, e.g Bla Bla Bla
Navigate to /admin/users/search.php
Type this in search form:
Bla Bla Bla
Expected result: User is in the search results, because you've typed their
exact last name.
Actual result: User is not in the search results
Workaround: Enclose the firstname and/or lastname *by itself* in
double quotes. e.g., for the user Aaron von Wells, search for:
Aaron "von Wells"
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1612481/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1612481] Re: In some cases users are out of the search result on admin page
** Description changed: Steps to replicate: Make sure that the setting "Exact user searches" set to Yes on admin/extensions/pluginconfig.php?plugintype=search=internal Create a user with multi word lastname, e.g Bla Bla Bla Navigate to /admin/users/search.php - Type Bla in search form + Type this in search form: + Bla Bla Bla + + Expected result: User is in the search results, because you've typed their exact last name. Actual result: User is not in the search results - Expected result: User is in the search results ** Summary changed: - In some cases users are out of the search result on admin page + "Exact user search" doesn't work intuitively with names containing spaces ** Description changed: Steps to replicate: Make sure that the setting "Exact user searches" set to Yes on admin/extensions/pluginconfig.php?plugintype=search=internal Create a user with multi word lastname, e.g Bla Bla Bla Navigate to /admin/users/search.php Type this in search form: - Bla Bla Bla + Bla Bla Bla Expected result: User is in the search results, because you've typed their exact last name. Actual result: User is not in the search results + + Workaround: Enclose the firstname and/or lastname *by itself* in double + quotes. e.g., for the user Aaron von Wells, search for: + + Aaron "von Wells" -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1612481 Title: "Exact user search" doesn't work intuitively with names containing spaces Status in Mahara: Confirmed Bug description: Steps to replicate: Make sure that the setting "Exact user searches" set to Yes on admin/extensions/pluginconfig.php?plugintype=search=internal Create a user with multi word lastname, e.g Bla Bla Bla Navigate to /admin/users/search.php Type this in search form: Bla Bla Bla Expected result: User is in the search results, because you've typed their exact last name. Actual result: User is not in the search results Workaround: Enclose the firstname and/or lastname *by itself* in double quotes. e.g., for the user Aaron von Wells, search for: Aaron "von Wells" To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1612481/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1613392] Re: PostgreSQL insert error into site_content with multibyte language packs.
Hm, one more note on this. There was one character in the middle of that
block that originally didn't print. It's the "\x81\xa7" towards the end
of the text, which rendered as: ��.
In my copy-paste above, I replaced it with UTF-16 81a7: 膧
(http://www.mclean.net.nz/ucf/?c=U+81A7), but it was the one glyph in
the block that Google Translate didn't recognize as Japanese. Instead,
Google said it was Chinese.
Perhaps this glyph had something to do with the issue? I wonder if it's
meant to be the Hiragana で, which is UTF-8 E3 81 A7, i.e.
"\xe3\x81\xa7", and the "\xe3" was left out as a typo.
Cheers,
Aaron
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1613392
Title:
PostgreSQL insert error into site_content with multibyte language
packs.
Status in Mahara:
Incomplete
Bug description:
When we try to add a new institution using Japanese language menu, we
have an error message "Mahara: Site unavailable A nonrecoverable error
occurred. This probably means you have encountered a bug in the
system" and can't add the institution.
And Apache error log says as below:
[error] [client xxx.xxx.xxx.xxx] [WAR] 18 (lib/errors.php:820) HINT: This
error can also happen if the byte sequence does not match the encoding expected
by the server, which is controlled by "client_encoding".] in adodb_throw(INSERT
INTO "site_content" ("name", "content", "ctime", "mtime", "institution") VALUES
(?, ?, ?, ?, ?),
[Mahara-contributors] [Bug 1613392] Re: PostgreSQL insert error into site_content with multibyte language packs.
Are you using custom lang files? And if so, would you mind attaching the lang/ja.utf8/install.php file here for testing? >From that error stack, it looks like it was trying to insert this block of text: Maharaにようこそ [あなたの組織名]はオンラインコミュニティを構築するための十分な機能を有するインターネット上のポートフォリオシステムです。
[Mahara-contributors] [Bug 1613392] Re: PostgreSQL insert error into site_content with multibyte language packs.
Hi all,
I wasn't able to replicate this one. Here's what I tried:
1. Clean install of Mahara 16.10dev
2. Download and install Japanese language pack from langpacks.mahara.org
3. Select Japanese as my language in Mahara
4. Log in
5. Create a new institution
Expected (error) result: Errors out with encoding issue
Actual result: It went through fine, and created the new static pages in the
site_content table in Japanese.
This was testing with Postgresql 9.1, Ubuntu 14.04, PHP 5.5, Apaache
2.4.
Cheers,
Aaron
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1613392
Title:
PostgreSQL insert error into site_content with multibyte language
packs.
Status in Mahara:
In Progress
Bug description:
When we try to add a new institution using Japanese language menu, we
have an error message "Mahara: Site unavailable A nonrecoverable error
occurred. This probably means you have encountered a bug in the
system" and can't add the institution.
And Apache error log says as below:
[error] [client xxx.xxx.xxx.xxx] [WAR] 18 (lib/errors.php:820) HINT: This
error can also happen if the byte sequence does not match the encoding expected
by the server, which is controlled by "client_encoding".] in adodb_throw(INSERT
INTO "site_content" ("name", "content", "ctime", "mtime", "institution") VALUES
(?, ?, ?, ?, ?),
home,Mahara\xe3\x81\xab\xe3\x82\x88\xe3\x81\x86\xe3\x81\x93\xe3\x81\x9d[\xe3\x81\x82\xe3\x81\xaa\xe3\x81\x9f\xe3\x81\xae\xe7\xb5\x84\xe7\xb9\x94\xe5\x90\x8d]\xe3\x81\xaf\xe3\x82\xaa\xe3\x83\xb3\xe3\x83\xa9\xe3\x82\xa4\xe3\x83\xb3\xe3\x82\xb3\xe3\x83\x9f\xe3\x83\xa5\xe3\x83\x8b\xe3\x83\x86\xe3\x82\xa3\xe3\x82\x92\xe6\xa7\x8b\xe7\xaf\x89\xe3\x81\x99\xe3\x82\x8b\xe3\x81\x9f\xe3\x82\x81\xe3\x81\xae\xe5\x8d\x81\xe5\x88\x86\xe3\x81\xaa\xe6\xa9\x9f\xe8\x83\xbd\xe3\x82\x92\xe6\x9c\x89\xe3\x81\x99\xe3\x82\x8b\xe3\x82\xa4\xe3\x83\xb3\xe3\x82\xbf\xe3\x83\xbc\xe3\x83\x8d\xe3\x83\x83\xe3\x83\x88\xe4\xb8\x8a\xe3\x81\xae\xe3\x83\x9d\xe3\x83\xbc\xe3\x83
[Mahara-contributors] [Bug 1613135] [NEW] Fix negative block_instance sortorders before running upgrade
Public bug reported: See: https://mahara.org/interaction/forum/topic.php?id=7687=0=10#post30945 For Bug 1528351 we added an upgrade block that corrects the block_instance sortorder drift that had been created by Bug 1523719. As a workaround to the uniqueness constraint on that column, this block temporarily moves the sortorders into the negative integerspace, and then re-orders them as positive numbers. However, we've had multiple reports of sites that have somehow got negative numbers already in their block_instance.sortorder column. These sites then error out during the upgrade, because the extant negative numbers turn into positive numbers, and then there's a uniqueness violation if another block being re-ordered overlaps with it. Ghada has written up a block of code that can fix this, and we've shared it with some affected sites via the forum. It should be easy to add it to the basic upgrade script, though. In order to reduce complications, we could preface it with a check to see whether there are negative sortorders in the database, and only run this additional step if we find any negatives. ** Affects: mahara Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.04 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.10 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.04 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.10 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Also affects: mahara/16.10 Importance: Undecided Status: New ** Also affects: mahara/15.04 Importance: Undecided Status: New ** Also affects: mahara/16.04 Importance: Undecided Status: New ** Also affects: mahara/15.10 Importance: Undecided Status: New ** Changed in: mahara/15.04 Milestone: None => 15.04.10 ** Changed in: mahara/15.10 Milestone: None => 15.10.6 ** Changed in: mahara/16.04 Milestone: None => 16.04.4 ** Changed in: mahara/16.10 Milestone: None => 16.10.0 ** Changed in: mahara/15.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.04 Importance: Undecided => Medium ** Changed in: mahara/15.10 Importance: Undecided => Medium ** Changed in: mahara/16.04 Importance: Undecided => Medium ** Changed in: mahara/16.10 Importance: Undecided => Medium ** Changed in: mahara/16.10 Status: New => In Progress ** Changed in: mahara/16.04 Status: New => In Progress ** Changed in: mahara/15.10 Status: New => In Progress ** Changed in: mahara/15.04 Status: New => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1613135 Title: Fix negative block_instance sortorders before running upgrade Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: See: https://mahara.org/interaction/forum/topic.php?id=7687=0=10#post30945 For Bug 1528351 we added an upgrade block that corrects the block_instance sortorder drift that had been created by Bug 1523719. As a workaround to the uniqueness constraint on that column, this block temporarily moves the sortorders into the negative integerspace, and then re-orders them as positive numbers. However, we've had multiple reports of sites that have somehow got negative numbers already in their block_instance.sortorder column. These sites then error out during the upgrade, because the extant negative numbers turn into positive numbers, and then there's a uniqueness violation if another block being re-ordered overlaps with it. Ghada has written up a block of code that can fix this, and we've shared it with some affected sites via the forum. It should be easy to add it to the basic upgrade script, though. In order to reduce complications, we could preface it with a check to see whether there are negative sortorders in the database, and only run this additional step if we find any negatives. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1613135/+subscriptions
[Mahara-contributors] [Bug 1611547] Re: Adding members via Institutions -> members is broken
** Changed in: mahara Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1611547 Title: Adding members via Institutions -> members is broken Status in Mahara: Fix Committed Bug description: Turns out the patch 83069d9effc9707cf3aa1f72c8e7de8ecd78e6a4 (Purge MochiKit from mahara.js) broke the ability to add members to an institution via Institution -> Members The js returns a TypeError: data is null I suspect that all the pages using the double textarea box setup will be broken To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1611547/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1612464] [NEW] Cleanup of embedded images code
Public bug reported: While working on Bug 1612451 I noticed some brittle code in the embedded images library, that could use a reworking. ** Affects: mahara Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Changed in: mahara Milestone: None => 16.04.4 ** Changed in: mahara Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara Importance: Undecided => Low ** Changed in: mahara Status: New => In Progress -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1612464 Title: Cleanup of embedded images code Status in Mahara: In Progress Bug description: While working on Bug 1612451 I noticed some brittle code in the embedded images library, that could use a reworking. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1612464/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1611995] [NEW] Delete redundant profileicons.json.php file
Public bug reported: While code reviewing Bug 1590632, I noticed that there are two files named "profileicons.json.php" in the Mahara code base: htdocs/artefact/file/profileicons.json.php htdocs/artefact/internal/profileicons.json.php It looks like only the one under the "file" artefact is actually used (it's referenced in htdocs/artefact/file/profileicons.php). The other one was mistakenly left behind in commit c2356895f72ff2d9b7130084fc403ad1cd20d59a, when the profileicons were moved from being internal artefacts to file artefacts. ** Affects: mahara Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.04 Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/15.10 Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.04 Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Affects: mahara/16.10 Importance: Low Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Also affects: mahara/15.10 Importance: Undecided Status: New ** Also affects: mahara/16.10 Importance: Undecided Status: New ** Also affects: mahara/15.04 Importance: Undecided Status: New ** Also affects: mahara/16.04 Importance: Undecided Status: New ** Changed in: mahara/15.04 Status: New => In Progress ** Changed in: mahara/15.10 Status: New => In Progress ** Changed in: mahara/16.04 Status: New => In Progress ** Changed in: mahara/16.10 Status: New => In Progress ** Changed in: mahara/15.04 Importance: Undecided => Low ** Changed in: mahara/15.10 Importance: Undecided => Low ** Changed in: mahara/16.04 Importance: Undecided => Low ** Changed in: mahara/16.10 Importance: Undecided => Low ** Changed in: mahara/15.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.04 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/16.10 Assignee: (unassigned) => Aaron Wells (u-aaronw) ** Changed in: mahara/15.04 Milestone: None => 15.04.10 ** Changed in: mahara/15.10 Milestone: None => 15.10.6 ** Changed in: mahara/16.04 Milestone: None => 16.04.4 ** Changed in: mahara/16.10 Milestone: None => 16.10.0 -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1611995 Title: Delete redundant profileicons.json.php file Status in Mahara: In Progress Status in Mahara 15.04 series: In Progress Status in Mahara 15.10 series: In Progress Status in Mahara 16.04 series: In Progress Status in Mahara 16.10 series: In Progress Bug description: While code reviewing Bug 1590632, I noticed that there are two files named "profileicons.json.php" in the Mahara code base: htdocs/artefact/file/profileicons.json.php htdocs/artefact/internal/profileicons.json.php It looks like only the one under the "file" artefact is actually used (it's referenced in htdocs/artefact/file/profileicons.php). The other one was mistakenly left behind in commit c2356895f72ff2d9b7130084fc403ad1cd20d59a, when the profileicons were moved from being internal artefacts to file artefacts. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1611995/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1558361] Re: XSS vulnerability due to window.opener (target="_blank" and window.open())
One possible fix for this is to add rel="noreferrer" to all "target" links. But reports say this doesn't work in Internet Explorer, so it's not an option for Mahara, which still supports IE11. -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1558361 Title: XSS vulnerability due to window.opener (target="_blank" and window.open()) Status in Mahara: Fix Released Status in Mahara 1.10 series: Fix Released Status in Mahara 15.04 series: Fix Released Status in Mahara 15.10 series: Fix Released Bug description: The Catalyst security team has pointed out to us that the practice of opening new browser windows via "target" links or the Javascript window.open() command. The problem is that in these cases, the Javascript and HTML standards require that the newly opened window/tab have access to the original window's "Window" object, via "window.opener". This allows the new window to control the navigation of the original window, and possibly access other DOM objects as well, depending on security policies. The really bad part, though, is that the new window has access to window.opener, and navigation control via it, even if the new window is on a different domain than the original window. And this window.opener object remains there, even if the user goes to a new page or site in the new window, or the old window! This allows for all kinds of cross-site-scripting attacks. So, we need to prevent this behavior in Mahara. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1558361/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1611609] [NEW] Mistake in the $cfg->urlsecret manual page
Public bug reported: I noticed on the Mahara manual page for $cfg->urlsecret, it says to set it to "none" where it should be "null": http://manual.mahara.org/en/16.04/administration/config_php.html#new-in- mahara-16-04-urlsecret-run-the-cron-or-upgrade-only-when-you-are- authorised "When you have a developer instance or a test server that is behind a firewall, you may not want to add the urlsecret every time, especially when you are the only once who has access to those sites. You could put $cfg->urlsecret = none; into the config.php files for these sites and circumvent the requirement of entering a secret phrase. However, you should not use that on a production site or any other site that is accessible to many people." In the middle there, where it says: $cfg->urlsecret = none; ...it should be: $cfg->urlsecret = null; (And there shouldn't be any quotes around the word null, because null is a PHP keyword.) ** Affects: mahara Importance: High Assignee: Kristina Hoeppner (kris-hoeppner) Status: Confirmed ** Changed in: mahara Assignee: (unassigned) => Kristina Hoeppner (kris-hoeppner) ** Changed in: mahara Importance: Undecided => High ** Changed in: mahara Status: New => Confirmed -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1611609 Title: Mistake in the $cfg->urlsecret manual page Status in Mahara: Confirmed Bug description: I noticed on the Mahara manual page for $cfg->urlsecret, it says to set it to "none" where it should be "null": http://manual.mahara.org/en/16.04/administration/config_php.html#new- in-mahara-16-04-urlsecret-run-the-cron-or-upgrade-only-when-you-are- authorised "When you have a developer instance or a test server that is behind a firewall, you may not want to add the urlsecret every time, especially when you are the only once who has access to those sites. You could put $cfg->urlsecret = none; into the config.php files for these sites and circumvent the requirement of entering a secret phrase. However, you should not use that on a production site or any other site that is accessible to many people." In the middle there, where it says: $cfg->urlsecret = none; ...it should be: $cfg->urlsecret = null; (And there shouldn't be any quotes around the word null, because null is a PHP keyword.) To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1611609/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1609731] Re: Error in theme/Readme.md - 'template' should be 'templates'
** Changed in: mahara/16.04 Status: Fix Committed => Fix Released ** Changed in: mahara/15.10 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1609731 Title: Error in theme/Readme.md - 'template' should be 'templates' Status in Mahara: Fix Committed Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: Version 16.04 In the help file theme/Readme.md you are advised to create a new 'template' folder for customised templates (line 51). This is wrong. The new folder should be called 'templates'. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1609731/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1605110] Re: Raw theme table border style overrides user settings
** Changed in: mahara/16.04 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1605110 Title: Raw theme table border style overrides user settings Status in Mahara: Fix Committed Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: Table borders have been purposefully overridden by a style in the Raw theme (line 66 of /theme/raw/sass/features/_user-pages.scss), anything added by tinyMCE won't be used because of this. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1605110/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1527031] Re: Performance improvement for view_search() when finding copyable views
** Changed in: mahara/16.04 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1527031 Title: Performance improvement for view_search() when finding copyable views Status in Mahara: Fix Committed Status in Mahara 16.04 series: Fix Released Bug description: Adjusting the sql from using IN() to use EXISTS() To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1527031/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1607669] Re: LDAP user sync incorrectly proceeds when LDAP list or search fails
** Changed in: mahara/16.04
Status: Fix Committed => Fix Released
** Changed in: mahara/15.10
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1607669
Title:
LDAP user sync incorrectly proceeds when LDAP list or search fails
Status in Mahara:
Fix Committed
Status in Mahara 15.04 series:
Fix Released
Status in Mahara 15.10 series:
Fix Released
Status in Mahara 16.04 series:
Fix Released
Status in Mahara 16.10 series:
Fix Committed
Bug description:
Mahara: 16.04
DB: Postgres
OS: Linux
The LDAP user sync is incorrectly continuing when the search in the
context fails to contact the server.
The following error is generated in the cron.log file:
Jul 29 00:01:05 server mahara-site: [WAR] 29 (auth/ldap/lib.php:937)
ldap_list(): Search: Can't contact LDAP server
Jul 29 00:01:05 server mahara-site: Call stack (most recent first):
Jul 29 00:01:05 server mahara-site: * log_message("ldap_list(): Search:
Can't contact LDAP server", 8, true, true,
"/var/www/mahara-site/auth/ldap/lib.php", 937)
at /var/www/mahara-site/lib/errors.php:489
Jul 29 00:01:05 server mahara-site: * error(2, "ldap_list(): Search: Can't
contact LDAP server", "/var/www/mahara-site/auth/ldap/lib.php", 937, array(size
11)) a
t Unknown:0
Jul 29 00:01:05 server mahara-site: * ldap_list(resource(#87),
"ou=people,o=ldapserver.xxx", "(uid=*)", array(size 5)) at
/var/www/mahara-site/auth/ldap/lib.php:937
Jul 29 00:01:05 server mahara-site: *
AuthLdap->ldap_get_users_scalable("auth_ldap_extusers_temp", "extusername", "")
at /var/www/mahara-site/auth/ldap/lib.php:1
121
Jul 29 00:01:05 server mahara-site: * AuthLdap->sync_users() at
/var/www/mahara-site/auth/ldap/lib.php:1614
Jul 29 00:01:05 server mahara-site: * PluginAuthLdap::auth_ldap_sync_cron()
at Unknown:0
Jul 29 00:01:05 server mahara-site: * call_user_func_array(array(size 2),
array(size 0)) at /var/www/mahara-site/lib/mahara.php:1714
Jul 29 00:01:05 server mahara-site: * call_static_method("PluginAuthLdap",
"auth_ldap_sync_cron") at /var/www/mahara-site/lib/cron.php:89
It then proceeds to sync the users:
Jul 29 00:01:05 server mahara-site: [WAR] 29 (auth/ldap/lib.php:940)
ldap_first_entry() expects parameter 2 to be resource, boolean given
Jul 29 00:01:05 server mahara-site: Call stack (most recent first):
Jul 29 00:01:05 server mahara-site: * log_message("ldap_first_entry()
expects parameter 2 to be resou...", 8, true, true,
"/var/www/mahara-site/auth/ldap/lib.php
", 940) at /var/www/mahara-site/lib/errors.php:489
Jul 29 00:01:05 server mahara-site: * error(2, "ldap_first_entry() expects
parameter 2 to be resou...", "/var/www/mahara-site/auth/ldap/lib.php", 940,
array(size
12)) at Unknown:0
Jul 29 00:01:05 server mahara-site: * ldap_first_entry(resource(#87),
false) at /var/www/mahara-site/auth/ldap/lib.php:940
Jul 29 00:01:05 server mahara-site: *
AuthLdap->ldap_get_users_scalable("auth_ldap_extusers_temp", "extusername", "")
at /var/www/mahara-site/auth/ldap/lib.php:1121
Jul 29 00:01:05 server mahara-site: * AuthLdap->sync_users() at
/var/www/mahara-site/auth/ldap/lib.php:1614
Jul 29 00:01:05 server mahara-site: * PluginAuthLdap::auth_ldap_sync_cron()
at Unknown:0
Jul 29 00:01:05 server mahara-site: * call_user_func_array(array(size 2),
array(size 0)) at /var/www/mahara-site/lib/mahara.php:1714
Jul 29 00:01:05 server mahara-site: * call_static_method("PluginAuthLdap",
"auth_ldap_sync_cron") at /var/www/mahara-site/lib/cron.php:89
Jul 29 00:01:05 server mahara-site:
Jul 29 00:01:05 server mahara-site: [WAR] 29 (auth/ldap/lib.php:971)
ldap_free_result() expects parameter 1 to be resource, boolean given
Jul 29 00:01:05 server mahara-site: Call stack (most recent first):
Jul 29 00:01:05 server mahara-site: * log_message("ldap_free_result()
expects parameter 1 to be resou...", 8, true, true,
"/var/www/mahara-site/auth/ldap/lib.php", 971) at
/var/www/mahara-site/lib/errors.php:489
Jul 29 00:01:05 server mahara-site: * error(2, "ldap_free_result() expects
parameter 1 to be resou...", "/var/www/mahara-site/auth/ldap/lib.php", 971,
array(size 13)) at Unknown:0
Jul 29 00:01:05 server mahara-site: * ldap_free_result(false) at
/var/www/mahara-site/auth/ldap/lib.php:971
Jul 29 00:01:05 server mahara-site: *
AuthLdap->ldap_get_users_scalable("auth_ldap_extusers_temp", "extusername", "")
at /var/www/mahara-site/auth/ldap/lib.php:1121
Jul 29 00:01:05 server mahara-site: * AuthLdap->sync_users() at
/var/www/mahara-site/auth/ldap/lib.php:1614
Jul 29 00:01:05 server mahara-site: * PluginAuthLdap::auth_ldap_sync_cron()
at Unknown:0
[Mahara-contributors] [Bug 1606435] Re: Not sending enough parameters to "useroverquotathreshold" lang string
** Changed in: mahara/15.10
Status: Fix Committed => Fix Released
** Changed in: mahara/16.04
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask
on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1606435
Title:
Not sending enough parameters to "useroverquotathreshold" lang string
Status in Mahara:
Fix Committed
Status in Mahara 15.04 series:
Fix Released
Status in Mahara 15.10 series:
Fix Released
Status in Mahara 16.04 series:
Fix Released
Status in Mahara 16.10 series:
Fix Committed
Bug description:
The lang string "useroverquotathreshold" in artefact.file.php expects
three sprintf parameters, but in the two places we use it, we only use
one parameter. As a result, it prints a warning message to the error
logs, and the string it should print is replaced with an empty string.
Here's the warning message:
[WAR] 37 (lib/mahara.php:1418) sprintf(): Too few arguments
Call stack (most recent first):
* log_message("sprintf(): Too few arguments", 8, true, true,
"/home/aaronw/www/mahara/htdocs/lib/mahara.php", 1418) at
/home/aaronw/www/mahara/htdocs/lib/errors.php:489
* error(2, "sprintf(): Too few arguments",
"/home/aaronw/www/mahara/htdocs/lib/mahara.php", 1418, array(size 3)) at
Unknown:0
* sprintf("User %s has arrived at %s%% percent of their %s qu...", "user1
user1 (user1)") at Unknown:0
* call_user_func_array("sprintf", array(size 2)) at
/home/aaronw/www/mahara/htdocs/lib/mahara.php:1418
* format_langstring("User %s has arrived at %s%% percent of their %s
qu...", array(size 1), "en.utf8") at
/home/aaronw/www/mahara/htdocs/lib/mahara.php:505
* get_string_location("useroverquotathreshold", "artefact.file",
array(size 1)) at /home/aaronw/www/mahara/htdocs/lib/mahara.php:294
* get_string("useroverquotathreshold", "artefact.file", "user1 user1
(user1)") at /home/aaronw/www/mahara/htdocs/admin/users/edit.php:405
* edituser_site_submit(object(Pieform), array(size 16)) at Unknown:0
* call_user_func_array("edituser_site_submit", array(size 2)) at
/home/aaronw/www/mahara/htdocs/lib/pieforms/pieform.php:540
* Pieform->__construct(array(size 6)) at
/home/aaronw/www/mahara/htdocs/lib/pieforms/pieform.php:161
* Pieform::process(array(size 6)) at
/home/aaronw/www/mahara/htdocs/lib/mahara.php:4730
* pieform(array(size 6)) at
/home/aaronw/www/mahara/htdocs/admin/users/edit.php:265
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1606435/+subscriptions
___
Mailing list: https://launchpad.net/~mahara-contributors
Post to : mahara-contributors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mahara-contributors
More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1591760] Re: The link "Move to undefined" should not be displayed
** Changed in: mahara/15.10 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1591760 Title: The link "Move to undefined" should not be displayed Status in Mahara: Fix Committed Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: Version: master (16.10) Reported in https://mahara.org/interaction/forum/topic.php?id=7624 When I clicked an icon of a file in a sub folder, I saw the link "Move to undefined". This link is redundant. See the screenshot in the attached file To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1591760/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1431659] Re: Problems importing Annotations via Leap2a
** Changed in: mahara/16.04 Status: Fix Committed => Fix Released ** Changed in: mahara/15.10 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1431659 Title: Problems importing Annotations via Leap2a Status in Mahara: Fix Committed Status in Mahara 15.04 series: Fix Released Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Bug description: As reported on https://reviews.mahara.org/#/c/4123/: "When I import a Leap2A (a collection with two pages; one with a text and 2 annotation blocks and the other with an image block and an annotation block), I get "[INF] 83 (import/index.php:301) Leap2A import failed: Cannot find reflection entry for annotation." The text block does not have an embedded image. Just plain text." To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1431659/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1605071] Re: Display something more error-like when an AJAX block errors out
** Changed in: mahara/15.10 Status: Fix Committed => Fix Released ** Changed in: mahara/16.04 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1605071 Title: Display something more error-like when an AJAX block errors out Status in Mahara: Fix Committed Status in Mahara 15.04 series: Won't Fix Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: Spinning this bug off from Bug 1544424 (Endless JS loop if there's an uncaught exception in an ajax block) since patch https://reviews.mahara.org/6055 has taken much longer than https://reviews.mahara.org/6054 to get merged. We no longer get an endless loop when an Ajax block errors out, but it still looks pretty bad. See the attached screenshot. Because the file "blocktype.ajax.php" doesn't have the "JSON" header at its top, when it errors out, Mahara tries to print the full error page with the navigation headers and the message "Mahara: Site unavailable", and then ajaxblocks.js tries to display it in the little iframe reserved for that block. This looks confusing to the user, and it can spill over out of that block's space and cover up adjacent blocks. It would be better if we printed something that more obviously indicates that just this one block is broken, and that doesn't break the display of other blocks. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1605071/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1609112] Re: The is_plugin_active() function can give false positives
** Changed in: mahara/15.10 Status: Fix Committed => Fix Released ** Changed in: mahara/16.04 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1609112 Title: The is_plugin_active() function can give false positives Status in Mahara: Fix Committed Status in Mahara 15.04 series: Fix Released Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: This is due to the fact that we have different plugin types with the same name, eg: Artefact | Blocktype ---+ blog | blog comment| comment annotation | annotation And that we check the type 'artefact' first so in the case of the Artefact 'annotation' being active but the blocktype 'annotation' not being active we will get 'true' from is_plugin_active() We need to alter the function and pass it a 'type' so we can indicate which of the types we are interested in. I'll mark this as 'high' as this could lead to confusion in the use of the function. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1609112/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
[Mahara-contributors] [Bug 1609200] Re: Non-admin role users can edit group settings
** Changed in: mahara/16.04 Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Mahara Contributors, which is subscribed to Mahara. Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it! https://bugs.launchpad.net/bugs/1609200 Title: Non-admin role users can edit group settings Status in Mahara: Fix Committed Status in Mahara 15.04 series: Fix Released Status in Mahara 15.10 series: Fix Released Status in Mahara 16.04 series: Fix Released Status in Mahara 16.10 series: Fix Committed Bug description: Only the admin of a group should be able to change the group's settings (via group/edit.php). But any member of a group can view and edit the settings if they go to the URL directly: * http://my.mahara/group/edit.php?id=3 There is no check to make sure the user has admin role. To replicate: 1. Create a group as User 1. Note the group's id 2. Add User 2 to the group as a "member" (not an "admin") 3. Log in as User 2 4. Type in e.g. http://my.mahara/group/edit.php?id=X , where X is the group's ID Expected result: You get an error message saying "You can't edit this group" Actual result: You see the group config page, and you can make changes and they will be saved. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1609200/+subscriptions ___ Mailing list: https://launchpad.net/~mahara-contributors Post to : mahara-contributors@lists.launchpad.net Unsubscribe : https://launchpad.net/~mahara-contributors More help : https://help.launchpad.net/ListHelp
