Welcome to 6.5 BETA - please at least read the "Details" below each chapter in this "top" section of the Release Notes.
Our Beta Agreement with You
By installing the Beta version of our software farmerswife, you hereby confirm that you understand and agree to the consequences thereof as listed below:
Only customers with a Gold Support & Maintenance Agreement active past the planned release date are eligible to receive a Beta license. The release date is subject to change; once upgraded to the Beta version the Beta-Customer agrees to extend the Support & Maintenance Agreement to at least one month past the actual version release.
For customers who have purchased feature development it is prerequisite to run the Beta version within their production environment.
Without purchased feature development the access to Beta is only granted on a case-per-case basis at our own discretion.
Any prior issues (bugs, missing functionality, etc.) or new ones related to the upgrade to the Beta version need to be addressed separately and conform to the below information. Being on Beta doesn't mean that all issues can or will be addressed; some might require unplanned and purchased feature development.
You hereby authorize us to include your Company Name, City, and Country to the list of Beta Customers within the Beta Release Notification email. All recipients you have informed us about (see below list), will receive this notification once a next Beta version is ready to be downloaded and installed. All recipients are added as "BCC".
We need to know the First Name, Last Name, Title, email address of:
- Main Farmer(s)
- Main IT contact(s)
- Main WIFE user(s)
You also confirm:
All users who work with your farmerswife system running on "Beta" were previously informed about the following information.
You agree to upgrade as soon as possible, once we've notified you about a new release.
The updated Release Notes supplied with every release notification and shipped with each installer are the first and only line of documentation during the Beta phase. The content is essential for everyone running a WIFE Beta version. You agree to read them and distribute them among your users.
New feature development bears the higher risk of new bugs being introduced, or previously working functionality to contain bugs. We need to be able to replicate the bugs, in order to fix them. The issues you might encounter will not go away by magic. We need your help here: report bugs to firstname.lastname@example.org. If you use the below format, it not only makes it easier and less time consuming for your and everyone involved, but a responsive and fluent communication is the very base for a fast solution of any issue:
Email Subject: a clear and short description of the problem or bug. For example: "WIFE Client crash on opening Project #12345 on WIFE-Beta-version-xyz" is already a lot more useful than "WIFE crashes" or "problem"
WHAT and WHERE is the bug?: describe as detailed as needed and in the shortest possible way on how to replicate the bug. Any window in WIFE has its own title name. Using these descriptions is the best and easiest way to communicate to us, to what you are referring to within WIFE. Please also consider adding screen shots; make sure all needed information is visible on your screen shot. This is not always needed, but it's a very useful a quick way to provide us with more information.
Describe in simple words of what happened.
Describe what you expected to happen.
... and then send this to email@example.com
If a WIFE Server crash was involved, use the "Send Backup Now" button located on the WIFE Server application window.
If a WIFE Client crash was involved we need the "error.txt" from the machine where the crash happened; the error.txt is located in the root installation folder of the WIFE Client software.
Farmers WIFE offers these access tiers to the system:
WIFE Client application on Mac and Windows (Linux is also available but not officially maintained).
Web-browser based Web Client (designed for Safari, Firefox and Google Chrome. Recent changes now make it also usable with MS Internet Explorer v9).
WebCal based "Object Event subscription" to 3rd Party applications, which support subscribing to WebCal format (e.g. Outlook for Windows and iCal).
For Apple iOS mobile devices the iOS farmerswife Beta app is special. At the beginning of it's Beta phase (not always needed) this app might only be installed if the Apple mobile device's UDID was pre-registered by us. Special conditions by Apple apply; the amount of UDID's we can grant access with is VERY limited. We register only max. 5 UDID's per Beta customer during the normal Beta phase. Closer to the planned release date, we might make the iOS farmerswife Beta app version available on Apple's App Store.
6.5 Beta development phase roadmap
This section will be updated with every released version.
The below dates are goal planning dates.
These dates are subject to change without notice!
6.5 Beta 1 "IBC 2018 Preview": 13. September 2018. DONE
6.5 Beta 2 "NAB 2019 Preview": 8. April 2019. DONE
6.5 Beta 3: 17. April 2019. DONE
6.5 Beta 4: 30. April 2019. DONE
6.5 Beta 5: 7. May 2019. DONE
6.5 Beta 6: 15. May 2019. DONE
6.5 Beta 7: 3. June 2019 ... in progress
6.5 Beta 8: 5. June 2019
Earliest planned release date:
End Q2 beginning of Q3 2019
Upgrading to v6.5 Beta - 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.5" license at hand, before starting the upgrade process.
- We recommend that you first get a proper separate "TEST environment" up and running.
ONLY upgrade from 6.4 SP2 rev. 17824 or later!
The "simple" built-in in-application farmerswife (fw) Client auto-upgrade process is supported.
Soon to come:
A new low-level-libraries-upgraded version for Windows called "Windows_64" will be soon available.
If this is used to upgrade the fw Server application, then on Windows a MANUAL fw Client desktop installation is necessary once to upgrade to v6.5 - the "full-installer-download-auto-Client-upgrade" is supported,
This will then install the new 64bit fw Client desktop app on Windows!
Each user on Windows 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 built-in auto-fwClient upgrade will work again for any "Windows_64" farmerswife Client desktop app, which was once manually upgraded.
- Your farmerswife Server application needs to have at least been running on version 6.4 SP2 rev. 17824.
- 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 use these instructions: https://support.farmerswife.com/a/solutions/articles/17000026005-server-and-client-installation-linux
- Quit the running farmerswife Server.
- Now copy the new v6.5 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 SP2 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 SP2:
... by using the "FULL" Client upgrade process; OS admin user permissions Read, Write AND Execute are necessary on the initial upgrade.
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:
5.x is a facelift version! 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.828 is available on Apple's App Store, click on "+" to see the details!
The latest iOS farmerswife app is v5.0.828, and is available on Apple's App Store since 08-April-2019.
IMPORTANT: Requires iOS 12
And due to iOS 12 requirements for new submitted apps this will result in the previously working 3rd party external barcode scanner support to no longer work, as this was removed by Apple.
The previous farmerswife app v5.0.825 (available since 4-June-2018) works from iOS 9 through to iOS 12.
NOTE: iOS 9 required since iOS farmerswife app v5.0.706.
Requires farmerswife v6.1 SP1 and later versions!
You should upgrade as soon as possible to the latest released version 6.4, but at least to v6.1 SP1 rev 16195.
If you can't upgrade your fw Server application to v6.1 SP1 rev 16195 or later (was 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.
How to install the iOS farmerswife app:
On your Apple mobile device go to the "App Store" app and search for "farmerswife"; depending on which iOS version you have installed, it will show you different iOS farmerswife app versions.
Latest iOS farmerswife app version is 5.0.828; it requires iOS 12 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.
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 6.1 SP1 or later to use iOS farmerswife app version v5.0.59 and later.
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" (https://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.
Changed wrong behaviour on "Do You Want To Keep Rates And Activities" setting. See details!
Before when replacing Objects you would always get a dialogue that asks "Do You Want To Keep Rates And Activities" even though you might not be using Rates, Classes or Activities.
A new setting in fw Client > Toolbox > Settings > Class / Object > "When Replacing Keep The Class, Activity And Rates" now controls whether to get the pop-up message or rather have a default "Yes/No" behaviour.
1) "No" => When replacing, it will ask to select the Class and Activity and the new objects own rates will apply.
2) "Yes" => When replacing the new Object will keep the old Object Class, Activity and Rate (IF it also belongs to the same Class and/or has same Activities, else own Class or Activities will apply).
3) "Ask" => When replacing you'll be asked if you want to keep the old Class, Activity and Rate:
- IF NO => same as above 1).
- IF YES => same as above 2).
Important: If the User has the Permissions "Can Edit Booking Rates" or "Can Select Booking Activity" disabled, then this setting will be forced set to use "No" and the user won't be able to change it.
Fixed a bug when copying or repeating a "Booking" the "Created By" detail is now showing the correct Username of who copied it, see details.
Before this bug fix the "Created By" field on the new copied/repeated Booking was still wrongly showing the Username of who had created the original Booking.
Fixed a bug wrongly disabling the "Forward To Actuals View" on Price Agreements, see details.
When the "To Invoice / Invoiced" View is set to include Budget Details, the "Forward To 'To Invoice / Invoiced' View" option is disabled, because the Budget's Price Agreements are already automatically brought into the view.
The bug was that this also made the "Forward To 'Actuals' View" action disabled. That is now fixed.
Implemented multiple performance improvements on the Cirkus.com Integration, see details.
- Now, farmerswife will query for changes on Tasks since the last sync and process them, instead of query all Tasks to evaluate changes after.
- The first sync after a fw Server restart will be a Full Sync.
- The button “Update Now” also triggers a Full Sync.
- Now, it’s also possible to enable Cirkus logs, by adding the var CIRKUS_LOGS_ENABLED with value 1. This will write log lines in the file fw Server/system/customlog.cirkus.log.
Fixed a client crash when connecting to a fw Server with the "Pre-login Message" being enabled.
Added "Swapping" actions from Dispatch to Booking's history, see details.
When an Object got swapped in the Dispatch module, there was no history entry for this in the corresponding Booking (if any). Now when swapping an Object with another, or swapping an Object Class with one of its members, the Booking History will state:
Swapping an Object class with Object Class member:
"Removed (Dispatch): Object Class Name
Added (Dispatch): Object Class / Object Name / Inventory Number"
Swapping one allocated member of an Object Class with another:
"Removed (Dispatch): Object Class / Object Name / Inventory Number
Added (Dispatch): Object Class / Object Name / Inventory Number"
Added two columns to the Dispatch window: "Related Check Out" to Check Ins and "Related Check In" to Check Outs, see details.
When an Object is scanned back into the system, on the "Check In" window there is now a new column called "Related Check Out". This will now display the number of the "Check Out" where this Object comes back from. This way it is easy to see, if all scanned-in Objects came back from the same job.
The "Related Check In" column data will only show, after you click "Ok" on the newly created Check Out. You will then see the last Check In that the Object came back from.
Both columns are now available in the Dispatch Report in the "Element Row" section.
Fixed a bug when using "Paste From Objects Clipboard" wrongly causing all copied Objects to already be verified in the New Check Out, see details.
When copying Objects from a "Dispatched" Check Out to a newly created Check Out by using "Paste From Objects Clipboard", then the copied Objects were added wrongly on already "verified" status. This has now been fixed and the copied Objects now appear with non-verified status.
Fixed a bug wrongly causing Objects not to be removed from the linked Booking, if they were deleted from the corresponding Dispatch on Status "Ready".
Added "Scheduled Invoices totals" fields to the Financial Reports "Header" and "Footer" sections, see details.
The fields added to the Financial Reports "Header" and "Footer" sections are:
- "Scheduled Invoice Fixed Price"
- "Scheduled Invoice Fixed Price (Invoiced)"
Implemented farmerswife Server-side performance improvements for "Financial Reporting", see details.
The following farmerswife (fw) Server-side performance improvements will typically have their greatest effect when running Financial Reports on BIG databases (= size of current45.efdb bigger than 150MB).
The built-in Financial Reports performance improvements are split in two parts:
a) "caching" (or pre-calculating and temporarily storing the results) of the most needed "Input" data during the start-up of the fw Server application. This can save time and reduce computing later. The "input data" is therefore "already ready" before any user has created a Financial Report.
b) "threading" of the actual fw-Client-FinancialReport-connection to the fw Server. This means, that the creation of the Financial Report no longer has an impact on the running fw Server session. It now only affects the user who is generating the Financial Report. This now no longer blocks the connection for everyone else, while the Financial Report is being created.
There are now these 3 new fw Client side Settings which allow to disable or enable this functionality in fw Client > Toolbox > Settings > Server Setup >
1) "Use Threading For Financial Reports":
This is enabled by default.
fw Server-side and technical details:
The memory usage of the fw Server application during run-time will increase by around 30%.
During the launch of the fw Server application, this will create within the fw Server's "system" folder a file called "init_worker_thread_flag".
And on the fw Server's "Log" window this info will show this line:
"Starting Up Worker Threads".
The "init_worker_thread_flag" file gets removed again, when shutting down the fw Server application if there were no issues during runtime. Should this file be present during the launch of the fw Server application then this will cause this line to be stated on the fw Server's "Log" window:
"Skipping Worker Thread Startup since it looks like previous startup failed".
Then the next graceful shut-down of the fw Server application will then remove this file, for the "Use Threading For Financial Reports" to be active again on the next fw Server start.
This new functionality does NOT take effect when doing Financial Reports on a single Project and up to max. 3 selected Projects!
In order for this new functionality to become active 4 or more Projects need to be selected to run a Financial Report on.
ONLY if the following Setting "2) "Keep Thread Data Updated" is DISABLED (= not ticked), then when creating Financial Reports on 4 or more Projects, there will now be a yellow triangle "Warning" icon on the "Generate Report" button, which will shot this info on mouse-over:
"The Report Data Being Used Was Last Refreshed:
Click To Refresh Now"
"x-time" is based on the latest time the "Financial worker thread" was last updated.
It is now the user's choice to generate the Financial Report based on the existing cached data by using the "Generate Report" button. Or to trigger an update to run the report on the latest data, simply by clicking on the yellow triangle Warning icon.
2) "Keep Thread Data Updated".
This is enabled by default.
And this feature simply ensures that the new "Financial worker thread data" gets updated before each Financial Report. This causes the above mentioned Warning triangle icon to appear, since the worker thread data is up to date.
3) "Use Caching For Financial Reports":
This is enabled by default.
This creates a NEW "caches.db3" SQLite-helper DB within the fw Server's "system" folder.
Fixed a bug wrongly causing when clicking on a "Checkpoint" icon this would wrongly open the Edit Booking window.
In fw Client > Hourline when clicking on the Checkpoint icon which indicates the currently set status, the Booking window would wrongly open.
Now the correct Checkpoint sub-menu pops-up again, in order to change the Checkpoint.
Added new icons to the "Users" section and "Others" section, see details.
To change Object icons go to fw Client > Object Manager, then search and double click on the Object you want to change the icon. On the Modify window click on the Object's icon to select a different one.
Take care when changing icons of Objects, as this might lead to confusion or irritation among your colleagues.
Fixed a bug when changing the Creation Date of an Invoice, this wrongly cause the changed Invoice's selection to get lost, see details.
For this bug to happen, required these fw Server > Setup > Financial tab settings to be configured as:
- "Assign Invoice Number When Creating" > No
- "Use Pro Forma Numbers" > Yes
Then, when selecting an Invoice (= high lighted yellow) and changing its Creation Date, this caused the selection to get lost and due to Invoice being re-sorted caused the wrong Invoice to be selected (= high lighted yellow).
This is now fixed, and farmerswife now correctly keeps the correct selection.
Added for the setting in Invoice Creator > "Automatically Creates Internal Invoices When Invoicing" to now also apply to "Part Invoice".
PDF Printing (server side)
Fixed multiple issues causing fw Server and Client crashes when printing any kind of Report via the fw Server-side PDF Print Export.
Verbose print logging is still enabled on 6.5 Beta 7.
Added the possibility to filter by "Project Custom Fields" via the fw REST API, see details.
See this documentation for latest changes:
Implemented support for "GET last updates on events since last checked" via the fw REST API, see details.
See this documentation for latest changes:
Fixed a bug wrongly preventing the "Ratecard Name" info on the "projects" table from being populated.
Implemented support on Windows for Java "OpenJDK", see details.
- This is still work in progress -
Download "OpenJDK" e.g. here: https://adoptopenjdk.net/
UNINSTALL Java on the fw Server host machine.
Use JRE - "Java Runtime Environment.
JDK - "Java Development Kit" will also work, but it's not necessary anymore on Mac (to be confirmed).
Fixed a bug causing a fw Server-side error when adding an Object Class as "Extra" to Time Report via the Web Client, see details.
Adding Object Classes as Extra to a Time Report is not supported on the Desktop fw Client.
It was a "glitch" that a Web User could see Object Classes when adding Extras to Time Report.
And as the Web User was selecting a Class, this was causing a fw Server-side error and resulted in freezing the Web Client.
Now Classes are no longer available via "Extras" when time-reporting via the Web Client.
Fixed a bug when using this behaviour for the Web Client “Open Booking Window In Edit Mode When Creating Ad-hoc Time Report", see details.
For this bug to happen required in fw Client > Toolbox > Settings > Server Setup > the Setting “Open Booking Window In Edit Mode When Creating Ad-hoc Time Report” to be enabled.
When in Web Client > "Not Done Time Reports" list on the left pane of the Web Client was used, time-report changes done here were wrongly lost due to the Booking windows opening in Edit mode.
This is now fixed, so that the Booking will only open in Edit mode after creating an Ad-hoc Time Report, but not when saving changes to a Time Report from an existing Booking. So this is now fixed and this setting only applies when creating an Ad-hoc Time Report, as initially intended.
Fixed a bug related to the Web Permission "View And Book Classes As Objects" was not displaying the complete list in certain scenarios, see details.
For this bug to happen required in the Web Permission "View And Book Classes As Objects" to be enabled, "Specific Object Level Control" to be configured and “Select And Share Saved Hourline Views” to be used.
This would cause that some Classes were wrongly not displayed for the Web User when booking via the Web Client.
If restrictions on Objets were applied via the "Specific Object Level Control" then the related Object Class was not being displayed.
Also the “Select And Share Saved Hourline Views” was participating on deciding which Classes were to be displayed.
Now this Web User permission "View And Book Classes As Objects" is independent from any other setting.