New custom menu in header

[Jeremy Hopkins]

Currently there is unused space between "messages" top left and "logged in as" top right.

We want to add a TWO custom menus here using Moodles existing format of indenting with hyphens.

The two menus will be side by side. The one to the left will have an admin option (check box) to "limit to logged in users". The one on the right will have the option of only being visible to users with a given profile / custom profile field.

be One will have access / visibility restricted based on a profile / custom profile field. This same process is used in #12 and #18

The desired result is to replicate the navigation shown in the header of http://www.coventry.ac.uk (that website opens an overlay, we just want nav to look like that but show drop downs as is normal with Moodle navigation).

Note: colour option required for this and other header items as outlined in #6

[John Stabinger]

Not sure what this means: "The one on the right will have the option of only being visible to users with a given profile / custom profile field."

I would suggest we use the new top header font and background colors for this to make it a simpler implementation. I would suggest we use text boxes in the settings where users simply add a list (li items) with links, etc.

[Jeremy Hopkins]

I agree on the colour pickers, use those recently added.

Put simply we have some liks available to all users and others available only to staff. As we use delimited free text (moodle custom menu format) to ender the links there is no easy way to implement that restrictoin in a single menu. The only way I could think of doing it was to place two menus side by side, the one on the right hand side having a profile field restriciton (for staff only links).

Does that make more sense?

[John Stabinger]

That makes sense but I do not see how we would implement the profile field restriction. Any ideas on it?

[Jeremy Hopkins]

Given the number of other changes I have added and the fact that at this point in time I do not even know if anyone oustide BCU or coventry would use this feature I will simplify it. The custom profile field both BCU and Coventry will use is "persontype". To access this you would use:

$user->profile_field_persontype

In the theme we need to be able to add the value we want to match, so we could add (in the various places this method will be used):

1. a label "persontype must match"
2. a text field to take the value

Thus you know persontype is the the field and can simply hard code:

$user->profile_field_persontype

and test against the text field value in the admin field, which will almost certainly be either "staff" or "student".

[Jeremy Hopkins]

... so with that test in place you would need conditional statements to render those menu items

• IF (admin field empty) { render menu}; // admin has not applied a rule
• ELSE IF (admin field == $user->profile_field_persontype} {render menu}, // admin has applied a rule for us to test against

If neither condition is met do not render the menu.

[John Stabinger]

Are we applying these rules on each menu link or on the entire menu?

[Jeremy Hopkins]

Hi John,

A video explanation can be found here:

http://1drv.ms/1MejefJ

We need two menus side by side which look itendical / part of the same menu. One of these needs to be limited to "persontype" for staff only links which will be on the right. Every user will see "a menu". Staff users will see an additional menu.

[John Stabinger]

So there will be two new menus, one to be visible by everyone and the other determined on the profile field type.

There will be two settings for a user to add a profile field type (and the other field will be set to the value it should contain) that will be used in the php to determine who to show it to.

There will also be two text areas for the admin to add LI items for the two new menus.

Placement will be next to the 'messages' item in the top header.

[Jeremy Hopkins]

Hi John,

I think it would be better ot apply the rule to BOTH of these fields, but using the code example given before that ignores rule if the field is empty. That way if we ever needed to we could show completely different menus to staff and students.

I think placment should be to the left of the username in the top right, see attached screen shot.

[John Stabinger]

I’m not sure how we could show completely different menus to staff and students without having separate and different field settings for each menu (rather than just one).

If nothing is in these fields, but menu items are present, then the menus will present to everyone.

[Jeremy Hopkins]

We DO need separate and different field settings:

• Two input boxes (for menu code)
• Two sets of fields for restricting access

They would need to be named differently and render separately in the theme using different variable names. The code to determine whether to display could but put into a single function.

If the menu is present and no rule is applied then yes, it would show to everyone If no menu is present it shouldnt render anything If a menu is present AND a rule is applied then it is only rendered for users of that "persontype"

[John Stabinger]

Makes sense.

[John Stabinger]

Do you have any working examples of getting the value of a custom profile field?

$user->profile_field_persontype

does not seem to work for me (I have tried it a number of different ways).

[Jeremy Hopkins]

1. Has the custon field been added in moodle?
2. It may require an include / require once, I will check that later, dont have access right now

[John Stabinger]

Yes, a custom field of persontype has been added.

[Jeremy Hopkins]

I think you need:

require_once($CFG->dirroot.'/user/profile/lib.php

I will double check that later.

[Jeremy Hopkins]

I just checked the code where I used this and it has:

• require_once($CFG->dirroot.'/user/profile/lib.php');

• profile_load_data($user); // load custom profile fields

• $user->profile_field_persontype = $value // set custom profile field

It also requires user lib but that is for other functions, I am sure it is only the above code you need.

• require_once($CFG->dirroot.'/user/lib.php');

[John Stabinger]

Needed the global $USER; to get this to work.

It is working with the two new menus now.

[John Stabinger]

Note that I changed these to use custom menu functions like the tools menu last night from what I originally had it as.

[Jeremy Hopkins]

Hi John,

We need these menus to, at the top level render horizintally across the top of the menu. There are a couple of issues with the style currently. I have made a screen recording to try to illustrate what I mean:

http://1drv.ms/1iM4kk2

[John Stabinger]

I don’t think that will be possible without re-building the functions and taking all of the time left available for additional work. I will work on cleaning up the hover backgrounds, adding arrows and the sub-sub menus.

[Jeremy Hopkins]

Ok how hard would it be to add more top level menus, i.e. clone the existing two menus to make more?

Also I am assuming "Top Menu Dropdown 2 trigger word" is intended to be applied to these allowing FA to be used and the name / menu link text to be altered from the hard coded value it is currently?

[Jeremy Hopkins]

I have had another look at what we need for this and if we cannot render the top level items horizontally would need a total of five menu items rather than the two we have currently. If it is possible to add the restriction fields to all it would make the navigation more flexible going forward as not only could we use more regions but also target different types of user.