Also added fw Client-side platform info in fw Server logs when logging in.

The "Warning" pop-up message for the fw Client 32bit app:
"You are using the 32b it version of the farmerswife client application. Support will stop by the end of 2022. Please contact support@farmerswife.com or your System Administrator to upgrade to a working system."

On the fw Client 32bit app title bar:
"Support for the 32bit app will stop by the end of 2022"

On the fw Server app (both 64bit and 32bit versions) you'll see this info on the first log-line on the fw Server app's Log: window and on the fw Server app's log.txt:
On 6.8 Release:
"Running: farmerswife Server 6.8 (Support for the 32bit app will stop by the end of 2022) (Rev: 20523)"
On 6.8 SP1 Release:
"Running: farmerswife Server 6.8 Service Pack 1 (Support for the 32bit app will stop by the end of 2022) (Rev: 20580)"

Fixed fw Client crash when using fw Client > Toolbox > Settings > Server Setup > MS Azure Active Directory Connector > Setup > "Test" button.

Fixed some wrongly not populating important "Properties":
- Phone Direct
- Phone Mobile
- And fixed in fw Server app > Setup > Users > Microsoft Azure Active Directory Connector > "MS Azure Extension Attribute ID To Import User Number" to correctly populate the data again.

When you create a Project in farmerswife, the auto incremented Project Number is synced to the corresponding Cirkus Project.
But when you created the Project in Cirkus instead, the Number field in Cirkus remained blank even though the corresponding farmerswife Project got an auto incremented number.
This is now fixed by syncing back farmerswife's Project Number to the Cirkus Project.
Note that after creating the Cirkus Project, it can take a moment before it updates with the new Project Number.

When farmerswife creates a Subproject in Cirkus, it can cause a notification to be sent out to all Project Members in Cirkus.
Since the sync can often cause Subprojects to be created in bulk, this can lead to an excessive amount of notifications and put a strain on the Cirkus servers.
To reduce that server load, this operation will no longer cause notifications to be sent.

In farmerswife, Binders can have an empty name. But in Cirkus, Subprojects are not allowed to have empty names.
So when syncing unnamed Binders, it would cause a repeated sync error.
Now it will instead call the Cirkus Subprojects "(Untitled)".

In certain conditions, when one Project's Binders/Subprojects failed to sync, it could cause a loop in a different Project, where Subprojects were first created and then removed, created again, removed again, etc. etc.
That bug is now fixed.

If you:
- Synced a Project between fw and Cirkus.
- Deleted the Project in fw.
- Created new Bookings for the Project in Cirkus.
...then it would cause errors in the log and prevent other Bookings (in other Projects) from syncing.

Now it will detect that the Project is deleted and stop syncing those Bookings.

If anything prevented a Project from being created in Cirkus, farmerswife would just keep trying and trying - even if the error was permanent.
Now it will stop syncing that Project until you open it up and click on the error icon in order to clear errors and retry.

Services that have "Day"/"Days" as the Unit Name, will now show the correct List Price from the Rows loop of the Financial Report Print Designer. Previously having the unit price as "Day" / "Days" would wrongly show the List Price as 0.00.

In the Edit Rule window, next to the working periods chart, there are now two new options:
- Set Periods > Every 2 Weeks (Starting Mon)
- Set Periods > Every 2 Weeks (Starting Sun)

When counting Worked Hours for Labour Rules, farmerswife flattens any overlapping events so that each hour is only counted once.
However this didn't work if events were of different types.
So overlapping Bookings worked fine, and e.g. overlapping Shifts worked fine, but as soon as you mixed overlapping Bookings and Shifts, it could count time double during the overlapping time.

When different types of events overlap in the schedule, the Worked Hours calculation in Labour Rules will "flatten" the schedule so there is only one event at every point in time. This is so that overlapping events won't count double towards the worked hours.
But because Tasks don't count as worked hours, this meant that if a Task got priority over e.g. an overlapping Shift, then it didn't count as work. And if the Shift got priority, it did count as work. So the result wasn't always consistent.
Now it will always prioritize events that count as work, such as Shifts.

When a user wanted to edit the Booking in the Mobile Web Client and add Involved Ob ject, searching them under "Search" or "Categories" was empty and not giving any option to actually find any Objects.
Now the bug is fixed and returning search results correctly.

When an item was added twice to the same Booking, in the Object Report Total Buy/Sell would be wrongly doubled.
Now the bug is fixed and Totals sum up correctly.

When a user had the permission to create and modify Objects in the Objects Manager, but at the same time had no permission to see and modify Rates, it would cause a fw Client app crash when opening the Modify User window in the Object Manager.
The bug is fixed now and users with no rate permissions can open the Modify User window without any issues.

Printing to PDF in New Rendering Mode was converting the Italic Helvetica font to Bold Italic on PDFs. This fix is to correct this issue, so that Italic Helvetica comes through to the PDF as Italic Helvetica.

In v6.8 we've added 2 new fields in the Reports > Row section, that would allow to display Price Agreement Name and Price Agreement or No Price Agreement info. Those fields were not pulling properly in Project Reports, which is now fixed.

The fwRESTapi will now always convert "time" information into the 24h-timekeeping-system according to ISO 8601 time format.

This means, it does not matter if in fw Server app > Setup > General > Time: ... the format "21:00" or this format "09:00 pm" is being used. Time relevant results via the fwRESTapi will now always be displayed in the 24h-timekeeping-system according to ISO 8601 time format.

For this change to apply, your farmerswife system needs to at least run on 6.8 nightly rev. 20572 or later.

There is no "swagger.json" version update needed for this change to take affect.
The latest sagger.json version is still 0.8.9.

Before the fix, 0.00 rates would never get applied after doing "Force Apply" in the Rate Card.
Now Rates will be set to 0.00 when hitting Force Apply, but only if the 0.00 Rate comes from an Object in the Rate Card.

Some farmerswife systems need to hide future events from the schedule for some users.
This can be achieved with using the "Static Time Frames > Viewable" to be set to the past.
But until now, this also prevented "Schedule Changes Emails" to not get sent.

Now a new check-box setting was added, called "Use Web User's Viewable Static Time Frame" and is is located in the fw Client > Toolbox > Settings > Web Share Settings > External Calendars / Schedule Changes Email Sendout / XML ..." section.
This new Setting is enabled/checked by default, to ensure the standard behaviour of the "Schedule Changes Email Sendout" functionality is persevered.

If you now un-tick this new setting "Use Web User's Viewable Static Time Frame", then another new Setting called "Static Time Frames" gets displayed. Select here the period for which the Schedule Changes Email can be send out, independent of the "Static Time Frames > Viewable" configuration.

When you moved a Shift so it overlapped a Booking, there was a dialog asking if you want to remove the Object from the Booking. And if you pressed No, it failed due to conflicts.
At the same time, the conflict dialog didn't show when you added a new Shift.
As it can be useful to have overlapping Shifts and Bookings, the conflict dialog is no longer used when moving Shifts.

Advanced Users who are type "Task/Booking" can now edit the "When Replacing Keep The Class, Activity And Rates" setting in the Toolbox.

In v6.8, new Settings were added in fw Client > Toolbox > Settings > Web Share Settings, to control the Booking Colors in the Web Client and on the iOS fw app.
This caused the previous color behavior to change, and it was hard to update the settings in a way that brought back the old behavior.

Now a new "Enabled" checkbox has been added at the top of fw Client > Toolbox > Settings > Web Share Settings > Booking Colors. Un-checking it will almost bring back the old color behavior, with the exception that "Use Container / Project / Client Colour" will no longer apply. That setting existed before fw 6.8, but it makes most sense to disable it together with all the other Booking Color settings when they are disabled.

Go to fw Client > Toolbox > Settings > Web Share Settings > "Hide User Number / Other In The Web Client, iOS and Mobile Web Client: Yes / No (default)" check-box.

This functionality is supported on the iOS fw app since v5.0.861.