{ "changelogs": [ { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 17, "publishPending": false, "updatedAt": "2024-02-19T19:29:41.076Z" }, "title": "13 February 2024", "slug": "13-february-2024", "body": "# Feature release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nAdd Delta upstream messages to the comment section of the notifications.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nExtra details in the (Delta) notifications.\n\n# Feature release\n\nIssue's/PR's:\n\n- \n- \n\n## Summary\n\nRemove separation between primary and routed IP subnet when retrieving from cooldown.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nUsers would now get any subnet returned if one exists in cooldown. There is no longer a difference if the block was previously a primary or routed subnet.\n\n# Feature release\n\nIssue's/PR's:\n\n- \n- \n\n## Summary\n\nMove from imp Redis container to redis1.imp.nextpertise.nl. Instead of using a local Redis container, now use the persistent test/prod Redis server.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nNone\n\n# Bugfix release\n\nIssue's/PR's:\n\n- \n- \n\n## Summary\n\nFixes the cron-administration-diff cli command that got broken by the customer/profile change.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nNone", "type": "", "hidden": true, "revision": 4, "_id": "65cbc929bd58690056dafb39", "createdAt": "2024-02-13T19:55:21.664Z", "updatedAt": "2024-02-19T19:29:40.825Z", "lastUpdatedHash": "465ccc4b4f3eda4dd2312905547152178f3c829e", "__v": 0, "html": "

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

Add Delta upstream messages to the comment section of the notifications.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

Extra details in the (Delta) notifications.

\n

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

Remove separation between primary and routed IP subnet when retrieving from cooldown.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

Users would now get any subnet returned if one exists in cooldown. There is no longer a difference if the block was previously a primary or routed subnet.

\n

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

Move from imp Redis container to redis1.imp.nextpertise.nl. Instead of using a local Redis container, now use the persistent test/prod Redis server.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

None

\n

Bugfix release

\n

Issue's/PR's:

\n\n

Summary

\n

Fixes the cron-administration-diff cli command that got broken by the customer/profile change.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

None

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 5, "publishPending": false, "updatedAt": "2024-02-08T15:17:39.382Z" }, "title": "8 February 2024", "slug": "8-february-2024-1", "body": "# Bugfix release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nScore was sometimes unable to connect to Redis, resulting in a timeout exception. Score now initiates the Redis connection with a health check interval and socket timeout, which will hopefully prevent the connection from getting stale and closing.\n\n## Impact\n\nNone\n\n## User Visibility\n\nNone", "type": "", "hidden": true, "revision": 2, "_id": "65c4f093bf816a00534db539", "createdAt": "2024-02-08T15:17:39.195Z", "updatedAt": "2024-02-08T15:17:39.195Z", "lastUpdatedHash": "0d322d1dee12556345065d41b441e8390bbc30e0", "__v": 0, "html": "

Bugfix release

\n

Issue's/PR's:

\n\n

Summary

\n

Score was sometimes unable to connect to Redis, resulting in a timeout exception. Score now initiates the Redis connection with a health check interval and socket timeout, which will hopefully prevent the connection from getting stale and closing.

\n

Impact

\n

None

\n

User Visibility

\n

None

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 10, "publishPending": false, "updatedAt": "2024-02-08T10:45:45.516Z" }, "title": "8 february 2024", "slug": "8-february-2024", "body": "# Feature release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nIn the add profile dialog changed the label for the checkbox from 'Radius Managed' to 'Managed Radius' and the checkbox is now enabled by default.\n\n## Impact\n\nNone\n\n## User Visibility\n\nUpdated label and checkbox is set when adding a new profile.\n\n# Bugfix release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nThe setting for managed radius was not properly send to the backend, causing it to never be actually set.\n\n## Impact\n\nNone\n\n## User Visibility\n\nThe managed radius setting is properly showing as true when setting it when adding a new profile.", "type": "", "hidden": true, "revision": 2, "_id": "65c4b0d9890f33005e57da4a", "createdAt": "2024-02-08T10:45:45.354Z", "updatedAt": "2024-02-08T10:45:45.354Z", "lastUpdatedHash": "1e4dac5c1e8d305476fa51c60b539639830eaf8c", "__v": 0, "html": "

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

In the add profile dialog changed the label for the checkbox from 'Radius Managed' to 'Managed Radius' and the checkbox is now enabled by default.

\n

Impact

\n

None

\n

User Visibility

\n

Updated label and checkbox is set when adding a new profile.

\n

Bugfix release

\n

Issue's/PR's:

\n\n

Summary

\n

The setting for managed radius was not properly send to the backend, causing it to never be actually set.

\n

Impact

\n

None

\n

User Visibility

\n

The managed radius setting is properly showing as true when setting it when adding a new profile.

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 10, "publishPending": false, "updatedAt": "2024-02-06T22:21:58.118Z" }, "title": "6 february 2024", "slug": "6-february-2024", "body": "# Bugfix release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nYesterdays release introduced an issue with the KPN comments not being properly read in due to a field name mismatch.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nShould no longer see an exception that was thrown \"Uncaught error while handling the message: ''UpstreamMessageCode' object has no attribute 'comment_code'\" when KPN sends a comment code in the XML response.\n\n# Bugfix release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nThis change sets the on_demand flag when we receive a NEW_SA message from KPN where the order_variant key in the XML is set to 'On Demand'. This will make sure that when an order is created directly in KPN, we still see the on_demand status in Incontrol and also this will make sure that, for instance when changing the wishdate, the on_demand flag will still be send along in the XML message towards KPN.\n\n## Impact\n\nShort, single `./restart.sh`\n\n## User Visibility\n\nWe should see on_demand be set to True if a NEW_SA message is received from KPN where the order_variant has 'On Demand' set.", "type": "", "hidden": true, "revision": 2, "_id": "65c2b1050e85490067c32e10", "createdAt": "2024-02-06T22:21:57.705Z", "updatedAt": "2024-02-06T22:21:57.705Z", "lastUpdatedHash": "d1b8cb7a569b913a6a2be4f93d996434b8300f1f", "__v": 0, "html": "

Bugfix release

\n

Issue's/PR's:

\n\n

Summary

\n

Yesterdays release introduced an issue with the KPN comments not being properly read in due to a field name mismatch.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

Should no longer see an exception that was thrown "Uncaught error while handling the message: ''UpstreamMessageCode' object has no attribute 'comment_code'" when KPN sends a comment code in the XML response.

\n

Bugfix release

\n

Issue's/PR's:

\n\n

Summary

\n

This change sets the on_demand flag when we receive a NEW_SA message from KPN where the order_variant key in the XML is set to 'On Demand'. This will make sure that when an order is created directly in KPN, we still see the on_demand status in Incontrol and also this will make sure that, for instance when changing the wishdate, the on_demand flag will still be send along in the XML message towards KPN.

\n

Impact

\n

Short, single ./restart.sh

\n

User Visibility

\n

We should see on_demand be set to True if a NEW_SA message is received from KPN where the order_variant has 'On Demand' set.

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 20, "publishPending": false, "updatedAt": "2024-02-05T23:09:06.943Z" }, "title": "5 february 2024", "slug": "5-february-2024-3", "body": "# Feature release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nForward Delta keepalives to Zabbix so we can monitor for lost connection of the message feed.\n\n## Impact\n\nNone\n\n## User Visibility\n\nNo\n\n# Feature release\n\n## Issue's/PR's:\n\n- \n\n- \n\n- \n\n- \n\n- \n\n- \n\n- \n\n- \n\n## Summary\n\nThis separates the customers and profiles, which will make it possible to share a profile between multiple customers. Up until now profiles always got created under a certain customer, which can cause a lot of replication.\n\n## Impact\n\nNone\n\n## User Visibility\n\nNo changes for Incontrol users, but in Admin a new menu item has been created under which profiles are listed. When editing a profile, it shows the page that before was shown when editing a profile on the customer page. Only addition at the bottom is a box that shows the list of customers using this specific profile. On the customer page you can still add/link these profiles via a dropdown selection.\n\n!!!NOTE!!!: This is first part of the changes required to fully be able to separate profiles from customers. So despite the explanation above, it is currently not the intention to already share a profile among multiple customers as this might cause issues internally. When a new profile is required for a customer, please first add a new profile via the profile menu and then link it to the customer via the customer page.\n\n# Feature release\n\n## Issue's/PR's:\n\n- \n- \n\n## Summary\n\nInternally we had a separate comment and error table for KPN. When adding more providers this structure would require similar tables for any other provider added. For this reason a generic upstream message table has been created, which will contain any comments or error messages for any provider we currently support or which we might add in the future.\n\n## Impact\n\nNone\n\n## User Visibility\n\nNo\n\n# Feature release\n\n## Issue's/PR's:\n\n- \n\n- \n\n- \n\n- \n\n## Summary\n\nWhen we recieve a 113 message from Delta it means the order can no longer be cancelled (as provisioning has already been stated), which means the order should just stay in the current state. This message was not handled properly up until now. \n\n## Impact\n\nNone\n\n## User Visibility\n\nUsers should see that if they requested the order to be cancelled and it's no longer possible, the order just stays in the current state. Users should also recieve a notification that the cancel was not possible.", "type": "", "hidden": true, "revision": 4, "_id": "65c16a84e3a691000fe69699", "createdAt": "2024-02-05T23:08:52.523Z", "updatedAt": "2024-02-05T23:09:06.766Z", "lastUpdatedHash": "cd41f3c0becf99ca63cce99bb300d5bf86aa4b4c", "__v": 0, "html": "

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

Forward Delta keepalives to Zabbix so we can monitor for lost connection of the message feed.

\n

Impact

\n

None

\n

User Visibility

\n

No

\n

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

This separates the customers and profiles, which will make it possible to share a profile between multiple customers. Up until now profiles always got created under a certain customer, which can cause a lot of replication.

\n

Impact

\n

None

\n

User Visibility

\n

No changes for Incontrol users, but in Admin a new menu item has been created under which profiles are listed. When editing a profile, it shows the page that before was shown when editing a profile on the customer page. Only addition at the bottom is a box that shows the list of customers using this specific profile. On the customer page you can still add/link these profiles via a dropdown selection.

\n

!!!NOTE!!!: This is first part of the changes required to fully be able to separate profiles from customers. So despite the explanation above, it is currently not the intention to already share a profile among multiple customers as this might cause issues internally. When a new profile is required for a customer, please first add a new profile via the profile menu and then link it to the customer via the customer page.

\n

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

Internally we had a separate comment and error table for KPN. When adding more providers this structure would require similar tables for any other provider added. For this reason a generic upstream message table has been created, which will contain any comments or error messages for any provider we currently support or which we might add in the future.

\n

Impact

\n

None

\n

User Visibility

\n

No

\n

Feature release

\n

Issue's/PR's:

\n\n

Summary

\n

When we recieve a 113 message from Delta it means the order can no longer be cancelled (as provisioning has already been stated), which means the order should just stay in the current state. This message was not handled properly up until now.

\n

Impact

\n

None

\n

User Visibility

\n

Users should see that if they requested the order to be cancelled and it's no longer possible, the order just stays in the current state. Users should also recieve a notification that the cancel was not possible.

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 1, "publishPending": false, "updatedAt": "2024-02-05T20:48:11.904Z" }, "title": "5 February 2024", "slug": "5-february-2024-2", "body": "**Infrastructure release**\n\n**Summary** \nRouting for api.nextpertise.nl was changed to accommodate for the new score api. \nIMP now has a regex for paths that lead to app2.prod, same goes for documentation. \nThe catch-all will now be routed to score instead of IMP.\n\n**Impact** \nNone\n\n**User Visibility** \nNot directly for customers but api.nextpertise.nl/openapi.json is now available for the public containing the score api docs.", "type": "", "hidden": true, "revision": 2, "_id": "65c1498bd1656b005f66b119", "createdAt": "2024-02-05T20:48:11.740Z", "updatedAt": "2024-02-05T20:48:11.740Z", "lastUpdatedHash": "a7a4a1d97818092337511897f5cc6708b803fcba", "__v": 0, "html": "

Infrastructure release

\n

Summary
Routing for api.nextpertise.nl was changed to accommodate for the new score api.
IMP now has a regex for paths that lead to app2.prod, same goes for documentation.
The catch-all will now be routed to score instead of IMP.

\n

Impact
None

\n

User Visibility
Not directly for customers but api.nextpertise.nl/openapi.json is now available for the public containing the score api docs.

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 1, "publishPending": false, "updatedAt": "2024-02-05T12:46:18.313Z" }, "title": "5 February 2024", "slug": "5-february-2024-1", "body": "**Feature release**\n\nIssue's/PR's:\n\n- \n- \n\n**Summary** \nWhen an offer is turned into an order, do not display the text when it's expired in red color. \n\n**Impact** \nNone\n\n**User Visibility** \nYes\n\n[block:image]\n{\n \"images\": [\n {\n \"image\": [\n \"https://files.readme.io/f09f184-issue-814.png\",\n \"\",\n \"\"\n ],\n \"align\": \"center\"\n }\n ]\n}\n[/block]", "type": "", "hidden": true, "revision": 2, "_id": "65c0d89ab4d77e006316f1f7", "createdAt": "2024-02-05T12:46:18.169Z", "updatedAt": "2024-02-05T12:46:18.169Z", "lastUpdatedHash": "371a83761c91f0e6f408a6f7b37d32882198de7c", "__v": 0, "html": "

Feature release

\n

Issue's/PR's:

\n\n

Summary
When an offer is turned into an order, do not display the text when it's expired in red color.

\n

Impact
None

\n

User Visibility
Yes

\n\n
\n
\n\t
\n\t
\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 1, "publishPending": false, "updatedAt": "2024-02-05T10:23:21.796Z" }, "title": "5 february 2024", "slug": "5-february-2024", "body": "**Bugfix release**\n\nIssue's/PR's:\n\n- \n- \n\n**Summary** \nFor English, an old message with html tags was shown to the user. At the same time the description for both Dutch and English got updated.\n\n**Impact** \nNone\n\n**User Visibility** \nYes\n\n[block:image]\n{\n \"images\": [\n {\n \"image\": [\n \"https://files.readme.io/5af0ee4-issue-811.png\",\n \"\",\n \"\"\n ],\n \"align\": \"center\"\n }\n ]\n}\n[/block]", "type": "", "hidden": true, "revision": 3, "_id": "65c0b70fe6a25400116d3a9b", "createdAt": "2024-02-05T10:23:11.837Z", "updatedAt": "2024-02-05T10:23:21.629Z", "lastUpdatedHash": "46a918389664a3afc3f213d23b5d9d4c7d9366a2", "__v": 0, "html": "

Bugfix release

\n

Issue's/PR's:

\n\n

Summary
For English, an old message with html tags was shown to the user. At the same time the description for both Dutch and English got updated.

\n

Impact
None

\n

User Visibility
Yes

\n\n
\n
\n\t
\n\t
\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 1, "publishPending": false, "updatedAt": "2024-02-04T21:08:28.922Z" }, "title": "2 february 2024", "slug": "2-februari-2024", "body": "**Feature release**\n\nIssue's/PR's:\n\n- \n- \n\n**Summary** \nAdded a new notification template for generic updates. This template will soon be called by b2bemail: . Changes in this release are not yet visible to customers.\n\n**Impact** \nShort, single `./restart.sh`\n\nExample generic update notification - Deltafiber planning confirmation - b2bemail PR #49 (Not yet released):\n\n![](https://files.readme.io/f34447b-image.png)", "type": "", "hidden": true, "revision": 4, "_id": "65bfb0207848cf004f6aff39", "createdAt": "2024-02-02T19:41:00.000Z", "updatedAt": "2024-02-04T21:08:28.743Z", "lastUpdatedHash": "e4e9d2fe4425317e05da059bc6d69588aba004be", "__v": 0, "html": "

Feature release

\n

Issue's/PR's:

\n\n

Summary
Added a new notification template for generic updates. This template will soon be called by b2bemail: https://github.com/Nextpertise/b2bemail/pull/49. Changes in this release are not yet visible to customers.

\n

Impact
Short, single ./restart.sh

\n

Example generic update notification - Deltafiber planning confirmation - b2bemail PR #49 (Not yet released):

\n

\"\"

\n\n
" }, { "metadata": { "image": [], "title": "", "description": "", "keywords": "" }, "algolia": { "recordCount": 1, "publishPending": false, "updatedAt": "2024-02-04T15:40:04.814Z" }, "title": "31 januari 2024", "slug": "31-januari-2024-1", "body": "Security release: \nZojuist een release van kong docker image. Tijdens het testen van het Keycloak project (release van afgelopen maandag) zijn we tegen de volgende twee bug’s aangelopen:\n\n- De basic auth token cache key bevatte niet het IP-adres waardoor de cache key gedeeld werd. In de praktijk betekent dit als de cache entry bestaat er geen IP whitelist controle wordt uitgevoerd\n- Kong cache resurrection issue. Als een gebruiker probeert in de loggen, en dit niet lukt, werd dit door Kong gezien als een cache lookup fail. Als de cache was verlopen, maar het object nog wel in memory was (in de praktijk tot de volgende productie release) werd het cache object gebruikt. In de praktijk betekent dit dat: \n o Als je wachtwoord wijzigt, je nog kan inloggen met je oude wachtwoord \n o Als je IP whitelist entry verwijderd, je nog steeds kan inloggen\n\nBeide issues zijn met de release van vandaag verholpen.", "type": "", "hidden": true, "revision": 2, "_id": "65bfafd4878c1a005b24ec1d", "createdAt": "2024-01-31T19:39:00.000Z", "updatedAt": "2024-01-31T19:39:00.000Z", "lastUpdatedHash": "9dddae8cfe7334ff4f8ff9a5c537a3bb35f894a2", "__v": 0, "html": "

Security release:
Zojuist een release van kong docker image. Tijdens het testen van het Keycloak project (release van afgelopen maandag) zijn we tegen de volgende twee bug’s aangelopen:

\n
    \n
  • De basic auth token cache key bevatte niet het IP-adres waardoor de cache key gedeeld werd. In de praktijk betekent dit als de cache entry bestaat er geen IP whitelist controle wordt uitgevoerd
  • Kong cache resurrection issue. Als een gebruiker probeert in de loggen, en dit niet lukt, werd dit door Kong gezien als een cache lookup fail. Als de cache was verlopen, maar het object nog wel in memory was (in de praktijk tot de volgende productie release) werd het cache object gebruikt. In de praktijk betekent dit dat:
    o Als je wachtwoord wijzigt, je nog kan inloggen met je oude wachtwoord
    o Als je IP whitelist entry verwijderd, je nog steeds kan inloggen
\n

Beide issues zijn met de release van vandaag verholpen.

\n\n
" } ], "pagination": { "per_page": 10, "page": 1, "total_records": 0, "total_pages": 0 } }