Though, whereas making this determination to make use of the iframe it appeared like the right one to do, as we might be capable of management the safety of the Canvas app by passing a parameter from the Mannequin-driven type into the app, that ended up being a crash and burn scenario as we wanted this to be obtainable on each Desktop and Cell functions. On the time of writing this text, Canvas apps embedded in iframes will not be accessible on cellular gadgets.
Even Scott Durow’s Ribbon Workbench, utilizing Good buttons has the power to open up a Canvas App in a brand new modal window, however that too has limitations because it is not going to work in cellular gadgets because of the Cross Area authentication restrictions which can be blocked by the Energy Apps cellular utility. You may vote for Scott’s assist request by clicking on the hyperlink under:
So, now that we had this subject, we needed to discover a approach to resolve it. As I discussed in my earlier publish, we had a fancy safety mannequin, which included the sharing of information, but additionally a customized applied tab degree safety which wanted to find out whether or not a read-only mode or a read-write mode of this app can be accessible to the tip consumer. All of this logic was executed by way of JavaScript, so it was very straightforward to go a parameter, however that wasn’t accessible by way of cellular system.
We consulted with Microsoft, and one strategy was to get all of the entities that make up that safety mannequin and write logic inside our Canvas app to cope with that safety mannequin. That will be an overkill.
The opposite strategy which we considered, was in fact that Energy Apps can name Energy Automate flows. We need to see if this could possibly be finished, and after thorough testing, we decided this could be a good selection. We wanted to jot down the JavaScript logic that may check tab degree safety into our movement, we wanted extra safety to examine whether or not the consumer the is logged in is the proprietor of the file or a member of any of the groups, we have to examine if the consumer had the right sharing privileges by way of principal object entry, which might additionally give us the standing of the file was read-only or not.
Many of the movement dealt with the tab degree safety, however the issue that we had was that we couldn’t question the principal object entry entity, and it’s not obtainable on the listing of entities inside of CDS.
Though, I used to be keen to begin “taking part in” with Customized APIs, I reverted to utilizing customized actions and plugin code to deal with the Principal Object Entry safety. For some organizations that you just work with, preview and new options require approvals.
So, I created a customized motion to examine whether or not consumer had the right sharing (Write Entry) and whether or not the consumer was an proprietor (or member of proprietor staff) of the file. For the reason that accessrightsmask return worth enumeration would return the sum of all potential entry rights which can be being shared with ta consumer, I used a BitArray with the intention to get the worth of Write Entry (2). The hyperlink under reveals the write entry sorts on the Microsoft Docs web site.
As soon as I created the capabilities and examined the logic, I handed the 2 parameters again from the Customized Motion of whether or not the consumer is the proprietor and the consumer has entry.
The code under reveals the code that may examine if the principal (consumer or staff) has the right entry within the principalobjectaccess entity.
non-public bool principalHasAccess(Guid principalId, Guid objectId, int place) { bool hasAccess = false; QueryExpression question = new QueryExpression("principalobjectaccess"); question.ColumnSet.AddColumns("accessrightsmask"); question.Standards.AddCondition("principalid", ConditionOperator.Equal, principalId); question.Standards.AddCondition("objectid", ConditionOperator.Equal, objectId); EntityCollection outcomes = Context.SystemOrgService.RetrieveMultiple(question); if (outcomes.Entities.Rely > 0) { foreach(Entity poa in outcomes.Entities) { int accessRightsMask = poa.GetAttributeValue int > ("accessrightsmask"); BitArray accessRights = new BitArray(new int[] { accessRightsMask }); hasAccess = accessRights.Get(place); } } return hasAccess; }
As soon as the movement was accomplished, the one factor that was left to do was name it from the Canvas app, and set the return variable as to whether the App ought to run as read-only and read-write.
The picture under reveals the short-term screenshot that was exhibited to the consumer whereas the safety movement was being executed
Now that we needed to undergo all this performance to implement this, my ideas had been that needs to be a manner that we are able to go parameters between a Mannequin-driven app and a Canvas app in a supported manner. Sadly, none that I’m conscious of (or my Microsoft contacts).
I created a brand new thought within the Energy Apps discussion board, so if you happen to assume that that is one thing that may be useful to you in future implementations, please vote up.
UPDATE: My good friend and fellow MVP, Alex Shlega simply posted a hyperlink on quering the Principal Entry Object from inside Energy Automate flows. Test it out if you’re on the lookout for that a part of the answer. Thanks Alex:
https://www.itaintboring.com/dynamics-crm/how-to-verify-principle-object-access-directly-from-the-flow/
