08:01:09 #startmeeting 08:01:09 Meeting started Thu Dec 5 08:01:09 2013 UTC. The chair is aarow_laptop. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:02:21 I'd like to start the meeting as we always do by asking everyone to introduce themselves, preceeding it with #info so it'll show up in the minutes 08:02:26 #info anitsirk is Kristina Hoeppner, Catalyst IT, Wellington, NZ 08:02:33 #info dobedobedoh is Andrew Nicols, Moodle Pty Ltd, Perth, Australia. 08:02:35 #info sonn_ is Son Nguyen, Catalyst IT, Welllington, NZ 08:02:40 #info anzeljg is Gregor Anželj, developer and translator, Ljubljana, Slovenia 08:02:50 #info aarow_laptop is Aaron Wells, Catalyst IT in Wellington 08:02:53 #info mingard is Jono Mingard, newly of Catalyst IT, Wellington, NZ 08:03:23 #info robertl_ is Robert Lyon, developer, Catalyst IT, Wellington, NZ 08:03:29 Hi ghada, we were just doing introductions. Please introduce yourself, preceeding it with #info so you'll show up in the auto-generated minutes 08:03:53 #info #me is Tobias Zeuch, developer at the KIT, Karlsruhe, Germany 08:04:01 #info /me is Tobias Zeuch, developer at the KIT, Karlsruhe, Germany 08:04:15 #info ghada is Ghada El-Zoghbi, developer, Catalyst IT, Sydney, Aus 08:04:18 #info tobiasz is Tobias Zeuch, developer at the KIT, Karlsruhe, Germany 08:04:29 tobiasz: what is the KIT? Karlsruhe Institute of Technology? 08:04:47 yep 08:04:49 whoops, I got disconnected for a few seconds there 08:04:50 For those interested, the live minutes are at http://meetbot.mahara.org/mahara-dev/2013/mahara-dev.2013-12-05-08.01.log.txt (if you want to find out who people are and missed it) 08:05:09 just what I needed :) 08:05:55 Well, is that everyone who's actually present and not just leaving their IRC signed in 24/7? ;) 08:06:09 aarow_laptop: i think so 08:06:18 okay, then 08:06:28 #topic Items from last meeting: The "Choose a skin" contest 08:07:07 anitsirk, I think you ran the contest, do you have want to say anything about it? 08:07:31 ehm. nope. not much. don't know why you put it on the agenda. ;-) just a few words then I guess: 08:07:59 I think at the last meeting (two months ago) it was still a proposal, and it got bumped to "discuss at next meeting" 08:08:28 It was the first time that we ran a competition that robertl_ and aarow_laptop had come up with. it was great because we got some people to submit skins using anzeljg's new feature. 08:08:37 the contest did help find a bug or two in skins so that was useful 08:08:51 it was great to see what users had come up with and also see the power of the skins and that you can create some pretty cool stuff. 08:09:21 and was good to see how mahara folks would use it 08:09:25 and it showed us that we didn't have a very convenient central place for people to share skins 08:09:38 the hidden goal was to get users to test the feature, but it was also good to garner interest in this feature. 08:09:50 the main "complaint" when creating skins was to add support for choosing menu colors 08:10:08 anzeljg: which menus? 08:10:18 which are shown on page 08:10:22 the topnav you mean? 08:10:25 yep 08:10:29 oh, right 08:11:05 #info The contest was a success at locating bugs during the RC stage, and raising interest in skins 08:11:30 #info One reported oversight is the inability to set the color of the topnav 08:12:05 Oh yeah, we wound up turning on the ability to attach XML files to wiki.mahara.org, and I think that's where we're telling people to post skins they want to share 08:12:18 wasn't it zip files? 08:12:37 maybe it was zip files 08:12:42 https://wiki.mahara.org/index.php/Page_skins 08:12:57 many people have also just hosted them as files in their mahara.org accounts 08:13:00 afaik we turned on zip files and pdfs 08:13:09 #info we've set up a skins sharing page on the wiki: https://wiki.mahara.org/index.php/Page_skins 08:13:33 okay, if there's nothing else about skins, we'll move on to the next topic 08:14:06 oops. and there we lost him again. 08:14:15 whoops, disconnected again 08:14:21 I seem to be having some technical issues tonight 08:14:52 #topic Dropping support for MySQL 5.1, as of Mahara 1.9 08:15:44 I want to drop support for MySQL 5.1 in the next release, since 5.5 has been out for 4 years now, and our devs aren't actively testing on 5.1 anymore anyway 08:15:52 with the increased reliance on triggers / procedures mysql 5.1 isn't going to cut it 08:16:11 does it have different trigger & procedure syntax? 08:16:15 Also, support for 5.1 (Oracle) has stopped. 08:16:37 It has different permisisons. 08:16:53 so hopefully potential clients will no longer be running 5.1? 08:16:58 What's the version bundled in major distros? 08:17:01 It's been "streamlined" and a new permission has been added just for triggers. 08:17:18 not sure... 08:17:20 debian & Ubuntu come with 5.5 I believe 08:17:30 ubuntu 12.04+ come with 5.5 08:17:33 Wheezy = 5.5 08:17:44 We can't drop support if major distros are still using 5.1 IMHO 08:17:46 that sounds right. Three months ago I installed Ubuntu and it's 5.5 08:17:49 So DeadRat? 08:17:59 http://packages.debian.org/wheezy/mysql-server 08:18:31 CentOS seems to still bundle 5.1 08:18:55 but we don't officially support centos 08:18:57 http://mirror.centos.org/centos/6/os/x86_64/Packages/ 08:19:04 We don't officially support any OS do we? 08:19:29 the mahara registration information isn't helpful at all. for postgres it says "postgres7" though i'm running 9.1 if i'm not mistaken. 08:19:58 https://wiki.mahara.org/index.php/System_Administrator%27s_Guide/Requirements 08:20:03 whoops, disconnected again 08:20:16 says we officially support debian and ubuntu 08:20:21 Hm, when did that come in?!? 08:20:23 aarow_laptop: are you using the web client? 08:20:32 no, I'm using xchat. maybe I should switch, though 08:20:43 robertl_: but we don't do debian packages at the moment. 08:21:05 well, our support in that sense means that we will actively work to make it run on Debian 08:21:14 albeit now, by manually installing it 08:21:18 whishlist: centos would be nice... 08:21:20 right 08:21:45 I go for CentOS 08:21:54 Personally, I'm a Debian user, but I think we should consider the CentOS users too. 08:22:17 hm, it's an interesting point 08:22:18 can we leave that discussion to another topic / time and focus on mysql, please? ;-) 08:22:33 anitsirk: They're intrinsically linked. 08:22:36 according to the wiki we support ubuntu 10.04, which doesn't have mysql 5.5 afaik - that would need to be updated if we switch 08:22:44 Ditto for Lenny 08:23:06 okay, let's do this 08:23:17 take a look at the major distros & their versions 08:23:23 and see what MySQL versions they support 08:23:29 is there any (statistical) data about the systems people are installing mahara on? 08:23:50 Might be wise to sk Partners too aarow_laptop 08:23:52 Let me check the "phone home" data 08:24:21 aarow_laptop: it's not useful for postgres as it only says postgres7. doubt it's acurate for mysql. 08:25:41 another way to look at it, though, is that the "supported systems" is also a reflection of which systems are we actually testing it on 08:26:19 and in point of fact, at Catalyst NZ these days we're just testing it on Ubuntu with Postgres 9 & MySQL 5.5 08:26:42 Same in Catalyst, Australia 08:26:50 the devs certainly are 08:27:05 I think if we got some automated testing set up, then it would be more feasible to run those automated tests on other distro's 08:27:08 the testers branch out a bit more with OS / devices 08:27:22 We'd need to write some phpunit tests... 08:28:03 okay, so I think we can summarize this topic 08:28:27 We should get a look at which OS's & versions we'll be cutting off if we drop support for 5.1 08:28:46 and... well, I guess that's the main action item 08:29:01 #action We should get a look at which OS's & versions we'll be cutting off if we drop support for 5.1 08:29:06 thanks anitsirk 08:29:17 now we just need someone to attach to the action item :-) 08:29:24 aarow_laptop_: you'll need to rename to attach items ;) 08:29:31 oh 08:31:11 #action also, note that if we can specify 5.1.6 at least, we'll make things easier for ourselves 08:31:28 Okay, next topic 08:31:36 #topic Plans & priorities for Mahara 1.9 08:31:38 aarow_laptop: wait 08:31:50 who is going to find out? 08:31:55 oh :) 08:32:13 I will do 08:32:18 thanks sonn_ 08:32:47 #action sonn_ will look at which OS's & versions we'll be cutting off if we drop support for 5.1. 08:33:10 so, moving on the 08:33:18 #topic Plans & priorities for Mahara 1.9 08:33:47 #info It's not looking to be as big and exciting of a release as 1.8 08:33:53 there must be something in the nz air. i got dropped off the channel as well. :-( 08:34:36 #info We've got mingard working on accessibility 08:35:29 #info And I'd really like to upstream the improvements to sent messages and notifications being developed by tobiasz 08:35:30 seems to me that we can get A level accessibility quite easily, possibly AA as well before release 08:35:41 but I need to do more research into exactly what will be involved 08:35:45 good to hear 08:35:54 The text editor will get in your way there 08:36:27 tinyMCE? 08:36:29 TinyMCE is non-compliant 08:36:37 We're going through that atm 08:36:45 at Moodle? 08:36:48 Yup 08:37:07 We're looking at replacing TinyMCE 3.5; 4.X is better, but still not great 08:37:18 might work just having an option to turn it off 08:37:27 but I'm not sure where that should go 08:37:34 mingard and our accessibility expert are working on reviewing mahara for accessibility issues so that we can get a good overview of where work would be necessary. we'll then have a good picture of the pain areas and those that could be fixed more easily. we may not be able to address all issues at once, but at least we'll know where work would be needed. ideally, we'll also get some funding for improving the accessibility. if anyone knows of 08:37:48 possibility to tap into, please let us know. 08:38:37 mingard: Well, we could add a "screenreader compatibility" setting to the account settings 08:38:47 mingard: you can already do that at the moment under user settings :-) 08:38:55 oh, that too 08:39:01 you can actually turn off the wysiwyg editor 08:39:10 ok, I'll look into it 08:39:21 maybe just some more explanation that screen reader users should do this 08:39:34 i thought that's what moodle was doing as well. 08:39:48 also note so far we've only really looked at viewing things (not editing) so edit functionality may need a lot more work 08:40:00 perhaps if we wind up with a list of things like that, we could put together a page in the Mahara manual or something, about how to optimize your Mahara experience for accessibility 08:40:19 yes :) 08:40:28 good idea, I'll bear it in mind 08:40:32 We're trying to make everything ARIA compliant, everywhere with a view to dropping the screenreader setting 08:40:53 So that there's only one interface, and it's an accessible one. 08:41:04 we were definitely planning on creating bugs for the issues and also having some information on the wiki in regards to overall accessibility because we've been asked this question in the past / recently. 08:41:30 dobedobedoh: that's a great approach. 08:42:13 agreed, ideally we'll also use it 08:42:42 well, shall we move on to the next bit? 08:43:26 so, there was accessibility 08:43:35 any action required? 08:43:55 Well, mingard's already working on accessibility 08:44:07 so no further action I think :) 08:44:31 ok, shall I update at the next meeting 08:44:33 ? 08:44:54 The next thing in our 1.9 plans, was to get in the improvements to the "sent messages" and inbox 08:45:13 which I believe both tobiasz and another developer on the forum are both working on different versions of 08:45:18 auto testing? 08:45:27 mingard: good idea. 08:46:02 tobiasz, I've been meaning to look at your patch, I'll try to get to that asap 08:47:36 I also put "automated testing" on the agenda, but that's more of a wishlist item than a likelihood. However, the folks at Totara seem to finally be starting on their Mahara-related project, and they're pretty big on automated testing, so I'm hoping we can get them to do some work towards writing some tests for Mahara 08:48:18 or at least settle on a good test framework that we can use 08:48:21 aarow_laptop: ok, I'll wait for your comments. It's programmed as a pure plugin so far but we can integrate it into the core. Just wanted to see what you (all) think about the implementation, first 08:48:42 #info Automated test, would be great, but outlook uncertain at the moment 08:48:56 Okay, next item 08:49:04 #topic: Features funded by Arnes which could go into 1.9 08:49:09 We already have a test framewrok 08:49:11 anzeljg? 08:49:14 tobiasz: we were thinking of going over the discussion you had with angela again and see if maybe a combo of your work would be a good idea as she also had good points. 08:49:15 But no-one has ever written any tests for it 08:49:41 It seems that two parallel conversations are going on. 08:49:48 dobedobedoh: yep, the framework isn't so much the problem, it's the tests 08:49:49 Shall I wait for couple of minutes? 08:49:55 yeah. we aren't quite finished with the previous topic. ;-) 08:49:59 oh, sorry 08:50:04 I think I may have had some lag there 08:50:04 Please undo ;) 08:50:08 #undo 08:50:08 Removing item from minutes: 08:50:45 As I say, we already have phpunit implemented. It's Mjollnir`'s code which I sponsored and had integrated 08:50:58 Unfortunately I then changed employ and haven't done as much mahara dev since and no-one else has written any tests either 08:51:08 but the basis is there 08:51:30 does totara also use phpunit? 08:51:35 Moodle does 08:51:41 And since Totara == Moodle 08:52:56 I'm actually more interested in setting it up to some behat testing, front-end stuff 08:53:05 which Moodle also does these days 08:53:11 Indeed so 08:54:01 that's where we got the idea from ;-) 08:54:03 we've even had some training with the Catalyst QA team to prepare them to write gherkin tests (for Moodle) 08:56:14 #info extending mahara with tests (unit tests but also behat) is high on the wishlist as it would facilitate regression testing, compatibility of new code etc. 08:57:35 okay, next topic? 08:57:36 and compatibility of 3rd party plugins. I'd highly appreciate the tests 08:59:20 #topic Features funded by Arnes which could go into 1.9 09:00:05 anzeljg? 09:00:06 The first three will be funded by Arnes, about hte last the conversation is still going on... 09:00:14 1. Dinamical "Progress bar" based on Institution selected preferences 09:00:15 oh, sorry 09:00:26 The idea is to take my "Progress bar" plugin, which has static set of artefacts that it observes and based on those artefacts it alculates the Profile completeness. The plugin could be extended in a way to implement page/dashboard for institution admins which would list all available artefacts and the admins would select which artefacts should count towards Profile completeness for their institution. Would it also be a good idea to 09:00:45 of those artefacts? To explain a little bit: select/drop-down box with options from 0 to e.g. 5 where that number would mean the occurance of each artefact type (0 = artefact does not count toward Profile completeness, 5 = 5 artefacts of that type count toward Profile completeness but user could also add less than 5 artefacts) 09:00:53 .. 09:01:19 Sorry, I meant do anyone has comments before I move on to number2 ? 09:01:37 I like the idea of a profile progress bar :) 09:02:24 anzeljg: do you have a screenshot or reference site? i remember having it seen somewhere. 09:02:40 I'll try to find it... 09:02:48 me too - it gives new users a task to complete 09:02:52 i also like the idea of an admin (institution admin?) being able to select which items count towards completeness. 09:03:01 so do I. Not sure how sophisticated the config needs to be (would be quite nice to have a number input ...) 09:03:33 #idea The idea is to take anzeljg's "Progress bar" plugin, which has static set of artefacts that it observes and based on those artefacts it alculates the Profile completeness. The plugin could be extended in a way to implement page/dashboard for institution admins which would list all available artefacts and the admins would select which artefacts should count towards Profile completeness for their institution. 09:04:40 anitsirk: the article was published in las newsletter, but the link https://mahara.org/newsletter doesn't work 09:05:02 anzeljg: it does work for me. 09:05:23 strange... anyway there should be a screenshot 09:05:25 sorry that i forgot that it was in the newsletter 09:05:34 and yes, there is a screenshot. 09:05:43 :) 09:06:00 yep, I see, looks good from the screenshot at least 09:06:35 so when task are completed do they disappear from list? 09:06:44 when it's completed maybe we could discuss implementing it into core, if you wish? 09:06:49 robertl_: yes 09:06:56 cool 09:07:12 would that require that the dashboard is made more flexible, i.e. the admin can decide which blocks to place on the dashboard? 09:07:46 Indeed, it seems like this is a feature that would make the most sense if an admin could have it automatically show up in the default dashboard 09:07:53 i'm not sure. currently i've made it so that for existing and new users the block is added to position 0 at right column... 09:08:02 #info the proof-of-concept around the progress bar plugin and a screenshot can be seen in the Mahara Newsletter, October 2013 https://mahara.org/view/artefact.php?artefact=292431&view=36871 09:08:28 but it would only make sense to have if the admin configured some sort of completion. 09:08:31 aarow: yes it shows at default dashboard, for current and new users 09:08:48 anitsirk: wha do you mean? 09:09:07 and the user can remove it from their dashboard if they wish? 09:09:24 ghada: haven't tested that - i think so 09:09:25 if an admin doesn't want to have a progress bar show up on the dashboard, it should not be placed there by default for existing and new users. 09:09:35 removing it should also be possible like for every other block. 09:09:36 anitsirk: i see 09:10:17 I see, the block has a postinst() method which adds it to all the existing dashboards, and to the default dashboard template 09:10:33 is it listed in the blocks menu? how does the user get it back if they remove it by accident? 09:10:41 anitsirk: so there should be a setting in plugin settings to allow admin to swithc plugin on/off? 09:10:54 i thought that turning the plugin off is enough 09:11:02 Yeah, that would do it 09:11:27 mingard: Yes, the block is set so that a user could re-add it to their Dashboard page if they remove it 09:11:40 ok, just checking 09:11:58 so, not like the homeinfo? 09:12:04 then i think there should be some sort of help before turning it on though esp. when it places a new block on a person's dashboard. normally, we do not touch existing pages and add things or change things as users can customize them to their liking. 09:12:16 true 09:12:20 ghada: homeinfo is different from blocks. 09:12:33 well, we'll need to give some thought to the automated placement thing when upstreaming it 09:12:40 agree 09:12:41 homeinfo is a template that the admin controls whereas the rest of the dashboard blocks is user controlled though we have default blocks there. 09:12:47 yes, but the mechanism to switch it off is in the user settings also. 09:12:54 I think the most logical thing (and kind of a missing bit of Mahara functionality anyway) would be to let admins configure the default Dashboard page 09:13:15 +1. but that would need to be done on institution level 09:13:15 currently you can do that with a hack, by logging in as the root user 09:13:38 that is the hack, i've used :) 09:14:10 ghada: Yeah, homeinfo is not actually a block. Although it could make sense to display the profile progress in a similar, non-Block fashion 09:14:10 on the other hand, we've already got it fully implemented as a Block :) 09:14:44 but configuring the dashboard page doesn't help when you introduce the plugin into a running system/with existing user accounts 09:15:16 correct, changes to the default dashboard would only affect new users 09:16:02 there's no way to have some sort of installation wizard for the plugin with an option to update existing users' dashboards? 09:16:34 #idea Add an interface for site & instititution admins to customize the default dashboard page 09:16:39 that's why the plugin currently updates the default dashboard (for new future users) and also dashboards of every exisitng user 09:16:42 that would be some might sql wranglings... 09:16:43 #idea Put the profile progress into a non-Block similar to homeinfo 09:17:00 mingard: normally, we don't touch users' existing pages as they could have highly customized them. 09:17:31 actually it wouldn't be too hard for admins to customize the default dashboard page 09:18:00 I see. having it set up like homeinfo makes sense to me, it's not the sort of thing you would want to add to multiple pages for example 09:18:01 it's stored as a normal page in the DB 09:18:01 it just belongs to the usually inacessible "root" user 0 09:18:02 if you give the "root" user a password, you can log in as them and edit it already 09:19:04 okay, well, not to shut down the discussion, but we are running a bit late, so I suggest we move on to the next item of anzeljg's :) 09:19:13 where do you set a plugin to be non-Block? 09:19:28 anzeljg: i don't think you can do that. 09:19:45 ok we'll discuss that later, over email or sth... 09:19:46 anzeljg: There's no plugin type for it. So, it's something we'd have to hard-code 09:19:59 2. "Cookie directive" plugin, possibly merged into core 09:20:00 ... or invent a plugin type 09:20:12 #idea "Cookie directive" plugin, possibly merged into core 09:20:12 The plugin is already implemented, you can see it in action at #link http://listovnik.sio.si (bottom right side of page - "Nastavitev zasebnosti" = "Privacy settings"). It should be noted that plugin works with $cfg->additionalhtmlhead setting, so it only works in Mahara 1.8 or newer. 09:20:19 Also there is an issue with language support - the language strings are written as a part of javascript which is written to $cfg->additionalhtmlhead setting. 09:20:28 It is possible for admin to select appropriate language when applaying settings for the plugin, but the language strings don't update dinamically - if the site supports several languages and user dinamically changes the language then that language change is not reflected, the plugin still uses the language that was set in plugin settings in admin area. 09:20:29 .. 09:20:32 This gets a high +1 from me because it is necessary for european sites. 09:22:05 anzeljg: If we incorporate it into core, then it won't have to be sent via $cfg->additionalhtmlhead, and that should help resolve the language string issues 09:22:36 this should be a site admin check box. 09:22:51 no institution setting necessary because the entire site is affected. 09:23:32 anitsirk: you've lost me, what should be a site admin check box? 09:23:43 arrow: nice 09:23:47 whether to set the cookie directive or not 09:24:15 the admin shouldn't have to change something on the server, but just tick a box and say whether they require the directive or not 09:24:46 Am I correct in assuming that what this feature does, is implements compatibility with this: http://en.wikipedia.org/wiki/Directive_on_Privacy_and_Electronic_Communications ? 09:25:00 #info rkabalin is Ruslan Kabalin, Lancaster University, UK. 09:25:17 anitsirk: ther'e more to is, since the colors etc. could be dinamically changed and also the consent mode, etc. 09:25:33 hi rkabalin 09:25:33 but yes, the for for the admin to set all the stuff 09:25:51 aarow: yes 09:25:58 in EU it's mandatory! 09:26:46 (I'm skimming the simpler explanation at http://www.theeucookielaw.com/ ) 09:26:48 sorry: for for = form for ^^^ 09:28:21 yep, sounds like something it would be good to include 09:28:57 anzeljg: will need to read up on how dynamic the colors etc. would have to be. i could imagine to have them in the theme css. but that's a detail discussion for later. 09:29:13 OK 09:29:14 I imagine a lot of European Mahara sites will be quite happy 09:29:17 moving on? 09:29:27 :) 09:29:58 yep 09:29:58 3. Social site addresses in user's profile 09:30:08 Actually the bug #link https://bugs.launchpad.net/mahara/+bug/605749 contains (in my oppinion) two separate issues. 09:30:12 #idea Social site addresses in user's profile 09:30:25 The first one is to add support for social site addresses to user's profile. My idea is to implement it in a sort of the same way that the user's emails are implemented. 09:30:32 The users will be able to add multiple addresses with a form (or maybe Pieform element) which will offer them a select/drop-down box with XY most used social websites so they will first select a social site/service and than in another textbox type/insert their personal address, e.g. http://twitter.com/johndoe or http://facebook.com/johndoe or http://en.linkedin.com/in/johndoe/ 09:30:44 Second issue is on General tab. "Occupation and Industry do not make a lot of sense, especially when portfolios are used in schools for students. It would be good if the admin could change these labels for an institution." 09:30:52 The new Europass HeadlineTypeLabelType element contains one value from predefined set of values: preferred_job, job_applied_for, studies_applied_for, position or personal_statement. We could support at least that or also add our own. I'm just not sure how to do that. Any suggestions? 09:30:53 .. 09:31:50 yes, that Launchpad bug contains basically two separate items 09:31:57 Multiple sources have asked me for the ability to customize the Profile fields, I think it would make a lot of sense 09:32:08 hello dajan 09:32:09 dajan hi 09:33:02 hi there. Sorry for being (very) late. Was kidnapped in another conf early this morning. 09:33:04 I also suggested customisable profile fields to the Totara team as something they might want to implement, since they've added "custom fields" to nearly everything in Moodle 09:33:56 luckily, we're still going ;) 09:34:27 We're on item 3.3 on the agenda ( https://wiki.mahara.org/index.php/Developer_Area/Developer_Meetings/29 ) 09:34:46 actually 3.2.3 09:34:47 so anzeljg, you're mostly focused on doing the first bit of that Launchpad bug, the multiple social site addresses; rather than fully customisable profile fields 09:34:47 ? 09:34:49 I think there are individual profile fields in moodle (created by the site admin) 09:35:20 oh, right 09:35:21 3.2.3 09:35:44 not sure. the social site addresses for sure... 09:35:45 anyway, yes, ideally most of the profile fields would be customizable. The social network fields are kind of embarrassingly out of date at this point, so even just making those more flexible would be great :) 09:36:40 #info the wishlist item for the social sites in the profile has been updated: https://bugs.launchpad.net/mahara/+bug/605749 09:36:40 we'd just need to make sure to have an upgrade script that converts the old-style hard-coded ones into the new-style flexible ones 09:36:46 and the approach for adding them similarly as emails would work? 09:37:01 #info there is a new wishlist item for changes to the "General" tab at https://bugs.launchpad.net/mahara/+bug/1258067 09:37:02 Well, presumably without the verification step 09:37:33 but in general, I think re-using the interface from the emails, would probably work 09:37:36 I menat, the users would select the site/service and enter the address :) 09:37:47 i think it would be better to just insert the username and then have the system add the rest of the url. 09:38:18 anitsirk: +1 (I wish I would think about it sooner) 09:38:18 well, I'm of two minds about that 09:38:26 aarow_laptop: why would we need to verify the urls / usernames? 09:38:30 wouldn't that make it too complicated? 09:38:31 on the plus side, it's perhaps an easier user experience if we just have them enter the username 09:38:31 Note that it is already easy to change the name of the profile field by adding a customized langpack into the local folder 09:38:34 we don't do that for the other urls that a user can insert 09:39:06 on the down side, if we have them just enter the username and we generate the URL, then we need to include a pre-set list of social networks and the ability to generate their URLs 09:39:15 dajan: yes, but if a user moves, they are back to the original or some other... 09:39:36 aarow_laptop: true. 09:39:37 or, we could include something similar to the iframe list, and let admins customize the list of social networks 09:40:16 aarow: i like your last idea 09:40:37 +1 to that idea 09:40:38 have you actually implemented anything on this yet, anzeljg? 09:40:46 That's right. Then the process of doing that will imply to save the info with the name of the field into the database. 09:40:59 it would need to be exportable (like the licenses). 09:41:00 but what happens when exporting user's portfolio 09:41:24 aarow: no implementation yet, just a lot of thinking about it... 09:41:40 anzeljg: look at the license implementation. when you export a portfolio that has license information then that is retained even if the new site doesn't have that license (as far as i know). 09:41:41 oh, okay :) 09:41:42 hm, exporting... 09:42:05 anitsirk: will do 09:42:06 well, maybe you'd need to have an "Other" option, that lets the user supply the name of the social network and a URL 09:42:20 aarow: though of that one also :) 09:43:28 if we have that (that the users could select from list of preentered sites or add their own) then I think we don't need admin interface similar to iframes... 09:44:00 It does make the admin page less necessary 09:44:05 the site/service should then be written to DB along with the url 09:44:36 the admin page is a kind of future-proofing, in case all the devs are too lazy to keep the list up to date 09:45:00 I see :) 09:45:18 And why not having an interface such as the one we actually use to add files to profile's info. Therfore the user is in charge of creating what he wants in the quantity he wants. He will have a field to choose the service and another one to provide his identity. A plus sign will let him to add a new one a minus sign to delete one. When I am writing "he" I also mean "she" 09:45:55 that was initial idea (like adding emails) 09:46:30 but the problem is what if the service is not on the list... 09:46:31 yeah, I think for consistency across the user profile area, making it similar to the Emails interface is good 09:47:02 but without the verification step i would say. 09:47:09 of course 09:47:32 In your experience: do you think that admin will want to control what kind of services the users will provide info about? 09:47:33 will the visiblity of the individual item be granular? or are you going to make all of them visible? I can't remember what we do with emails now... 09:47:34 but wouldn't we then have to change the existing site where you ahve the text box for entering usernames? 09:47:38 +1 for emails interface 09:47:58 ghada: you can decide which item to display and which one not to 09:47:59 Personally, I think it would be good enough to just give users two text fields, one for the name of the social network, and the other for their URL or username 09:48:30 yeah that's what I'm thinking 09:48:33 I agree with arron 09:49:03 so we leave it to users to enter e.g. Twitter or twitter or Facebook or facebook or FB or ... 09:49:23 then it would have to be the url i would say because users expect to get a link esp. when it's linkedin, twitter etc. they don't want to copy and paste the user name at the end of a url... 09:49:27 and just store it as field1=field2 pairs 09:49:58 there are some antiquated social networks, such as AIM, where you don't have a URL 09:50:30 I guess the downside to making it freetext is that you would get irregularity in the results 09:50:40 so the description would say: "paste the URL or username" 09:50:49 what about trying to fetch the site-icon like mahara does with the allowed iframe sources, instead of a name for the network? 09:51:10 potential for malicious users to have links to dodgy sites? although the site icon would help with that 09:51:27 or do we trust our users/administrators? 09:51:35 and that again takes us to set of predefined addresses 09:51:38