Talk:Module visibility and display

UCLA is very excited about this feature. Currently we are using a patch that we call public/private (http://moodle.org/mod/data/view.php?d=13&rid=2768) to accomplish this functionality.

This proposed feature would remove the need to maintain our customized code.

Additionally, allowing the developers to add custom editing icons next to resources/activities without modifying core moodle is an excellent idea! --Nick Thompson 17:37, 15 December 2010 (UTC)

---

+1 from me.--Tim Hunt 18:39, 15 December 2010 (UTC)

A few comments

1. the modinfo could be a class with extra methods for the new stuff - instead of precalculating everything we could do the extra work only when necessary, it should be 100% compatible with current code and it could actually detect some parameter problems; another reason is there is no proper phpdocs which prevents autocomplete from working in IDEs
2. icon and iconcomponent are supposed to be the new api, the mod/mymodule/iconname hack should be deprecated instead
3. at the same time we should fix the known perf problems with the modinfo caching

Alternative proposal:

• create new interface module_info which is backwards compatible with old $cminfo, add hidden setting which specifies which class to use
• keep get_fast_modinfo() and make it return array of instances with module_info interface
• either use plugin_supports() for finding out if plugin contains view.php (false means no url, true default) - external urls and nonstandard urls are supposed to be implemented via view.php redirects such as in the mod/url
• or simply check if mod/xx/view.php exists (did we ever consider this solution?)
• all course page specific data could be initialised/computed only when necessary

Benefits could be a bit better performance, smaller course->modinfo and finally all the customisation could be done via modification/replacement of one class only.

--Petr Škoda (škoďák) 16:56, 19 December 2010 (UTC)

Can this be used to create public/private course sites?

I'm not following all of this, but want to ask if this change would allow either of the following:

1. Guests can see course site, but certain resources or activities are invisible (and unavailable) unless logged in and enrolled in that class. (This is the purpose of UCLA's public/private customization mentioned by Nick Thompson above. We do this through Groupings and defaulting the course to public.)

2. Guests can NOT see the course site, but CAN access specific resources or activities if they've been marked as public and they have a URL to get there. (This is not how UCLA's is set up, but conceivably might be useful in certain situations.)

--Mike Franks 21:30, 22 December 2010 (UTC)

Yes Please

Just to add that I think this is a fantastic idea. I was hoping to be able to do this with my Standard Slideshow module (allowing the slideshow to be optionally embedded directly on the course page, rather than just a separate view page).

Mark Johnson 14:38, 23 December 2010 (UTC)