> Until they deliver this, eventually you are going to hit the buffers
> however you try and control this, where you want tool X to only be
> available to courses taught by Department A, and tool Y only to be
> available to courses taught by Departments A & B. You will hit a problem
> that not every node can be the primary node.
Surely this scenario is easily achieved by assigning courses to the node
representing their department and turning on the tool in each department
(node) which is permitted to access it (one for tool X and two for tool Y).
I think the problem Malcolm raised earlier was when the group of courses
to be allowed access to a tool does not match the groupings used to form
the hierarchy (e.g. departments). For example, how do you allow access
for all statistics courses no matter which department they belong to? I
think this requires something other than an institutional hierarchy, but
some settings which allow the courses to be selected for each tool. No
single hierarchy will cover all the patterns for every tool.
Stephen
> *From:*Blackboard/Courseinfo userslist
> [mailto:[log in to unmask]] *On Behalf Of *Joseph Gliddon
> *Sent:* 09 October 2014 13:05
> *To:* [log in to unmask]
> *Subject:* Re: Use of Hierarchies
>
> By a huge co-incidence I have just been asked about limiting a tool to a
> very small subset of our courses. So I thought I would share my findings.
>
> As you are all aware there are 4 settings
>
> Off (cant be switched on), Default off (can be switched), Default on
> (can be switched), On (cant be switched on).
>
> These settings can be applied at the system level AND at the node levels
>
> Further for the 2 "Default" options, staff can change things at an
> individual course level via off/on.
>
> Ok first for what happens if the system level is "Default" on or off.
> Then if you are also in a node then your setting *in the Node *is what
> you get. (ie system = default off, node = default on, result is "on")
>
> However if the system level is set to "Always off" or "Always on" then
> the *system level setting *is what you get (node setting doesn't have
> any effect)
>
> If you are in more than one node then you get your settings from your
> primary node.
>
> The big problem comes when you want the tool to be "On" for only certain
> courses and "Off (cant be switched on)" for the rest. You need to make
> one node for your courses that have the tool *and *another node for
> every single other course. You then associate the courses you want to
> have the tool to have the on node as their primary node.
>
> Of course if you then have more than one tool you want to limit and
> start having courses that are entitled to more than one tool then things
> get really messy.
>
> So for now I would recommend what Malcolm suggested and have a node for
> your entitled courses (and another node for every other course - if you
> want to avoid others accidentally switching it on). But at some point
> you may have to bite the bullet and get a fully fledged hierarchy and
> have tool decisions at a school/department level.
>
> Regards
>
> Joseph
>
> On 7 October 2014 17:16, Holden Matthew <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Hi Adam
>
> I was wondering the same. As you have to indicate a primary node I guess
> this is where such settings as the tools is taken from. I haven't tested
> this yet though.
>
> Mat
>
> Sent from my iPhone
>
>
> On 7 Oct 2014, at 15:51, "Adam Tuncay" <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Matthew,
>
> Thanks. I had previously tested this in SP12 where the feature
> didn’t exist. We are now on April 2014 where I can see the option, I
> should really have checked again.
>
> Malcolm,
>
> Do you have a structure where courses are included in more than one
> node with the tool setting on in one and off in another? If so does
> Blackboard respect the on setting and ignore off?
>
> Thanks
>
> Adam
>
> *From:*Blackboard/Courseinfo userslist
> [mailto:[log in to unmask]] *On Behalf Of *MURRAY M.R.
> *Sent:* 07 October 2014 12:48
> *To:* [log in to unmask]
> <mailto:[log in to unmask]>
> *Subject:* Re: Use of Hierarchies
>
> Matthew is correct - in that you can later change the model, but I
> think his suggestion will be hard to manage in the long term.
>
> Say you built out a single model based on Faculties and schools. You
> add the courses to the appropriate school node, and add the tool to
> it too.
>
> OK, but what if not all courses/modules in that school want/are
> allowed to use it?
>
> What if other Departments come on Board. Sure, you can create
> another node for another dept, map the courses and then add the tool
> too, but very quickly it becomes tricky to know which courses can
> see which tool. The ability to search through and report on the
> Institutional Hierarchy is pretty limited.
>
> By creating an extra tool based node you can easily see who should
> and shouldn't be able to access the tool at any time. If you later
> decide to drop the tool, delete this node and turn off the course
> feed to it and you are done.
>
> My suggestion does require more work for you integration -
> associating specific courses with the tool node, but I don't mind
> automated processes working hard if it means people don't!
>
> Malcolm.
>
> Dr Malcolm Murray FRGS FHEA CMALT PG Cert
>
> eLearning Manager - Computing and Information Services | Honorary
> Fellow - School of Education
>
> Durham University | South Road | Durham | DH1 3LE | UK |
> http://tinyurl.com/durltt | @learntechdurham
> <https://twitter.com/learntechdurham>
>
> On 7 Oct 2014, at 12:27pm, Holden Matthew <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Hi Adam
>
> I don’t think that is correct – you can overwrite on the current
> SPs. What SP are you running?
>
> You should be able to set up a node for the school in question
> adding in any courses which you want to have access to the building
> block.
>
> You can then set the tool to off at system level – ensuring you
> don’t apply the lock to prevent you from overwriting.
>
> Then you should be able to set the tool to on in your node.
>
> *Matthew Holden*
>
> Learning Technology System Manager* |* Human Resources Division
>
> Allerton Building, University of Salford, Salford M5 4WT
>
> *t:* +44 (0) 161 295 7284*| *
>
> [log in to unmask] <mailto:[log in to unmask]> *|*
> www.salford.ac.uk <http://www.salford.ac.uk/>
>
> http://www.hr.salford.ac.uk/employee-development/bb9
>
> <image001.jpg><http://www.salford.ac.uk/>
>
> <image002.gif><http://www.linkedin.com/pub/matthew-holden/48/b/241>
>
> *From:* Blackboard/Courseinfo userslist
> [mailto:[log in to unmask]] *On Behalf Of *VLE Service
> *Sent:* 07 October 2014 10:57
> *To:* [log in to unmask]
> <mailto:[log in to unmask]>
> *Subject:* FW: Use of Hierarchies
>
> Hi,
>
> We are looking at the possibility of allowing access to publisher
> building blocks to specific courses within a School. However we
> don’t currently have an institutional hierarchy in place, we thought
> that one could be created manually just for the specific School and
> release the tools to it, but it isn’t possible from what I can tell
> as a structure is needed for the whole institution if you want to
> limit/restrict access.
>
> It would also be useful if the system level tool setting could be
> overridden at node level which would enable us to bypass the need
> for an institutional hierarchy in place, but that isn’t possible either.
>
> Has anyone else attempted this? I cant see any way around it. Any
> suggestions would be much appreciated.
>
> Thanks
>
> *Adam Tuncay*
> e-Learning (VLES) Team | University of Leeds
>
> Website: *MailScanner has detected a possible fraud attempt from
> "applewebdata:" claiming to be*www.leeds.ac.uk/vle
> <http://www.leeds.ac.uk/vle>
>
> For the latest VLE news, hints, tips & updates visit our
> blog:http://vleservice.wordpress.com/,follow us
> on Twitter:https://twitter.com/leedsvlesupport or subscribe to the
> mailing list:http://www.leeds.ac.uk/vle/mail_list.htm
>
>
>
> --
>
> Joseph Gliddon
>
> Learning Technologist
>
> Technology Enhanced Learning
>
> Academic Registry
>
> University of Bristol
>
> 0117 331 4403
>
|
