[Mahara-contributors] [Bug 1359109] [NEW] Fail deleting long name groups
Public bug reported:
When you delete a group, it concatenates '.deleted.'.time() that is
about 19 characters. Hence, if your group name is longer than 108
characters it will throw a DB exception for exceeding the 128 characters
field for the group name. To avoid this, I've added the following code
to function group_delete($groupid, $shortname=null, $institution=null,
$notifymembers=true):
//Daniel Parejo
$delete_name = $group-name;
if (strlen($delete_name) 100) {
$delete_name = substr($delete_name, 0, 100) . '(...)';
}
//End added code
update_record('group',
array(
'deleted' = 1,
'name' = $delete_name . '.deleted.' . time(), //modified code
'shortname' = null,
'institution' = null,
'category' = null,
'urlid' = null,
),
array(
'id' = $group-id,
)
);
db_commit();
This solution is not perfect since it will fail if two groups that are
not different in their 101 first characters are tried to be removed in
the same time instant. Still, way better than before, though I think a
more solid solution should be implemented.
** Affects: mahara
Importance: Undecided
Status: New
** Tags: db delete group groups
** Description changed:
When you delete a group, it concatenates '.deleted.'.time() that is
about 19 characters. Hence, if your group name is longer than 108
characters it will throw a DB exception for exceeding the 128 characters
field for the group name. To avoid this, I've added the following code
to function group_delete($groupid, $shortname=null, $institution=null,
$notifymembers=true):
//Daniel Parejo
- $delete_name = $group-name;
- if (strlen($delete_name) 100) {
- $delete_name = substr($delete_name, 0, 100) . '(...)';
- }
+ $delete_name = $group-name;
+ if (strlen($delete_name) 100) {
+ $delete_name = substr($delete_name, 0, 100) . '(...)';
+ }
//End added code
- update_record('group',
- array(
- 'deleted' = 1,
- 'name' = $delete_name . '.deleted.' . time(), //modified code
- 'shortname' = null,
- 'institution' = null,
- 'category' = null,
- 'urlid' = null,
- ),
- array(
- 'id' = $group-id,
- )
- );
- db_commit();
+ update_record('group',
+ array(
+ 'deleted' = 1,
+ 'name' = $delete_name . '.deleted.' . time(), //modified code
+ 'shortname' = null,
+ 'institution' = null,
+ 'category' = null,
+ 'urlid' = null,
+ ),
+ array(
+ 'id' = $group-id,
+ )
+ );
+ db_commit();
-
- This solution is not perfect since it will fail if two groups that are not
different in their 101 first characters are tried to remove in the same time
instant. Still, way better than before, though I think a more solid solution
should be implemented.
+ This solution is not perfect since it will fail if two groups that are
+ not different in their 101 first characters are tried to be removed in
+ the same time instant. Still, way better than before, though I think a
+ more solid solution should be implemented.
** Tags added: groups
--
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/1359109
Title:
Fail deleting long name groups
Status in Mahara ePortfolio:
New
Bug description:
When you delete a group, it concatenates '.deleted.'.time() that is
about 19 characters. Hence, if your group name is longer than 108
characters it will throw a DB exception for exceeding the 128
characters field for the group name. To avoid this, I've added the
following code to function group_delete($groupid, $shortname=null,
$institution=null, $notifymembers=true):
//Daniel Parejo
$delete_name = $group-name;
if (strlen($delete_name) 100) {
$delete_name = substr($delete_name, 0, 100) . '(...)';
}
//End added code
update_record('group',
array(
'deleted' = 1,
'name' = $delete_name . '.deleted.' . time(), //modified code
'shortname' = null,
'institution' = null,
'category' = null,
'urlid' = null,
),
array(
'id' = $group-id,
)
);
db_commit();
This solution is not perfect since it will fail if two groups that are
not different in their 101 first characters are tried to be removed in
the same time instant. Still, way better than before, though I think a
more solid solution should be implemented.
To manage notifications
[Mahara-contributors] [Bug 1296698] Re: Text box title duplicated and only one instance updated
Thanks Robert. So are you saying that this isn't a bug at all, or just for the situations where the artefact title still makes sense when applied to the new block instance in its new context? What about when the artefact title doesn't make sense in the new context, or is even potentially confusing? Cheers, Tony -- 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/1296698 Title: Text box title duplicated and only one instance updated Status in Mahara ePortfolio: New Bug description: When a new text box is created, its original title goes into the database in two places: artefact.title and block_instance.title. However if the title is then edited, only block_instance.title gets updated; artefact.title retains the original title. This becomes an issue when the text box is viewed on its own, when both titles are displayed (whereas in the page view only the updated block_instance.title is displayed). The page owner is unable to update the original title via the Mahara interface as it doesn't appear at all when editing the block. I think there are really two issues here: firstly that the title is only updated in one place, but also that both titles are displayed when the text box is viewed on its own. If the title has never been edited, the same title is displayed twice, which is unnecessary. This has been tested in Mahara 1.8.1 on Ubuntu 13.10 with a Postgres database. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1296698/+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 1328388] A change has been merged
Reviewed: https://reviews.mahara.org/3516 Committed: http://gitorious.org/mahara/mahara/commit/e3f1cafa277068af4856ee6e806578413b999367 Submitter: Son Nguyen (son.ngu...@catalyst.net.nz) Branch:master commit e3f1cafa277068af4856ee6e806578413b999367 Author: Robert Lyon robe...@catalyst.net.nz Date: Mon Jul 28 15:37:49 2014 +1200 No indent forum style to only have two 'reply' buttons (Bug #1328388) Instead of having reply buttons next to every post there are only reply buttons before and after the list. The reply is saved as a child of the latest existing post so the forum works in a chronological way. Also added a help file to explain better what the indent options do. Change-Id: I820a611670e0e1ef5e7a645497c0f223b773c2ae Signed-off-by: Robert Lyon robe...@catalyst.net.nz -- 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/1328388 Title: Remove most of the reply buttons when a forum is set to no indent Status in Mahara ePortfolio: In Progress Bug description: As Nathan mentioned in https://reviews.mahara.org/3326, when you set a forum's indentation to no indent, we still show a reply button next to each post. This is confusing, because there's no visible difference depending on which one you click reply to. Basically, changing the indentation to no indent changes the behavior of the forum from threaded to single-thread. So we should reflect that. There should be a post or reply button at the top of the page and at the bottom, and your post should always be set as the reply to the current last post in the topic. Perhaps we ought to change the text description of the indent setting as well, to reflect the fact that now it's about behavior as well as display? To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1328388/+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 1328388] Re: Remove most of the reply buttons when a forum is set to no indent
** 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/1328388 Title: Remove most of the reply buttons when a forum is set to no indent Status in Mahara ePortfolio: Fix Committed Bug description: As Nathan mentioned in https://reviews.mahara.org/3326, when you set a forum's indentation to no indent, we still show a reply button next to each post. This is confusing, because there's no visible difference depending on which one you click reply to. Basically, changing the indentation to no indent changes the behavior of the forum from threaded to single-thread. So we should reflect that. There should be a post or reply button at the top of the page and at the bottom, and your post should always be set as the reply to the current last post in the topic. Perhaps we ought to change the text description of the indent setting as well, to reflect the fact that now it's about behavior as well as display? To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1328388/+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 1353153] Re: upgrade to 1.9 error when logged in and belonging to an institution
** 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/1353153 Title: upgrade to 1.9 error when logged in and belonging to an institution Status in Mahara ePortfolio: Fix Committed Status in Mahara 1.9 series: In Progress Bug description: If one is an institutional admin and they try to upgrade their site from pre 1.9 to 1.9+ they get this error Wed Aug 06 10:01:17.952987 2014] [:error] [pid 22070] [client 127.0.0.1:32941] PHP Fatal error: Uncaught exception 'SQLException' with message 'Failed to get a recordset: postgres7 error: [-1: ERROR: relation institution_config does not exist\nLINE 1: SELECT field, value FROM institution_config WHERE institu...\n ^] There was a change made in 1.9 relating to language settings and one of the things it does is try to set a cookie relating to the institution language last used. When one upgrades it logs them out as part of the process if they are logged in. And it tries to set their institution set language on logout in 1.9 getting info from the institution_config table (which does not exist at this point). The setting of that cookie needs to be wrapped in a check to make sure the table exists first. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1353153/+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 1349311] A change has been merged
Reviewed: https://reviews.mahara.org/3518 Committed: http://gitorious.org/mahara/mahara/commit/0efa9f973c72ad02ca76f76415af934bf2361628 Submitter: Son Nguyen (son.ngu...@catalyst.net.nz) Branch:master commit 0efa9f973c72ad02ca76f76415af934bf2361628 Author: Robert Lyon robe...@catalyst.net.nz Date: Tue Jul 29 09:37:09 2014 +1200 Be able to select all pages when adding to collection (Bug 1349311) The 'Add pages to collection' list needs an all/none option. Change-Id: I36e3ae4c5066e0963cb9da8f1b5a824c61de7d68 Signed-off-by: Robert Lyon robe...@catalyst.net.nz -- 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/1349311 Title: Enhancement - Select All option when adding pages to collection Status in Mahara ePortfolio: In Progress Bug description: When organising pages into collections it would be useful to have the option of 'select all', rather than having to tick every page individually (screenshot example). This would be particularly useful when setting up template pages within a group. I've recently created several large collections for use as templates or teaching resources, and as these were done sequentially the pages all appear together in the selection menu - but as you have to manually click 20+ boxes to select all of them it really feels like a simple 'select all' button would make life easier. Regards, Gordon. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1349311/+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 1353153] A change has been merged
Reviewed: https://reviews.mahara.org/3574 Committed: http://gitorious.org/mahara/mahara/commit/e96eee4c7a8738b074da8063fc67afa09a1bb6fe Submitter: Son Nguyen (son.ngu...@catalyst.net.nz) Branch:master commit e96eee4c7a8738b074da8063fc67afa09a1bb6fe Author: Robert Lyon robe...@catalyst.net.nz Date: Wed Aug 6 10:48:07 2014 +1200 Logout setting of cookie breaks upgrade from pre 1.9 to 1.9+ (Bug #1353153) If the user who is upgrading the site is logged into the site and is a member of a normal (not mahara) institution it causes the upgrade to break because the upgrade process tries to log them out and logout() function tries to set a cookie and the cookie needs info from the config_institution table and it doesn't exist yet. Change-Id: Ib8bb83fc1b774cec5636af6009ebf9906349bca3 Signed-off-by: Robert Lyon robe...@catalyst.net.nz -- 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/1353153 Title: upgrade to 1.9 error when logged in and belonging to an institution Status in Mahara ePortfolio: Fix Committed Status in Mahara 1.9 series: In Progress Bug description: If one is an institutional admin and they try to upgrade their site from pre 1.9 to 1.9+ they get this error Wed Aug 06 10:01:17.952987 2014] [:error] [pid 22070] [client 127.0.0.1:32941] PHP Fatal error: Uncaught exception 'SQLException' with message 'Failed to get a recordset: postgres7 error: [-1: ERROR: relation institution_config does not exist\nLINE 1: SELECT field, value FROM institution_config WHERE institu...\n ^] There was a change made in 1.9 relating to language settings and one of the things it does is try to set a cookie relating to the institution language last used. When one upgrades it logs them out as part of the process if they are logged in. And it tries to set their institution set language on logout in 1.9 getting info from the institution_config table (which does not exist at this point). The setting of that cookie needs to be wrapped in a check to make sure the table exists first. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1353153/+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 1331863] Re: Warning when adding an authentication plugin to an institution
** 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/1331863 Title: Warning when adding an authentication plugin to an institution Status in Mahara ePortfolio: Fix Committed Bug description: Version: master (1.10) Platform: any Browser: any I got the warning when adding an authentication plugin to an institution [WAR] ae (lib/mahara.php:1845) Argument 1 passed to Plugin::validate_config_options() must be an instance of Pieform, array given Call stack (most recent first): log_message(Argument 1 passed to Plugin::validate_config_optio..., 8, true, true, /home/sonn/code/mahara/master/htdocs/lib/mahara.ph..., 1845) at /home/sonn/code/mahara/master/htdocs/lib/errors.php:433 error(4096, Argument 1 passed to Plugin::validate_config_optio..., /home/sonn/code/mahara/master/htdocs/lib/mahara.ph..., 1845, array(size 0)) at /home/sonn/code/mahara/master/htdocs/lib/mahara.php:1845 Plugin::validate_config_options(array(size 7), object(Pieform)) at Unknown:0 call_user_func_array(array(size 2), array(size 2)) at /home/sonn/code/mahara/master/htdocs/lib/mahara.php:1584 call_static_method(PluginAuthBrowserid, validate_config_options, array(size 7), object(Pieform)) at /home/sonn/code/mahara/master/htdocs/admin/users/addauthority.php:114 auth_config_validate(object(Pieform), array(size 7)) at Unknown:0 call_user_func_array(auth_config_validate, array(size 2)) at /home/sonn/code/mahara/master/htdocs/lib/pieforms/pieform.php:1382 Pieform-validate(array(size 7)) at /home/sonn/code/mahara/master/htdocs/lib/pieforms/pieform.php:505 Pieform-__construct(array(size 5)) at /home/sonn/code/mahara/master/htdocs/lib/pieforms/pieform.php:162 Pieform::process(array(size 5)) at /home/sonn/code/mahara/master/htdocs/lib/pieforms/pieform.php:71 pieform(array(size 5)) at /home/sonn/code/mahara/master/htdocs/admin/users/addauthority.php:87 To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1331863/+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 1313963] Re: Pagination in Groups/Topics does not work
** 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/1313963 Title: Pagination in Groups/Topics does not work Status in Mahara ePortfolio: Fix Committed Bug description: Version: master (1.10) Platform: all Pagination in Groups/Topics does not work. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1313963/+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 1320006] Re: Show shared collections on the group homepage
** 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/1320006 Title: Show shared collections on the group homepage Status in Mahara ePortfolio: Fix Committed Bug description: Version: 1.8 and master This is a new feature (WR219566) is to show collections shared with the group instead of their individual pages and a paginator will be included to browse through the list of shared pages. 1. On the group homepage, collections shared by others with the group are displayed. They are displayed with the collection title and the collection author similar to the display of shared pages. 2. A paginator is available for each individual section (Group pages, Pages shared with this group by others, Collections shared with this group by others) for easy browsing through a long list of pages. 3. On the configuration screen for Group pages, the group admin can choose to display pages shared with the group (existing functionality). Only pages that are not in a collection are displayed (new functionality). 4. The group admin can choose to display collections shared with the group. 5. As there can be quite a number of pages or collections shared with the group or created in a group, the group admin can limit the number of displayed pages / collections. If the number of actual pages / collections exceeds this number, a paginator (see 2) will be displayed. A maximum of 100 pages / collections can be displayed on the homepage in each section before the paginator needs to be used. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1320006/+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 1267285] Re: Mahara 1.8 German langpack not updating
** Changed in: mahara Status: In Progress = 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/1267285 Title: Mahara 1.8 German langpack not updating Status in Mahara ePortfolio: Fix Released Bug description: Ralf Hilgenstock contacted me on mahara.org to let me know that the Mahara 1.8 German langpack isn't updating, although interestingly the master langpack is updating correctly. Anyway, we've had problems before with the script not updating the langpacks, and it looks like we've got problems again. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1267285/+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 1359531] [NEW] Artefact path is not being calculated correctly on file rename
Public bug reported: Discovered while doing some testing in files and folders ** Affects: mahara Importance: Medium Assignee: Yuliya Bozhko (yuliya.bozhko) 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/1359531 Title: Artefact path is not being calculated correctly on file rename Status in Mahara ePortfolio: In Progress Bug description: Discovered while doing some testing in files and folders To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1359531/+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 1359531] A patch has been submitted for review
Patch for master branch: https://reviews.mahara.org/3653 -- 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/1359531 Title: Artefact path is not being calculated correctly on file rename Status in Mahara ePortfolio: In Progress Bug description: Discovered while doing some testing in files and folders To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1359531/+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 1358092] Re: Improve SQL performance when deleting notifications
... so I've move it to 1.9_STABLE instead: https://reviews.mahara.org/#/c/3654 The original bug reporter said that removing the nested subqueries from that UPDATE statement improved performance from taking 1 minute to 1 second, which is a drastic enough improvement (with no front-end change) that it'd be worth distributing on a stable release as a bug 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/1358092 Title: Improve SQL performance when deleting notifications Status in Mahara ePortfolio: In Progress Status in Mahara 1.10 series: In Progress Status in Mahara 1.9 series: In Progress Bug description: Martin from Catalyst EU pointed out to me that the performance of the code in account/activity/index.json.php could be improved by stripping an unnecessary subquery from it. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1358092/+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 1358092] Re: Improve SQL performance when deleting notifications
In 1.10 this particular optimization becomes much less important, because the old message inbox is no longer used unless the site disables the new multi-recipient message inbox. Cheers, Aaron ** Changed in: mahara Status: New = In Progress ** Changed in: mahara Importance: Undecided = Medium ** Changed in: mahara Assignee: (unassigned) = Aaron Wells (u-aaronw) ** Changed in: mahara Milestone: None = 1.9.3 ** Also affects: mahara/1.10 Importance: Medium Assignee: Aaron Wells (u-aaronw) Status: In Progress ** Also affects: mahara/1.9 Importance: Undecided Status: New ** Changed in: mahara/1.9 Status: New = In Progress ** Changed in: mahara/1.9 Importance: Undecided = Medium ** Changed in: mahara/1.10 Importance: Medium = Low ** Changed in: mahara/1.9 Assignee: (unassigned) = Aaron Wells (u-aaronw) ** Changed in: mahara/1.9 Milestone: None = 1.9.3 ** Changed in: mahara/1.10 Milestone: 1.9.3 = None -- 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/1358092 Title: Improve SQL performance when deleting notifications Status in Mahara ePortfolio: In Progress Status in Mahara 1.10 series: In Progress Status in Mahara 1.9 series: In Progress Bug description: Martin from Catalyst EU pointed out to me that the performance of the code in account/activity/index.json.php could be improved by stripping an unnecessary subquery from it. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1358092/+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 1355572] Re: Blocktype JS includes not loaded correctly on https sites using subdirectory for wwwroot
** Description changed:
There are a few places which do this:
if (strpos($jsfile, 'http://' === false)) { ...
when they should do this:
- if (stripos($jsfile, 'http://' === false) stripos($jsfile, 'http://'
+ if (stripos($jsfile, 'http://' === false) stripos($jsfile, 'https://'
=== false)) { ...
the problem only reveals itself on https sites where the wwwroot is in a
subdirectory such as https://mysite/mahara/.
The result is that the URL to include files is wrong so the files aren't
loaded.
--
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/1355572
Title:
Blocktype JS includes not loaded correctly on https sites using
subdirectory for wwwroot
Status in Mahara ePortfolio:
New
Bug description:
There are a few places which do this:
if (strpos($jsfile, 'http://' === false)) { ...
when they should do this:
if (stripos($jsfile, 'http://' === false) stripos($jsfile,
'https://' === false)) { ...
the problem only reveals itself on https sites where the wwwroot is in
a subdirectory such as https://mysite/mahara/.
The result is that the URL to include files is wrong so the files
aren't loaded.
To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1355572/+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 1359531] Re: Artefact path is not being calculated correctly on file rename
** Description changed: Discovered while doing some testing in files and folders + + To reproduce: + + 1. Get fresh install. + 2. Login as admin + 3. Click content files + 4. Add a folder f1 + 5. Enter folder + 6. Add a subfolder f2 + 7. Edit f2, rename to folder2 + 8. In SQL client run: SELECT id,path from artefact; + + The subfolder's path should be something like '/5/7' but instead it's + '/5/5/7'. + + It is quite important to fix as permissions to view artefact ancestors + are calculated from the path. I checked and this happens only when + files/folders are renamed as constructor is missing $oldparent property + which is no supplied from the DB. -- 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/1359531 Title: Artefact path is not being calculated correctly on file rename Status in Mahara ePortfolio: Fix Committed Bug description: Discovered while doing some testing in files and folders To reproduce: 1. Get fresh install. 2. Login as admin 3. Click content files 4. Add a folder f1 5. Enter folder 6. Add a subfolder f2 7. Edit f2, rename to folder2 8. In SQL client run: SELECT id,path from artefact; The subfolder's path should be something like '/5/7' but instead it's '/5/5/7'. It is quite important to fix as permissions to view artefact ancestors are calculated from the path. I checked and this happens only when files/folders are renamed as constructor is missing $oldparent property which is no supplied from the DB. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1359531/+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 1359531] Re: Artefact path is not being calculated correctly on file rename
** Changed in: mahara Milestone: None = 1.10.0 ** Changed in: mahara Status: In Progress = Fix Committed ** Tags added: regression -- 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/1359531 Title: Artefact path is not being calculated correctly on file rename Status in Mahara ePortfolio: Fix Committed Bug description: Discovered while doing some testing in files and folders To reproduce: 1. Get fresh install. 2. Login as admin 3. Click content files 4. Add a folder f1 5. Enter folder 6. Add a subfolder f2 7. Edit f2, rename to folder2 8. In SQL client run: SELECT id,path from artefact; The subfolder's path should be something like '/5/7' but instead it's '/5/5/7'. It is quite important to fix as permissions to view artefact ancestors are calculated from the path. I checked and this happens only when files/folders are renamed as constructor is missing $oldparent property which is no supplied from the DB. To manage notifications about this bug go to: https://bugs.launchpad.net/mahara/+bug/1359531/+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
