I’m very happy to announce that my first Visual Studio Code extension called NAVBaaS Git has been released last Wednesday.
The people who attended the session about Continuous Integration at the Dutch Dynamics Community event already had their first glimpse at the brand new extension and I really hope that people are or will be excited about this extension 🙂
Source control is step one if you want to do professional development and with source control in place you’re able to take the next step, which is Continuous Integration!
When running AL and C/SIDE side by side you always want to have your symbols up to date, this can be done by starting up finsql.exe with the parameter generatesymbolreference=yes as described here, but it’s also possible to generate symbols at compile time when using the Compile-NAVApplicationObject cmdlet.
It can be very handy to know which NAV Docker images are available on Microsoft’s public Docker repository, you can either do this the boring way by browsing this website (it will only show the 100? most recent tags) or the cool way by using (obviously) PowerShell.
With the release of the latest development preview most of the functions in the test libraries are marked as external, meaning they can be used for extension development!
With the current test framework and it’s limitations it can sometimes be hard to find a way to test your code, this gets even worse when external web services are called.
I’ve seen a number of (bad) workarounds in the last few months varying from calling a nonexistent endpoint to a self-hosted web service to test against.
Of course those workarounds do their job but we can do better than that, and let’s not forget tests must be independent of external components!
Ideally we would simply mock this web service call and return some data we can test against, but not in (C/)AL right?
Every now and then a developer takes the xRec bait and they’re wondering why their code doesn’t work and it usually ends up with a lot of lost time combined with a good amount of frustration.
I hope most of you do know that if you trigger the OnModify through code and xRec is used in the OnModify trigger, Rec and xRec will be the same, however it works fine when it’s triggered through the UI. (more…)
With AL you can already create test codeunits, write test functions but you have to use your own libraries because all functions in the standard libraries are not marked as external..
After reporting an issue on GitHub Microsoft confirmed they’ll be marked as external in the January update!
In my next blog post I’ll show you how to get your docker development environment up and running with the test toolkit.
The time has come, we can finally run multiple NAV versions, cu’s and localization’s side by side with Docker, but how do we actually move our old and dusty c/side development environment to a modern place? (more…)
In the ideal world you have a nightly build, creating your entire solution from scratch, running all the automated tests that come with standard NAV and so on.
During business hours you basically want the same thing but a lot faster, you want to have feedback about your modifications as quickly as possible and running all the tests might be unnecessary and it’s very much time consuming.
Automating your automated tests is just as important as creating and maintaining them, you want to be able to run your tests at least once a day and ideally multiple times a day or even after every check-in.
All we have to invoke these automated tests is PowerShell but there’s another challenge because the automated tests require a user interface and the Invoke-NAVCodeunit cmdlet does not support this.
As mentioned in my first post about testing with permissions, this will be a more practical and straight forward approach on automated testing with permissions, let’s jump straight in!
This is the first part of Automated testing with Permissions, in this post I’ll visualize and explain the way it’s described on msdn and in part two I’ll go for a more practical approach which will support permissions per test function and partial execution of code with a permission set.
Here’s another suggestion for the automated testing framework: a select function on a TestPage object.
In some cases you might face a (runmodal) page where a user has to select one or more records and based on that selection an action is performed, right now it’s not possible (correct me if I’m wrong) to actually simulate this with a TestPage object.
Please vote here or leave a comment.
So today a colleague referred me to this page on MSDN where it states the following about the ID:
If left unassigned the notification will be assigned an ID when the SEND method is called. For more information, see SEND Function (Notification).
So this sounds like giving your own unique ID to the notification is not that necessary at all, right?
After some testing it appears not to be that easy..
As I mentioned in my first blog post about notifications a notification without a unique ID can cause a huge stack of duplicate notifications on your screen and we DO NOT want that at all.
If you leave the ID empty and you let the SEND function generate an ID for you, the ID will be kept in memory BUT only if the notification variable is kept somewhere global (I hope you won’t even consider doing this)
You can think of all kind of fancy functions that will return the ID that the SEND function has generated for you, but in my perception the way to go is to create a function per notification to retrieve the hard coded guid.
P.S. this is also the way Microsoft is doing it.
Since C/AL unit tests run in a client session GUIALLOWED will always be TRUE, if code behaves differently in case of GUIALLOWED = FALSE it’s not possible to actually test that code.
Especially when testing web services it would be great if you could just disable the UI in a test function.
Please vote here!
A bit off topic but in my opinion it should be possible to run unit tests without UI, how cool would it be if you can just call the Invoke-NAVCodeunit Cmdlet to test your code!?
Technically this is possible but a lot of standard NAV tests will fail because of unexecuted UI handlers…
Dynamic visibility of fields and page actions behave different in the web client, make sure you are aware of the following limitations.
– Code in the visibility property will not work
– Using a variable to determine visibility only works once
– On a group this works as expected, workaround is to give those fields their own ‘invisible’ group
– Code in the visibility property only works once
– Using a variable to determine visibility only works once
– Giving these page actions their own group works but images are not shown correctly, no-go
– Use the enabled property as a workaround, this behaves as expected (Microsoft is doing the same)
Also check out this post from Arend Jan Kauffmann
Apparantly the Data Upgrade is executed by the SYSTEM user as you can see below.
The MinValue/MaxValue properties on tables/pages are only applied when the value is changed through the UI!
A colleague of mine came across this issue which looked like a bug at first.
When I for example have two posted credit memos within a different resposibility center than I’ve set up in for myself or in the company information, this will happen…
This is probably in the application for ages but shouldn’t NAV be intuitive? Since we’ve got notifications now, I would at least expect a notification why some documents are not shown when for example navigating to the Posted Sales Credit Memos list OR completely integrate responsibility centers and let the factbox take the responsibility centers into account (which is a lot of work since this cannot be done with the current FlowFields)
Now we have to decide wheter or not we want add our new notification to table 1518, adding it means we give the user the possibility to disable and add extra conditions (depending on the function we use to add it) to the notification.
In order to add our new notification in table 1518 we have to create a new subscriber function which subscribes to the event called OnInitializingNotificationWithDefaultState in page 1518.
Now we’ve got two functions in table 1518 to choose from:
– InsertDefault (basic notification)
– InsertDefaultWithTableNum (conditional notification)
If we decide to give the user the possibility to disable the notification we should also check if the notification is enabled before sending it.
We can do that by one of the following functions in table 1518:
– IsEnabled (checks if present/enabled)
– IsEnabledForRecord (checks if present/enabled and if conditions were met)
Note: if the notification is not present in table 1518 the functions will return TRUE.
After implementing all of the logic above our codeunit will now look like this:
With NAV 2017 we got the all new notification data type, let’s see how we can create a very simple notification and send it to the user.
So let’s say we want to send a notification to the user when he leaves the item description empty or when he empties the item description, sounds easy right?
In this case I’ve created one function which is called from the two EventSubscribers called SendOrRecallDescriptionNotification.
This function will either send the notification to the user or recall it if the Description is filled in, in the meantime.
Notifications always need a unique Id, in this case a Guid, we obviously create this Guid with the PowerShell New-Guid Cmdlet!
If you don’t provide the Notification with an ID you will en up with something like this 🙂
In part 2 I’ll explain how to register our new notification in table 1518 and if we want to give the user the ability to apply extra conditions on the visibility of the notification.
So a few weeks ago I came across this problem and thought I might as well share it with you guys.
Somewhere in the system we had a GET on the purchase document based on the approval entry.
The GET failed so the document was gone, I started looking for a DELETE(FALSE) on the purchase header and came across report 499 – Delete Invoiced Purch. Orders, which did not delete the related approval entries.
Above applies to the following sales and purchase reports:
– 291 Delete Invd Blnkt Sales Orders
– 299 Delete Invoiced Sales Orders
– 491 Delete Invd Blnkt Purch Orders
– 499 Delete Invoiced Purch. Orders
– 5914 Delete Invoiced Service Orders
– 6651 Delete Invd Sales Ret. Orders
– 6661 Delete Invd Purch. Ret. Orders
The reports were fixed in cumulative update 5 for NAV2015, but the records are still out there waiting for a clean up!