I have made the User Provisioning to be based around Phones. Phones can have a Provision assigned to them. There is an ajax endpoint for it at [POST]/phone-provisioning/ajax/toggle-provision/{phone_id}/{provision_id}
This will respond with {success:true/false}
The phone edit page should contain a provision tab, that will show the available provisions that can be assigned to this phone.
The frontend can loop over each provision in $provisions in the edit page. You can then call $provision->isOnPhone(PhoneID) to return boolean about whether the provision you are looping is on the phone requested.
With this, I have added the edit phone to a user. This currently has all the available variables that is on the existing phone edit, but should probably have some parts of the UI disabled. With that, there's 2 ways, either we have a new view file or I can pass in a variable in the user one, use the same view file, and just check if that variable is true/false to enable/disable elements.
Below are the new routes. It will also require new elements in the menu.
The new phone edit for users get.phones.list.user // the new list get.phones.edit.user // the new get edit post.phones.edit.user // the new post edit
I have made some starter UI for the provision component, based off our original discussion in planning. Not much has changed since it.
The submission required is name= shared= configs[mitel-generic][uuid|int][parameter_name]=
Each of the available parameter types have their own partials, the most advanced one being button which will require some JS component. Right now I have it to always show all users, but that dropdown should be based off if the first dropdown has BLF. Right now, BLF is the only supported one. Research into the possibility for the generic buttons, found that panasonic, which would appear to be the next one we work on, only supports BLF or Speed Dial (effectively just BLF without the light) on their buttons.
So chances are, we will have to add some parameters to the generic buttons that are not supported on all devices, but it is possibly for us to not think about BLF as we may. Perhaps BLF could be renamed to User BLF/State and have further ones for other components. Queue BLF, Voicemail BLF or something.
There is also support for us to have each subsequent config tab define the same config name but more thoroughly. For example they could define key_1 in mitel-generic to have all the available options that a mitel button does, and on mitel phones it'll override that with the parameters defined in the mitel-generic tab.
Example: key_1 button in the generic tab, which only has BLF is saved. Someone that, in the mitel-generic tab, instead sets key_1 to be a XML button on Mitel Phones. He then starts the phone that is a mitel device, the code will merge all matching configs (generic, which matches all and mitel-generic because its a mitel phone) and then merges them in priority order. Generic is priority 0, mitel-generic is priority 1, so everything defined in mitel-generic overrides generic if the same key is found.
key_{x} is also unlimited. So our idea was to have a +/- system for the buttons that will just increment the number, key_1, key_2 etc.
The other parameters are relatively simple.
Flex will just use the provision specified as the default for each user. Seemed the easiest. I still need to properly support flex with provision blocks that could be assigned to a non flex and then to a flex. So in that example, it will remove that phone from the provision assignment. I still need to test what happens with flex login/logout. But if my thinking is correct, the check sync that it does should detect changes, since the server will find a user id now attached to the phone, and create the user provisioning file.
Each user, can set a default provision to use on all their devices, and then, if they want finer grained control, can assign each phone from their new phone/edit/user page a specific config, either one shared or one they made.
To set the default, an ajax route exists, that should only be accessible from the users provision list, and not the account one, since it looks at the auth user.
Route: [POST]/phone-provisioning/ajax/set-default/{provision_id}
You can check which provision is default for the user by doing the following inside the $provisions loop; $provision->isDefaultFor($viewAsUser->getID()) : boolean
Other than that, everything seems to be working. Delete is in place also. I have checked and seen it on the phones, but not since ive added support for expansion modules, which I will also need to check once we can make like 50 buttons to test the overflow of the buttons if use_expansion is enabled in the mitel-generic.
I dont think any further config sections are required, generic and mitel-generic should cover all for what we have now.