Creating route objects just got a whole lot easier! Forget about hassle across organisations. Now you can submit the object with the passwords you have, and if it needs more, we will sort it out. The software will decide who else needs to authorise it and contact them. When they send in their passwords, we will match them up and create the object. Then we let everyone know the result – whether it’s a success or failure. Can it get any easier than this?
This feature will be deployed to the TEST database soon. Please note that we refer to route objects throughout this document, but all information also applies to route6 objects.
object requires multiple authorisations, often from different users. Currently this is done by sharing passwords, forwarding signed messages between users, or adding other users’ maintainers to your data objects. We looked at the problem from a different angle and came up with what we believe to be a better solution.
Let’s say a user wants to create a route object. Using the new approach, they can submit the update with the credentials they have to satisfy some of the authorisations needed. The software will then check if any required authorisations are missing from this update. If so, notifications will be sent to other users that this object needs to be authorised. If they agree, they supply their credentials. The software will match these up and create the object.
Queuing and authorisation
Route object creation requires two hierarchical authorisations as well as its own maintainer. Often these are not held by the same person or organisation. The idea behind this new approach is to submit the route object with whatever credentials you have. All the normal syntax and business rule checks are carried out on the object. If any of these checks fail, the object is returned to the user with error messages (as is the current case).
If all checks are successfully passed, we look at authorisation. If all required authorisation is included with the update, it will be processed immediately. If the authorisation for the object’s own "mnt-by:" fails, it will be returned as an error. If any of the credentials are missing for hierarchical authorisation, the object will be queued for up to one week.
When a route object is queued and pending some authorisation, notifications are sent to other users who have the missing authorisations. These users need to submit the exact same object and add the missing authorisation.
When the database software matches identical object texts, it checks to see whether the route object now passes all the required authorisations. If so, the object is created. If this does not happen within one week, the object is dropped from the queue.
There’s no longer any need for sharing passwords or passing update messages to others to sign. You can now just submit the update with whatever relevant passwords you have – and leave everything else to the software.