JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for BLACKBOARD-USERGROUP Archives


BLACKBOARD-USERGROUP Archives

BLACKBOARD-USERGROUP Archives


BLACKBOARD-USERGROUP@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BLACKBOARD-USERGROUP Home

BLACKBOARD-USERGROUP Home

BLACKBOARD-USERGROUP  October 2014

BLACKBOARD-USERGROUP October 2014

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Use of Hierarchies

From:

Stephen P Vickers <[log in to unmask]>

Reply-To:

Blackboard/Courseinfo userslist <[log in to unmask]>

Date:

Thu, 9 Oct 2014 14:33:23 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (234 lines)

> 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
>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager