Turning off "Inherit permissions from higher levels" programmatically - permissions

I am trying to setup some group maintained folders that should not be seen by the other groups. Currently, I achieve that by un-clicking the "Inherit permissions from higher levels" check-box in the ##sharing tab, but I would like to automate this.
I could not find anything about this in the documentation or googling. After searching around the eggs directory I found some interesting things about 'ac_inherited_permissions' but nothing jumped out at me as my solution.
I'd like to do something like obj.inherited_permissions = False, or call whichever function I need to.
Any ideas?

The sharing tab only affects local roles. These usually are inherited from parents (acquired), but you can explicitly block these by setting __ac_local_roles_block__ to True on an object.
Make sure, however, you set this on the unwrapped object (no acquisition context):
from Acquisition import aq_base
aq_base(object).__ac_local_roles_block__ = True

Related

Setting to follow Unison's recommended action

I use unison to sync a couple of directories between my laptop and desktop. Whenever there are new files on one system, I have to confirm each one individually:
<--- new file c [f]
I've scoured through the docs, but I can't seem to find a setting that will just auto-accept unison's recommendation. Is there one?
Yeah, the option -auto is what you're looking for. From the documentation:
auto
When set to true, this flag causes the user interface to skip asking for confirmations on non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)
Also of interest:
batch
When this is set to true, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.

Correct terminology for Dead Man Switch

I've implemented a Dead Man Switch this way:
A script can be fired by an event. When the script starts it looks for a specific object on an S3 bucket. If that object can't be found for any reason (be it network issues to access the bucket, lack of permissions, the object was removed or any other reason) then the script will abort before doing any other actions.
I suppose this is a classic Dead Man Switch.
The idea is to let us remove this object in case we need to stop the script in an emergency.
My question is about terminology - I also supply a script to our team to create or remove that S3 object. I want it to be clear which actions means what (remove object - stop script from doing anything, create object - let the script continue with its work). I used "removed" and "reinstate" and was told this is too ambiguous. I now contemplate about "pushed" and "enabled" but this too sounds too vague. I'm also thinking about "pulled" (object removed) vs. "rearmed" (object created).
It's important that the terminology will be clear since if this script is used then this is expected to happen during emergency, so we want to minimize confusion as much as possible.
I suppose the problem is the inherent "double negative".
So far I didn't find any common name used to describe these actions. Wikipedia and other places describe what the switch is, but not actions of enabling or disabling it.
Any ideas?
I would say that the system would be:
Enabled if the object is present
Disabled if the object is absent
Placing the object would enable the script.
Removing (deleting) the object would disable the script.
You could even call the file enable-xxx-script to make it more obvious.

How to register a Property Handler on folders?

I built a virtual filesystem (not a namespace extension) for Windows which acts as a frontend of our document management server consisting of files and folders. In order to be able to display some metadata of the DMS objects in Windows Explorer as additional selectable columns, I successfully provided properties to the Windows Property System by implementing a COM Property Handler. Wheras normal property handlers focus on specific file types for which they feel responsible, my Property Handler adds properties to all files regardless of their type. Because Property Handlers can only be registered on the file type level, I registered my handler for about 30 types under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PropertySystem\PropertyHandlers\<.Extension>
However, I did not manage to register the Property Handler for folder objects. Since all objects in our file system are virtual I build the property store (IPropertyStore) by implementing IInitializeWithFile instead of IInitializeWithStream. The properties are requested from our DMS with the path of IInitializeWithFile acting as key and were not read from an objects content. This concept would work for folders as well.
For getting called on folders I tried to associate the handler by registering under different well known identifiers like Folder, Directory, AllFileSystemObjects and * instead of the file extension without success.
I also didn’t find anything in the MSDN documentation regarding this aspect.
Is there a way to register a Windows Property Handler on folders? Or is there some other way to add custom columns to folders in Windows Explorer?
I'm not sure if it is possible to do this.
Property handlers are clearly not the right approach, they are system wide and there can only be one per file extension. They should only be implemented by the software that "owns" the file extension and can parse the file to extract properties.
The old column handlers would have been your best bet (IMHO) but they are officially dead and you already said you can't use them.
Have you considered creating a namespace extension? Either as a root item somewhere (Desktop or My Computer) the way My Documents used to work in 2000/XP or maybe something more along the lines of how OneDrive works?
I'm not sure if desktop.ini files work in the root of a drive but it might be worth looking into. You would then find yourself in the poorly documented land of [.ShellClassInfo] and its CLSID, CLSID2 and UICLSID members. The general idea would be to act as a IShellFolder proxy on top of the "real" IShellFolder so you could create a multiplex property store. I think there are some (undocumented?) property keys you can override to change the folders default columns and tooltips as well.
There is also something called a delegated folder that allows you to play with nested PIDLs but the documentation is once again pretty useless so I'm not sure if this is something worth looking into.
A 3rd option is to pretend to be a cloud storage provider. I don't know if this gets you any closer to your goal and you would still have to implement some NSE bits to get to the point where you can layer yourself on top of the underlying IShellFolder. This feature is rather new and only documented to work on Windows 10.
The inner workings of how Explorer/IShellBrowser is connected to the IShellFolder/IShellView is one of the least documented parts of Windows. There are hundreds of undocumented interfaces. Explorer gives DefView special treatment leaving other 3rd-party implementations out in the cold.
My feeling is that there is no clean solution to implement this on top of a drive letter but you might get lucky, if Raymond Chen drops by he might have some tips for you...

Programmatically turn off an individual monitor

Is there an API or way to programmatically turn off an individual, external monitor via Objective-C on a Mac?
I'm looking to write a small menubar application that can control a secondary display (without a physical power button), but still keep the primary monitor in use.
Hunting around the API documentation, I can't seem to find anything, other then reading states. So hoping someone else might have an idea.
You can't "programmatically turn off an individual monitor", it's not physically possible. The most you can do is tell the OS to not use the monitor, but I don't think you can change system-wide settings like that, especially not at the level you're working on (Obj-C).
Looking at the Core Graphics API mentioned in #Halley's comment, try starting with the CGBeginDisplayConfiguration method and see if you can set a display configuration to your liking.
EDIT: Alternatively, you could also use CGDisplayCapture(displayID), which by default fills the captured display with black. You can then
call CGDisplayRelease(displayID) when you want to turn it back on.
It seems to be possible to sleep display so by I/O Kit:
https://web.archive.org/web/20161106204726/http://www.cocoabuilder.com/archive/cocoa/191807-sleep-display.html
http://explanatorygap.net/2009/01/31/a-screensaver-to-send-your-display-to-sleep/
But I am not sure whether it can control single monitors.

Item is not added into the list (from code)

We have some strange problem here. We have feature event receiver, where we are creating custom fields -> content type -> list. After that, one default item is added. On my VM it was working just fine, but after moving into pre-prod environment, we got this strange behavior with no exception or error in logs.
First thing, item was created only sometimes, with no trace what happened. Mostly it was not created. I even experienced this: when I activated feature, I went to the list and so item there, but after refresh it was gone!
We tried to put there some Thread.Sleep() cycle (while debugging, item was in Items collection, but ItemsCount property of the list was always showing 0).
Now I am out of ideas what is wrong. It's not about execution time (maybe). Looks like, for some reason, SP is killing SPItem.Update before it is created for real and we don't know why. Any help is really welcome!
When you try to access sharepoint items from code and not have admin permissions to update/ delete them then set website website.AllowUnsafeUpdates = true; property
//Set AllowUnsafeUpdates = true to update the database / sharepoint list from code.
FormWeb.AllowUnsafeUpdates = true;
NewItem.Update();
FormWeb.AllowUnsafeUpdates = false;
you code should be like this to make changes in the list.. when you adding item to list.
Use Update statement in same manner when you accessing list and updating its data.
Check whether you updating the list correctly.. There may be some SharePoint security issue.
Reference Link:
http://blogs.msdn.com/b/infopath/archive/2010/04/01/add-items-to-a-sharepoint-list-using-managed-code.aspx.
You can check this [SPSecurity.RunWithElevatedPrivileges][1]
[1]: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx , link, link
you can check that what is going over there by adding your events in sharepoint..
Check this post and debug it..
http://developmentsolutionsjunction.blogspot.com/2011/06/adding-events-and-eventhandlers-in.html
so I was finally able to find out where the problem was. After deeper study and trying that and this I found out that there was a third party feature. It was adding event to each created list and was deleting everything what wasn't consistent with CT defined by company. This is weird and I don't really understand why somebody wants this. But ok, they pay, their rules.
So if you encounter such problem, try also this possibility.
However, I also leard few things during this, e.g. if you are working with SP instances from web scope, use web scoped features, not site ones, also, SP has a nasty habit to silent som exceptions. Also, if you e.g. take instance of SPWeb from event properties, it doesn't necessarily means it is already created. It takes some time, also, Update() itself is a thing that DB has to perform. Sometimes it's better to alsways check if you really have instance and if not, threadsleep for a while.
Have you used .Update() method in your code??