I need to check and add permissions on lots of folders, I was looking into using ReportService2010, but I have doubt regarding inheritance of security settings. In all examples I found online they are using:
$inheritParent = $true
in method
.GetPolicies($reportFolder, [ref]$inheritParent)
but this is not always the case.. sometimes folders have security setting independent from parent. Is there a way to check this setting using same assembly?
I have some doubts what exactly this does, I ran the same with $false and results were the same. Still I'd like to avoid breaking something when adding new user to folder.
I checked GetProperties and GetPermissions methods, but they do not return value I was looking for.
$inheritParent has to be initialized before it can be used with .GetPolicies. As you've already discovered, it doesn't matter what value you use. You can even set it to $null if you like, which might make it less confusing. You'll want to check the value after the call is made to determine if the policies returned are inherited or not.
The code found at https://github.com/microsoft/ReportingServicesTools might be useful to you. You can use it in its entirety or just as a reference.
Related
Compose - removeProperty(variables('Message')['Appointment'],'CustomerInfo')
What I want to see if the following.
I managed to recreate your issue without drama and unfortunately, I couldn't find a way to use the removeProperty function to make it work.
You have to call the function at the level it expects so it can remove a single named property and therefore, it only returns the level the function is called at which is, obviously, a problem.
This may not be the approach for you but to overcome this shortcoming, I used the inline Javascript action to do the work.
If you've never used the action before, you need to make sure set you flow up to use an Integration account. You can get one in the free tier so it doesn't cost you anything but may be limiting depending on the workload AND it's not supported for production workloads.
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-create-integration-account?tabs=azure-portal%2Cconsumption
This did give me the desired outcome though ...
Firstly, I have initialized variable and then used compose action with removeproperty(variables('emo')['appointment'],'customerInfo') as below:
Then I again used compose as below with removeproperty(variables('emo'),'appointment'):
Then I used Compose 3 for combing both composes as below using union(outputs('Compose_2'),outputs('Compose')) :
Output:
OR:
If you have integrated account Reference. Hope this clears all your doubts.
I'm getting an error when uploading my customized policy, which is based on Microsoft's SocialAccounts example ([tenant] is a placeholder I added):
Policy "B2C_1A_TrustFrameworkExtensions" of tenant "[tenant].onmicrosoft.com" makes a reference to ClaimType with id "client_id" but neither the policy nor any of its base policies contain such an element
I've done some customization to the file, including adding local account signon, but comparing copies of TrustFrameworkExtensions.xml in the examples, I can't see where this element is defined. It is not defined in TrustFrameworkBase.xml, which is where I would expect it.
I figured it out, although it doesn't make sense to me. Hopefully this helps someone else running into the same issue.
The TrustFrameworkBase.xml is not the same in each scenario. When Microsoft documentation said not to modify it, I assumed that meant the "base" was always the same. The implication of this design is: If you try to mix and match between scenarios then you also need to find the supporting pieces in the TrustFrameworkBase.xml and move them into your extensions document. It also means if Microsoft does provide an update to their reference policies and you want to update, you need to remember which one you implemented originally and potentially which other ones you had to pull from or do line-by-line comparison. Not end of the world, but also not how I'd design an inheritance structure.
This also explains why I had to work through previous validation errors, including missing <DisplayName> and <Protocol> elements in the <TechnicalProfile> element.
Yes - I agree that is a problem.
My suggestion is always to use the "SocialAndLocalAccountsWithMfa" scenario as the sample.
That way you will always have the correct attributes and you know which one to use if there is an update.
It's easy enough to comment out the MFA stuff in the user journeys if you don't want it.
There is one exception. If you want to use "username" instead of "email", the reads/writes etc. are only in the username sample.
Is there any built-in method or conventionally correct approach to this? I'm not asking about issuing an update, but rather, requesting one. I could query for it again, but the goal is that the object reference stay the same.
The approach I've taken so far is to define an instance method called "refresh" that gets the same resource instance by ID and then iterates over its properties, copying them over to the original object (how I love thee _.extend). But it seems like something that might already be included functionality in ngResource and I just can't find it. If not, does Angular provide a means to make such a "refresh" method default to all $resources the same way save, delete, etc already are?
So I actually found the answer as I was writing the question, but I'm going to post it and answer anyway in case it might help someone else.
While writing that and looking stuff up, I realized that get is not restricted to being a static method of the resource. What threw me here was that on an instance, it's named $get. And lo, $get does exactly what I wanted. However it does not seem to be documented on Angular's site -- in fact the site says that only non-GET actions are instance methods, so who'd have thought? I mean, aside from that it seems totally obvious now.
Is there a way to do some checks before allowing a merge in Mercurial?
I have found the pre-update hook and have a script that runs before an update is allowed, by adding the following to ~/.hg/hgrc:
[hooks]
pre-update = ~/hg_pre_update.sh
But I'd like to run the check before allowing a merge as well, and currently it just allows the merge to go through without running my checks.
Background
In case there are alternative ways to solve the problem...
We have been having a number of problems with 'lost' edits under Mercurial. I've tracked down most of them now to the same underlying cause: someone has vim edit sessions open while either they or someone else does a hg update or merge. The editor warns the file has changed externally, the user ignores the warning and saves their changes.
When these changes are committed, for Mercurial there is nothing controversial. The user has simply reverted all the changes brought in with the last update and put in their own changes.
Some time later, we notice the code has gone walkabouts. Cue assorted insults flung the way of mercurial...
Set vim to autoreload changes if no local changes where done. (otherwise ask, or force a merge)
that's how I avoid such issues in any editor...
Sorry just worked out there is a pre-merge hook that works just the same as pre-update. I tried it before asking the question, but now just looking at my hgrc I realise I put the script being called for that hook to ~/hg_pre_merge.sh which doesn't exist.
I can't find the existence of pre-merge documented anywhere but still feeling like a bit of a muppet now.
I am involved in using the C API to interact with Lotus Notes and Lotus Domino. I'm running into issues when reading existing Notes out of an NSF. Specifically, reading TYPE_OBJECT fields and even more specifically, $FILE fields (though I'm sure all TYPE_OBJECT fields would fail if I had any others).
I'm using NSFItemInfo to get the summary data on the $FILE field (so I don't need the saved file, I need information about it such as its size, name, etc...).
If I create the Note in memory, Commit it, then read the $FILE field, everything works. If I change my unit test to read an existing Note (instead of creating it in memory), Lotus PANICS with an Invalid Handle Lookup message.
So I'm left feeling like there is something different about loading those fields when I create a Note from scratch Vs opening one already created. Even reading in an already created Note that my own code created gives me the same error, so I think I'm creating the Notes correctly.
I've explored the NSFNoteOpenExt's flags options and have attempted to open the Note with every possible flag described in OPEN_xxx and I always get the panics except when I open the Note with OPEN_ABSTRACT or OPEN_NOOBJECTS. The reason those don't error though, is because they open the Note without the $FILE fields at all, so when I see if the field exists I get a false and the code to read in TYPE_OBJECT fields is never executed.
Any ideas what I'm missing?
I'd provide code, but I'm actually using .NET interop to accomplish all this, and the code is spread across multiple files, etc.... If you have any questions please ask and I'll provide as much detail as I can.
Craig
I figured out the issue. It came from the fact that when using interop in C#, you can't call C macros. OSLockBlock is defined as a macro to another macro to a function. Essentially, it locks the BlockId.Pool pointer, then increments the pointer by BlockId.BlockHandle. I was mis-interpreting that macro logic to be first increment BlockId.Pool by BlockId.BlockHandle, then lock.
Essentially:
Lock(BlockId.Pool)+BlockId.BlockHandle Vs Lock(BlockId.Pool+BlockId.BlockHandle)
It's interesting that the latter would work when creating a new note with new attachments. I finally figured that out as well, BlockId.BlockHandle was always zero when doing that. So that's why that always worked.