This article has been left in place to help users with older versions of Jomres to modify their installations, however if you are running any version of Jomres greater than v6 you should not be using this page. Instead, you should read the Access Control page.
We're getting asked a lot how site managers can make some menu options only viewable by some users. This article describes how you can achieve this.
Firstly, let's make it clear that we're talking about the Receptionist/Manager toolbar Your toolbar. In this hypothetical example we're going to prevent users from accessing the invoices option in the Receptionist's toolbar (Item 14).
Now, there are a couple of ways we can do this. Before we go through them, let's first talk about the files we will be working on.
In the /jomres/core-minicomponents/ directory there are a lot of files with the filename patterns j00009/10/11XXX_option_NN_XXXXX.class.php. 00009 minicomponents are included in the guest's toolbar (which is seen if a guest is a logged in, registered user). 00010 files are included in the receptionist's bar, whilst 000011 minicomponents are included in the manager's toolbar. All nice and straightforward so far.
As we want to prevent managers from seeing the invoice button logically then the file we want to edit is ''j00010reception_option_09_list_invoices.class.php''. Now, you could edit this file where it is but as soon as you upgrade, you'll lose your changes so the first thing you need to do is to create a new directory in the /jomres/remote_plugins directory called 'custom_code' (if you haven't already) and copy j00010reception_option_09_list_invoices.class.php into that directory. Once you've done this, use the administrator area Rebuild Registry button. This tells Jomres to re-scan the directories it knows about to see if there are any new files. As minicomponent files in the /jomres/remote_plugins/XXX directories override those in the /jomres/core-minicomponents directory Jomres will now start to use the copied file, not the original. Because the /remote_plugins directory and any sub-directories aren't modified during an upgrade, these files are now upgrade-safe.
The easy, not so good way
Ok, we can look at editing the file. The contents of this file are very simple, the key part is the following line.
This, however is a poor solution because if you're disabling that button because you want to ensure that nobody ever sees the invoices button you're going to have problems because the manager can still see his invoices by entering something similar to 'index.php?option=com_jomres&Itemid=53&task=list_property_invoices' into the address bar of the browser, and anyway Super Property Managers may still want to see them. So, what's a better solution?
The better way
The better solution is two stage. Firstly, we want to ensure that Super Property Managers can still see that button, so instead of commenting out that line, we're going to add a check to see if the user's a Super Manager. If they are, then we'll show the button. The following is how we'll change the file to achieve this.
What we're doing here is simple enough. We're importing the ''$thisJRUser'' object into the script so that we can look at the value of ''superPropertyManager''. If this is set to true, then we'll show them the button, if not, we wont.
Great, so what else do we need to do? Well, next we want to find the minicomponent that performs the list_property_invoices task. In there, we'll perform a similar check and stop the user from seeing the page if they're not a super property manager. For the invoices list, the file in question is called ''j06002list_property_invoices.class.php''. Again, copy that file to the /jomres/remote_plugins/custom_code directory and rebuild the registry.
If you now open that copied file, you'll see that most of the work is already done for us as there's already a line that gets the user object.
What we can do is add a check after that line that says "if the user isn't a super property mananger, then do nothing". The most appropriate way of doing this is to add the following lines after the one noted above.
The ! means 'not', so if the user isn't a super property manager then drop out of the minicomponent, preventing the rest of it from being run. We could instead trigger an error if we wanted, to catch people accessing scripts that they shouldn't be, but that's beyond the scope of this discussion.
That's it, you shouldn't need to do anything else.
Many new features, as they're added to Jomres, have corresponding minicomponents with the pattern j0600NXXXXXXXXX.class.php as the filename. Some 'older' tasks have their tasks hard coded into ''jomres.php'', for example the dobooking button. If you can't find a corresponding j0600NXXXXXXXXX.class.php minicomponent to match the task you want to edit, you'll need to search ''jomres.php''. In the dobooking example, in ''jomres.php'' you'll see that the 05020 trigger point is used, therefore the corresponding minicomponent would be ''j05020dobooking.class.php''. For Black Bookings, searching through ''jomres.php'' for the string 'listBlackBookings' you'll find the line $MiniComponents->triggerEvent('02130'); therefore the corresponding minicomponent is ''j02130listblackbookings.class.php''.
This document is copyright Vince Wooll/Woollyinwales IT, 2011. All rights reserved.