Welcome to 6.4 Service Pack 1 - please at least read the "Details" below each chapter in this "top" section of the Release Notes.
v6.4 SP1 Release rev. 17395, was released 8. August 2018.
- 2 Other important changes
- 16 very important Bug fixes
v6.4 SP1 RC1 rev. 17373, was available since 25. July 2018.
- 2 Other important changes
- 10 very important Bug fixes
v6.4 Release rev.17313, was released 19. June 2018
See the full list of all logged changes on our website: https://www.farmerswife.com/releasenotes/
Native v6.4 changes:
- 1 Warning: "A MANUAL fw Client desktop app upgrade is necessary when upgrading to v6.4; to assist the "full-installer-download-auto-Client-upgrade-mode" IS active"
- 7 HOT Features
- 20 Features
- 4 Other changes
- 17 Bug fixes
... and also take a look into the new highlights summary "Whats New in v6.4": https://blog.farmerswife.com/farmerswife-release-v6.4
Check out our Getting Started videos for new Advanced Users joining your team! https://www.youtube.com/playlist?list=PLA74zQEGurSW7WY9LJqO0jWLjaQnMXxPI
Upgrading to v6.4 and later - a MANUAL fw Client desktop installation necessary ONCE - the "full-installer-download-auto-Client-upgrade" is supported, see details!
- You need to be on "Gold Support" past the date of the planned release of this version.
- You need to have a "Version 6.4" license at hand, before starting the upgrade process.
IMPORTANT: The built-in farmerswife (fw) Client auto-upgrade process IS DIFFERENT!!!
Due to new fw Client-side "SOCKS5" protocol support, the normal "simple in-application auto-upgrade" is NOT supported on the initial upgrade from lower version..
In order to upgrade, the fw Client applications either ONCE need to be manually upgraded, by using at least the installers for 6.4 Beta 8 rev. 17068 or later.
Or each user can use the built-in FULL-installer-download auto-upgrade functionality (if allowed), which will be triggered upon first log-in to the already upgraded fw Server application.
This means, upon login with the fw Client Desktop app, the user has to choose a location where the installer file will be stored on the local machine ... to then automatically continue with the manual upgrade process.
NOTE: The simple "in-application" auto-fwClient-upgrade works again for any farmerswife Client which was once manually upgraded past 6.4 Beta 8 rev. 17068, local Operating System (OS) user privileges READ and WRITE are necessary for this to work.
- Your farmerswife Server application at least needs to have been running on version 6.3 SP1 before the upgrade (if lower, contact email@example.com).
- Inform your colleagues about this new version BEFORE you upgrade.
- Run a "Full Backup" BEFORE the upgrade.
- While the Full Backup is taking place, you could now take a look into the documents provided in the "Read And Use Me Upgrade Package" you were issued together with your license of the previous Released version.
- The upgrade itself might require a couple of "Forced Shutdowns" for it to finish.
- If needed, see more detailed information in the Upgrade Instructions.
- Ensure you have the latest Java version (JRE on Windows/Linux, JDK on Mac OS X) installed, for the Web Client and Mobile Web Client to work properly and in the most secure way. Watch out on Windows: here you can run the fw Server application in 32bit mode (farmerswife.exe) or 64bit mode (farmerswife 64bit.exe); and depending in which mode you're running the WIFE Server, you _must_ have JRE installed in the corresponding 32bit or 64bit version.
farmerswife Server upgrade on Mac:
- Copy the NEW farmerswife Server package to the machine hosting the WIFE Server.
- Un-zip and rename it to include "NEW" in the package name.
- Place it in the same location as the previous running farmerswife Server.
- Quit the running WIFE Server.
- Rename the previous farmerswife Server, to include "OLD" in the package name.
- On both packages do <Control> + click and select "Show Package Contents" in the pop-up menu.
- In the OLD package select the "system" and "files" folders* and use <Control> + click and select "Copy 2 Items".*
- In the NEW package use <Control> + click and select "Paste 2 Items".
- Now copy the new 6.1 license files into the "system" of the NEW WIFE server.
- Double click on the NEW farmerswife Server package icon to start the actual upgrade process.
- Once everything worked out fine, remove or update any Dock or Desktop links. And if needed remove the OLD Server package; because up until now, this was a working "roll-back" backup, just in case something went wrong.
- After the upgrade, start the farmerswife Server as usual.
* You might also need to copy the "html_templates" (only if used and if it contains customized templates) folder. And if you are using any 3rd party integration scripts, don't forget to manually migrate these from OLD WIFE Server package > Contents > "Show Package Contents" > lib > scripts > ... and then here only copy the integration script files from the according sub-folder and not the whole "scripts" folder.
Note: The "files" folder might not even be there, since it was broken out, to reside on some other storage device within your network.
farmerswife Server upgrade on Windows and Linux:
- Make sure you are logged into the host machine with the same admin user as on the initial installation of the farmerswife server application.
- Copy the NEW farmerswife Server installer file to the machine hosting the WIFE Server.
=> On Windows this is a .exe file
=> On Linux 64bit, this is also an executable file; use in a command shell: chmod +x Linux64_...
- Quit the running farmerswife Server.
- Now copy the new 6.1 license files into the "system" of the NEW WIFE server.
- Double click to run the installer file in the same manner as the previous installation (for example did you use "Run As Administrator" on Windows?).
- Follow the instructions of the install wizard.
- After the upgrade, start the farmerswife Server as usual.
The farmerswife Clients will auto-upgrade ...
... if already on version 6.4 or later: ... by using the "simple in-application" auto-upgrade process; "normal user" Operating System permissions (Read / Write) are sufficient.
... if BELOW version 6.4:
... by using the "FULL" Client upgrade process; OS admin user permissions Read, Write AND Execute are necessary on the initial upgrade to version 6.4.
IMPORTANT for the supported auto-upgrade functionality in later versions:
For the farmerswife Client applications the "simple in-application" auto-upgrade process to work (once supported in later versions), "normal user" Operating System permissions (Read / Write) are sufficient. You log-in, you confirm that you want to upgrade, the needed files are transferred, the WIFE Client restarts, done.
But when auto-upgrading on Mac with a mix of Admin and Standard users, make sure to be logged-in as a Standard user. Then after mounting the .dmg file, drag-and-drop it to the Applications folder. You then need to authenticate with the Admin users credentials! The farmerswife Client will not work for the Standard user, if installed while being logged-in as the Admin user.
IMPORTANT when upgrading the WIFE Client on Mac: If you have a mix of Admin and Standard users on a Mac, make sure to be logged-in as a Standard user. Then after mounting the .dmg file, drag-and-drop it to the Applications folder. You then need to authenticate with the Admin users credentials! The farmerswife Client will not work for the Standard user, if installed while being logged-in as the Admin user. For the farmerswife Client applications the "simple in-application" auto-upgrade process is supported, "normal user" Operating System permissions (Read / Write) are sufficient. You log-in, you confirm that you want to upgrade, the needed files are transferred, the WIFE Client restarts, done. This upgrade process is not explained in any further detail.
For customers on lower versions than 5.x:
5.x and 6.x are facelift versions! The user interface has changed, but it's still farmerswife.
If you have not seen it before, simply first try it out on your own local machine https://www.farmerswife.com/ and click on the "Free Trial" button.
Once you've successfully upgraded, please inform us by sending a short email to firstname.lastname@example.org; this is very helpful information for us.
Latest free universal iOS farmerswife app v5.0.825 on Apple's App Store - available since June 4. 2018, click on "+" to see the details!
The latest iOS farmerswife app is v5.0.825, and it's available since 4-June-2018.
NOTE: iOS 9 required since iOS farmerswife app v5.0.706.
Due to security changes on iOS 8.4 by Apple, these changes can only be supported on farmerswife v6.0 SP2 and later versions!
You should upgrade as soon as possible to the latest released version 6.4, but at least v6.1 SP1 rev 16195.
If you can't upgrade your fw Server application to v6.1 SP1 rev 16195 or later (released 20. July 2016), then you can't use the latest available iOS farmerswife app on iOS 8.4 or later.
You will get a "Error Failed To Connect" message.
IMPORTANT for older versions:
The latest v5 universal iOS farmerswife app for iOS 7 or later: v5.0.59 is available on Apples App Store since 12-September-2014.
Your WIFE Server needs to be at least on version 5.0 SP4 or 5.1 SP1 or later to use version v5.0.59 and later.
How to install the iOS farmerswife app:
On your Apple mobile device go to the "App Store" app and search for "farmerswife"; depending what iOS version you have installed, it will show you different iOS farmerswife app versions.
Latest iOS farmerswife app version is 5.0.802; it requires iOS 9 and later (ideally you're always on the latest iOS version).
Version 5.0.59 requires iOS 7 or later. This is the iOS 7 optimized version.
For iOS 6, the latest iOS farmerswife app is still version 5.0.34.
Once more: The iOS farmerswife apps v5.0.59 to v5.0.802 are compatible to login to WIFE Servers on 5.0 SP4, 5.1 SP1 or later, 5.2 or later, 6.0 or later ... except if on iOS 8.4 or later; here you need to be on v6.0 SP2 or 6.1 Beta 1 or later.
Per logged-in WIFE Server version, it will then allow using the latest supported features up to that point per that version.
NOTE: The 4.11.1 iOS farmerswife app will NOT work with a v5.x WIFE Server or later versions!
Running a separate TEST WIFE Server
This chapter describes the recommended best practice on working on and with a separate TEST WIFE Server.
This might be needed when running on Beta versions, or new Service Packs or in general when you first want to run an upgrade check
or evaluate new modules or new functionality on a separate TEST WIFE Server installation.
You can always use a WIFE Server in "demo mode" (also with your DB files) and it will run for 60 min. and you have 40 sessions.
An additional "TEST Server" license can be provided upon request, available for customer with a valid service agreement in place;
include in your request the Company Name, the info of the local static IPv4 address and the used Operating System of the machine to host the TEST WIFE Server.
farmerswife supports Push and Feed functionality, and various other email notifications (if enabled); and it can be integrated to various other 3rd party systems; and you can also break out folder structures to network shares which are normally locally hosted on the WIFE Server's host machine, etc.
All this functionality is therefore also enabled by default on a separate new TEST WIFE Server environment you might be using. And if not handled with care and turned OFF in a good way, this will lead to duplicate or wrong notifications to your users, or update wrong information on your real live Production farmerswife system.
Please read on.
For a "half way realistic" test environment, copy the "system" folder from your WIFE PRODUCTION Server, more info below!
Depending on how you use farmerswife, you might also need to copy other files or folders.
Use the "server.cfg" file to control certain vital parts of your separate TEST Server:
This "server configuration" file (server.cfg) provides the option to change certain "General tab" settings "outside" of the actual WIFE Server application.
You use this file to ensure certain settings are NOT enabled on your TEST WIFE Server BEOFRE it gets started.
These settings/variables are available by default on this version:
These are additional settings/variables not set by default:
Since v6.4 these two settings/variables are special, because on a "standard" and "not externally proxied" fw Server installation, both of these MUST have the SAME port value!
On our "Demo DB" these settings/variables will look like this:
Note: Only licensed features and their variables will be effected by any changes within this .cfg file.
A proper WIFE Test installation works like this:
- Quit your farmerswife PRODUCTION WIFE Server.
- Create a file called "server.cfg" within your PRODUCTION WIFE Server's "system" folder.
- Start up your PRODUCTION WIFE Server for the first time with the "server.cfg" file in place, then Quit it again, to trigger flushing your existing configuration settings into this "server.cfg" file.
- Install the TEST WIFE Server application on your test machine.
- Now copy at least the "system" folder from your WIFE "production" Server to within your "test" WIFE Server's installation folder. If you have the time, feel free to also copy the "files" folder; and if you have customized anything within the "html_templates" or "/lib/scripts/...", copy these sub-folders, and IF you are using anything "customized" within these folders, the related files might need to be copied as well.
BEFORE (!!!) the first start-up of the TEST WIFE Server, edit the server.cfg file with a text editor application within your TEST WIFE Server's "system" folder and add or set at least these variables to "0", like this:
Save the server.cfg file. Copy it again to a "safe" location on your test machine, so you can re-use it for the next DB file updates. Please read on.
Now start your TEST WIFE Server application.
VERY IMPORTANT after the first launch and after each update of database files of a separate TEST Server
Go to the running fw Server application > Setup > General tab > "Full Backup Time" and set it to "Never"!
The "server.cfg" does not yet support this feature, and if you do not turn it off, this might interfere with your actual real "Full Backups" from your "in-production" farmerswife system!
NOTE: to test "Allow Mail" functionality from a "test" WIFE Server, you can use for example a service like "Mailtrap" (http://mailtrap.io).
You then need to update this variables with your access details:
Repeat the above steps, for any upgrade or repeated update of the "system" folder on your Test WIFE Server.
We recommend to save the correctly configured "server.cfg" file for the TEST environment in a good way, and then simply replace it prior to the first start-up.
NOTE: Once you have properly configured your TEST WIFE Server as mentioned above, you can save time in the future by only copying these files from your PRODUCTION WIFE Server > from within the "system" folder:
About these Release Notes, Disclaimer and Legal Information.
The content of this Release Notes document is subject to change without notice. The information in this document is furnished for informational use only and should not be construed as a commitment by farmerswife. farmerswife assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document. Except as permitted by such license, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the express written consent of farmerswife.
Fixed a bug causing that the "Split" button was wrongly overlapping the new "Save" button when a Project has no Binders.
This was caused by a previous fix about wrongly displaying the "Split" button when the Project has Binders; "Split" is not supported if a Project has Binders.
Fixed a bug on Cirkus Integration to handle unexpected Cirkus server responses.
Implemented performance improvements for the "Conflict Checker and Resolver" to save time on Booking operations on "big" databases, see details.
The improvements have been benchmarked to save more than a minute when doing Booking operations on "big" databases ("big" = more than 10.000 Bookings).
Fixed a bug wrongly again causing "Error: Server Modify" when trying to change fw Server-side imported Contacts.
Fixed a bug causing ""cb_sync_warnings" no such variable" fw Client crashes when re-stocking Virtual Objects via a Check In.
Fixed a bug causing fw Client crashes when setting stock on "Virtual Objects" if "Expected To Be Returned When Checking Out" is disabled.
Now, when doing a Check In using Copy on the selected "Virtual Object", when there's no Check Out found for that Object, this will still trigger a warning about this, but the stock is increased accordingly and a Dispatch > Check In is created.
NOTE: 999 is the maximum amount of Stock to be added per one single Check In for "Allow Multiple Check Outs (Virtual Object)". If you have more stock, you will need to create multiple Check Ins.
Fixed a bug to prevent the same Object from being added twice to the same Dispatch and prevent it from being scanned twice, see details!
When a Dispatch had already been created from a Booking and the same Object was added again to the same Booking, the Object was wrongly added to the Dispatch and it was also possible to scan it twice. This was a loop hole to the normal blocking process if the same Object with the same Inventory Number is added twice to the same Booking.
Now, when upgrading, an automated clean-up/checking process will be initiated that will remove any wrongly double-added Objects from already existing Dispatches. And when upgrading, it will look similar to this on fw Server > Log:
"3788: 20180731:1443: Item Wisycom Microport A - ENG123 (Inventory Number: ENG123000008) marked and removed as duplicated on Dispatch Check In Number: 888 (id201802091458200000005452)"
"3788: 20180731:1505: Item Aviwest 23 (180) (Inventory Number: ABC000691) marked and removed as duplicated on Dispatch Check Out Number: 8582 (id201801031249500000064208)"
Fixed a performance issue when adding "stock amount" for "Virtual Objects" this wrongly takes a very long time, see details.
Before, when adding stock for "Equipment" Objects" which are configured to "Allow Multiple Check Outs (Virtual Object)", it took a very long time when setting the stock amount via a Dispatch > Check In > Copy = amount of Stock.
On an "average rental" DB with 4.500 Objects:
- 5 min for 300 copies.
- 999 copies ... more than 30 min.
Now, it takes 6-9 seconds in average to add stock by 300; and 1-2 minutes for 999.
IMPORTANT: 999 is the maximum amount for adding Stock on Virtual Objects on one Dispatch > Check In, by using "Copy" on the actual Virtual Object within the Check In window. If you have more Stock you will need to create multiple Check INs.
Note: The above mentioned times can be different, depending on host machine environment, size of database, etc.
Performance improvement in the indexing process implemented for the "Web Shared Hourline Views" and "Dayplan Hourline Views", see details.
This was causing a "wait" of more than 6 seconds on databases containing a lot of "Saved Hourline Views", when just opening and closing e.g. the "Modify User" window, without doing any change.
The Web Profile settings were also being affected, and these issues are fixed now.
Fixed a bug for the "Invoice Manager Password" wrongly preventing the password change if Password Policies are active.
The Invoice Manager has an option to lock it by password.
If this was set BEFORE activating the new "Password Policies", and if it did not comply with the new set complexity, it was not possible to be used. It was wrongly first trying to validate the old password. As it could not match them with the new set "Password Policies" it prompted the user with a pop-up message that the password is not valid. So the user was locked in a state where it was impossible to change the password, unless disabling the "Password Policies" or manually reset the Invoice Manager Password with matching complexity via fw Server > Setup > Financial > "Invoice Manager Password" . Now it does not validate the already set password against the policies.
Fixed a bug causing fw Client freezes on some specific users with data corruption on the Timeline start and end dates.
Fixed a bug wrongly not loading a "Saved Hourline View" in the Personnel tree, when using "New Grouping From Class" after a user was added, see details.
If a "Saved Hourline View" was created from "Classes" by using in Hourline > Options > "New Grouping From Class", then after adding a new user to the "Members" list of the used Object Class via the Object Manager, on then trying to load that view in fw Client > Long Form > Personnel tree it would wrongly not load.
Changed label "Day Note" within the Timereport window to "Time Report Day Note" to differentiate it from the "Day Note" on the timelines.
Fixed a bug by which the new "Saved Hourline Views" indexing process was wrongly called when updating "Web Profile" settings that were not related.
Now, it's only triggered when updating the settings: "Can See All Shared Hourline Views", "Select & Share Hourline Views" and "Day Plan Hourline Views".
Fixed a bug for a "Saved Hourline View" to wrongly also be available as a "Select And Share Saved Hourline Views" if ONLY added to "Day Plan Hourline View", see details.
So now, if a "Saved Hourline View" is ONLY added in fw Client > Object Manager > Modify User window > Web Profile Manager > Events > "Day Plan Hourline Views", then only this "(day-plan)" view will be available for all Web Access Tiers using this Profile.
Fixed a bug wrongly hiding from "Select & Share Saved Hourline Views" if the same view was also selected in the "Day Plan Hourline Views" in the Web Permission Profile, see details.
In the Web Profile Manager, adding a Saved Hourline View to the "Select & Share Saved Hourline Views" and adding the same Saved Hourline View to the "Day Plan Hourline Views", this was wrongly causing the exclusion of the selected Saved Hourline View from the "Choose to view > Categories > Views > for the Web Users.
Now if Selected both, the "Select & Share Saved Hourline Views" and the "Day Plan Hourline Views" are again displayed.
Fixed a bug wrongly causing the "Favourite" option added on Views to get lost when upgrading to 6.4 on iOS fw app, Web Client and Mobile Web Client, see details.
When upgrading passed 6.4 rev.17325, "Shared Hourline Views" saved as favourites on iOS farmerswife app, Web Client and Mobile Web Client were not being shown properly.
Now when upgrading to this version containing the bug fix, this recovers the favourite flag on those views.