Hi Aaron,
Certainly that's one way of looking at it, but I think it would be
better to simply display a message at the top of the page to inform the
user that the other group members had been sent a notification. I think
sending a notification to the owner of the page being shared could
It seems to be a combination of both of those things. I think users are
generally quite happy to receive notifications as long as they're
relevant and useful (and not confusing), and rewording the notification
as suggested would certainly help to improve that.
However, I still think it would be
Public bug reported:
Group members should receive a notification whenever a new group page is
created, just as they currently do when a member shares one of their own
pages with the group (provided that 'Shared page notifications' is
enabled for the group).
** Affects: mahara
Importance:
Public bug reported:
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
I'd be quite happy to work on this issue if one of the core developers could
just give me a bit of advice as to how best to proceed, e.g.
- Is there a legitimate reason for the data being stored in two places or was
this an oversight?
- Does it need to be updated in both places too, or should it
Verified that this is still an issue in Mahara 1.9.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
Public bug reported:
Currently if a user wants to edit their dashboard page they have to go
to the 'Portfolio' tab and click the appropriate edit button there,
which is not particularly intuitive.
This patch adds an 'Edit dashboard' button to the home page itself, and
also returns the user to
Public bug reported:
There are a few places in Mahara where usernames are displayed to
ordinary users (e.g. user/find.php and user/online.php). This may be a
privacy issue for sites where email addresses are used as usernames.
This patch adds a site option enabling the admin to prevent usernames
Thanks Kristina. So does that mean that the $username parameter of
display_name() is redundant, or that the original logic was incorrect? In other
words, should the username always be displayed for admins and staff, or only
when $username is true?
The original logic,
$addusername = $username
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
I've added another commit to this issue, after receiving a report from a
student that notification emails were displaying the sender's username
anyway.
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions:
OK, the text table obviously didn't work out so I've attached the
original spreadsheet. ;-)
** Attachment added: results.ods
https://bugs.launchpad.net/mahara/+bug/1353516/+attachment/4306488/+files/results.ods
--
You received this bug notification because you are a member of Mahara
I get completely different results for these tests, which I've
summarised below (thanks to http://www.tablesgenerator.com/).
These are exactly the results I would expect, logged in as a normal
(student) user, searching for another normal user who has set a display
name and a preference to hide
Thanks for reviewing Aaron. I've addressed the points you raised (the
de-duping code was in there already).
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
Thanks for the feedback Aaron.
I've added a commit which consolidates these two options into one,
hopefully resolving the inconsistencies you mention above. If usernames
are not displayed, Clean URLs for profile pages will be generated using
the preferred name if one is supplied, or the real
Sorry Kristina, I don't really have time at the moment. To be honest I'd
forgotten all about it. Is it still an issue?
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara
Thanks Kristina, but I'm afraid I just don't have the time to look into
it at the moment.
--
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
+1
--
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: mahara-contributors
https://bugs.launchpad.net/bugs/1939962
Title:
Password for Redis server cannot be configured
Status in Mahara:
Triaged
Bug
18 matches
Mail list logo
