Manual Bicyclerent - Options


Let's describe the component's options now which can be found as known from Joomla! in the top right of the backend list screens while using the component.

The first tab (Bicyclerent) offers you these choices: 

  • How should the disponibility ordering be queried? If you want your bikes to be randomly chosen, they will more or less equally wear over time but without guarantee - if you choose reservation count ascending the same effect but with more probability will be seen. If you want some to be used more than others to be able to achieve high resell prices for the not-so-much used ones, choose Database ID ascending or Reservation count descending. The first published version will also allow for a complete custom ordring column to be used, so you can reorder if needed at any time to use certain bikes more than others.
  • If you need more than a night to get your bicycles back in shape before your next rental, be sure to activate Bookoffs for Availability Check. You can enter the necessary days with each type (described later).
  • Station Changes offer the same option to allow for a number of days to be added when a bicycle is offered for a given period at another station than it's root. Here you need to evaluate, how many days you will need upfront and after the "changed" period to allow for transportation. (You can do this flexibly with each station change). These days won't be bookable.
  • Circles allow to look up bicycles not only in the requested station, but also in defined others, organizd in "circles
  • Missing in the below picutres are the options for the list of bookings automatically send via cronjob available with the latest release. Will add a new picture soon Cool here!
  • If you need so you can use different book-off times than for station changes within circles for bicycles ("How many days - yes, I will change this label before publishing the component.. Zwinkernd) to be transported between stations in case circles are enabled. (For example if you have very small distances between your stations in the circles you might use 1 day instead of 2 or 3 for the real station changes). The days noted here will have to be not booked as well as the "normal" reservation period up-front and after the booking period for a bicycle to be bookable.
  • You can decide on a minimum booking period - less won't be accepted.
  • You can decide if you want a certain percentage only as a prepayment instead of the full amount when a reservation is being made and get the remainder later. The PayPal amount will be adapted accordingly. "To pay on booking" lets you decide between 0 and 100%. With 0% even if PayPal is "on" under options the button won't appear.
  • A deadline can be activated for the above mentioned: If you want your customers to always pay 100% when a certain number of days is left only until the start day of their rental period you can use the deadline for prepayment option. If activated, it will get the days of the select list underneath and apply the prepayment percentage only if the booking is being made not closer than the specified days, if it's within that range it will make 100% of the due amount payable directly.
  • You have the possibility to change the date format shown in the plugin and for the reservation confirmation email (not shown above but implemented in the latest version) and choose from either Y-m-d or d-m-Y.


The "own access rights" tab is important for you, if you work with a large number of different stations, regsions, partners and roles who should be enabled to work on their own data but not to see all screens of the component or data:

.. you can assign users to groups within the component, independent of Joomla!'s ACL to make your life easy. Each screen can be accessed only by the chosen groups to which you have assigned Joomla! users (under the user rights menu in the component's menu). The users will only see their range of data, except for Joomla! super administrators who will always see and be able to work on all data. This works via "stations" and "regions" in this component, plus via general rights to see a submenu (called "screen" here, also). If you have assigned for example the screen option "Stations" to "Stations Leaders" but not "Station Employees", the employees won't be able to access the Stations screen, yet the leaders wiill.  

The actual assignment of users to groups will be done under the User Rights screen described later, here you do also the assignment to any existing regions / stations, - thus you can limit the locations out of which the respective roles will see data.

Note: For the bookings, bikes, stations, stationlist screens and most others the models of the component have been modified so the data really related to stations will only be queried regarding these rights. You can choose stations / regions under the User Rights submenu and assign them to users, so they can only see the database entries according to their rights. For the User Rights themselves, and for the following listed screens it is advisable though to only allow superadmins access, which is achieved by simply not adding the groups who should not have access to these screens under own component rights in the options.

Below is a recommendable setup if you are using the component's own user rights, Operators are the most restricted role in terms of which data to see - only those with their own Operator id in the database rows.

Station employees can not change things much, but they can see more data than an operator because they're not restricted to data with specific operator id, Station leaders can see and work with more screens but only with the data related to their assigned stations, region employees / leaders see more stations than station employees and superadmins are able to use any screen and function anyway: 

(Note: You will need to assign the users stations / regions under the User Rights submenu of the component!)

Screen Operator Station Employee Station Leader Region Employee Region Leader Superadmin
extra definitions            
station changes            
stations relations          
user rights          
opening hours exceptions      
invoice templates        
custom fields  not implemented not implemented  not implemented  not implemented  not implemented  not implemented 
station list            
alter table id start            
price exceptions            
Availability Calendar


The model for bookings has been added a function to check if the current user is an operator and in that case only show bookings with his operator id. This is a special role with usually less rights than the other roles provide. An operator should normally only be able to see and work with "his" bookings as he is not a station or region leader who is a more "general" manager and needs to access all bookings and some more things related to his locations.  

By default you can't assign operators screen rights other than for the bookings. If you need to, uncomment the according options in the config.xml file in the administrator folder of the package (on your server or simply reinstall after changing it locally). You will then be also able to assign Operators these screen rights.

Sounds complicated? If you don't need to restrict anything, because you do not have other people accessing this component and need to regulate who sees what, just leave this option deactivated!

I will explain this concept a little closer under the User Rights section!

The next tab under options allows you to customize the Google Maps integrations:

These settings will be used to help you find the distances between your stations (API Key), your station location exactly under "station" and decide on how static maps will look like that can be pulled into region and station description pop-ups in the frontend plugin. (more about this later).

The PayPal screen is pretty self-explanatory, in case you want to use the PayPal automation and payment features, you will have to provide the needed data in this tab. The component is not intended to offer all kinds of options - for bicycle rentals usually a one-off payment is needed only, so you'll find the basic settings here only for a regular "buy-now" button. The price of course will be calculated on the fly out of the type of bicycle, duration of reservation, operator factor (prices can be different in case the operator id is found in the url parameters or an operator is logged into the frontend to process any bookings himself) and chosen price calculation method (under "type" of bicycle).

The offline payment option can be used in case you want to offer a bank transfer to your customers:

Furthermore, the regular Joomla! ACL settings have been integrated but are usually not necessary to be changed due the component's own access rights:

This is useful though, if you want to for example not allow general access to backend components, but for the bicyclerent component. Then you can place the respective users into a Joomla! user group that won't be granted access to any except this component.