On a Plone 4.x install, can either
published content be restricted to a certain user/group or
private content be made to show in menus and searches for not-logged-in users ?
I have a customer who wants to be able to have content that can only be viewed by a certain user/group, but will show up in a menu or search when not logged in.
What would be the best approach for achieving this functionality?
You'll have to customize your workflow as below:
go to Zope Management Interface-> portal_workflow
Create a new state, let's say "Trailer" (this is optional, you could customize an existing state instead...maybe the private state would be a good option for dealing with restrictions for specific users/groups)
Remove all permissions but "Access contents information" from the Anonymous user in that specific state
Push the "Update security settings" button
Done!
Now all contents in the "Trailer" state will be searchable but not viewable by anonymous users.
Note: if you choose to create a new state, as I'd suggest, be sure to add all needed transitions too.
Edit:
Unfortunately I wasn't aware that in recent Plone's versions, there's a new index in the portal_catalog (allowedRolesAndUsers) that prevents the process above to work as it used to. The process above is still correct, though you'll need to override the default indexer.
First create a new package with paster using the "plone" template. Then add in the main level of the package (e.g. my.package/my/package) a file called indexers.py with this:
from zope.interface import Interface
from plone.indexer.decorator import indexer
from AccessControl.PermissionRole import rolesForPermissionOn
from Products.CMFCore.utils import getToolByName
from Products.CMFCore.CatalogTool import _mergedLocalRoles
#indexer(Interface)
def allowedRolesAndUsers(obj):
"""Return a list of roles and users with View permission.
Used by PortalCatalog to filter out items you're not allowed to see.
"""
allowed = {}
for r in rolesForPermissionOn('Access contents information', obj):
allowed[r] = 1
# shortcut roles and only index the most basic system role if the object
# is viewable by either of those
if 'Anonymous' in allowed:
return ['Anonymous']
elif 'Authenticated' in allowed:
return ['Authenticated']
localroles = {}
try:
acl_users = getToolByName(obj, 'acl_users', None)
if acl_users is not None:
localroles = acl_users._getAllLocalRoles(obj)
except AttributeError:
localroles = _mergedLocalRoles(obj)
for user, roles in localroles.items():
for role in roles:
if role in allowed:
allowed['user:' + user] = 1
if 'Owner' in allowed:
del allowed['Owner']
return list(allowed.keys())
and then in the same level add a file overrides.zcml with this:
<configure xmlns="http://namespaces.zope.org/zope">
<adapter factory=".indexers.allowedRolesAndUsers" name="allowedRolesAndUsers" />
</configure>
In the end the tree of your product should look like this:
my.package/
├── my
│ ├── __init__.py
│ └── package
│ ├── configure.zcml
│ ├── overrides.zcml
│ ├── indexers.py
│ ├── __init__.py
│ ├── profiles
│ │ └── default
│ │ └── metadata.xml
│ └── tests.py
├── README.txt
├── setup.cfg
└── setup.py
Last thing, you need to include the newly created egg in your buildout.cfg:
eggs =
my.package
develop =
src/my.package
Rerun buildout. That's all.
Related
I have the next tree:
root_project/
├── app
│ ├── default_photo_profile.jpg
│ ├── config.py
│ ├── __main__.py # My app are python package, I'm runnig it via "python -m"
│ └── ...
├── tests
│ ├── test_unit.py # import config.py inside
│ ├── functional # import config.py inside
│ ├── pytest.ini
│ └── ...
...
Currently default_photo_profile causing error because tests doesn't have this file.
Reading file in config.py:
DEFAULT_PHOTO_FILE_PATH = Path('default_photo.jpg')
with open(file=DEFAULT_PHOTO_FILE_PATH, mode='rb') as file_obj:
DEFAULT_PHOTO_BYTES = file_obj.read()
How I can solve this?
I tried:
Patch access to default_photo.jpg with fixture - not helped, error during import stage, not executiion.
set flag to pytest comamnd line: --rootdir app - not helped (don't know why).
try/except for reading the file in app.config.py - may help but it's not my intention, I really want raise error if file not found
Put default_photo.jpg inside EVERY test directory - will help bit dirty.
Patch os.path like suggested in https://stackoverflow.com/a/43003192/11277611 - dirty
Include tests into package (move __main__.py into root_project - not sure that it's a good idea (have not enough experience to decide).
Set absolut path to default_photo.jpg - will fail on the production server.
Probably adoptable solutions (What I want):
Set root dir to root_project.app somehow inside pytest.ini to immitate regular execution.
Set root dir to root_project.tests somehow to place file in root of tests and access from any of tests folder.
Try to use following code in config.py:
DEFAULT_PHOTO_FILE_PATH = Path(__file__).parent / 'default_photo.jpg'
with open(file=DEFAULT_PHOTO_FILE_PATH, mode='rb') as file_obj:
DEFAULT_PHOTO_BYTES = file_obj.read()
Is it what you are trying to achieve?
I'm a neophyte with Yocto, though I have been able to glean enough from tutorials to create an image that meets some of the requirements for my current project. I'm able to create my own layer and recipe so I can generate it with bitbake, e.g. bitbake mycustomimage.
I'm working with a beaglebone and the tutorials I've followed state you need the following layers:
meta-arm
meta-ti
poky (of course)
Just following the beagelbone tutorials will allow you to create a variety of prepackaged images from default recipes. However, tutorials and Yocto documentation do not explain how to access features and applications contained in the existing layers but are not utilized by the default recipes. I'm aware that you can use the IMAGE_FEATURE and EXTRA_IMAGE_FEATURE variables to add some (prepackaged) support.
I've come up with a way to add features from other layers by copying them into my custom layer directory structure and adding them to my customimage.bb file. This technique feels hacky and potentially error prone, also it duplicates files and directories found in other layers. My question is:
How are you supposed to add features from existing layers added to your project? For example I'll be needing PRU support for my beaglebone project, I know where those features are in the meta-ti layer (found in the recipes-bsp/ directory). How can I access that support and those features without a stupid hack? There must be a way.
Here's an example. I needed xorg-minimal-fonts installed, the recipe is contained in the poky/meta/recipes-graphics directory. I copied the contents into my custom layer which looks something like this:
mycustomimage
├── conf
│ └── layer.conf
└── recipes-core
├── images
│ └── core-image-mycustomimage.bb
└── xorg-font
├── encodings
│ └── nocompiler.patch
├── encodings_1.0.5.bb
├── font-alias-1.0.3
│ └── nocompiler.patch
├── font-alias_1.0.3.bb
├── font-util_1.3.2.bb
├── xorg-font-common.inc
├── xorg-minimal-fonts
│ └── misc
│ ├── 6x13B-ISO8859-10.pcf.gz
...(a bunch of zipped fonts)
│ ├── cursor.pcf.gz
│ └── fonts.dir
└── xorg-minimal-fonts.bb
My custom layer .bb file looks like this:
IMAGE_FEATURES_append = " x11-base ssh-server-dropbear hwcodecs"
IMAGE_FEATURES_remove = "allow-empty-password"
IMAGE_FEATURES_remove = "empty-root-password"
require recipes-core/xorg-font/xorg-minimal-fonts.bb
IMAGE_INSTALL = "\
packagegroup-core-boot \
packagegroup-core-full-cmdline \
${CORE_IMAGE_EXTRA_INSTALL} \
xorg-minimal-fonts \
"
inherit core-image extrausers
I know this is not how you're supposed do this, but it did work.
If you have a custom layer with a custom image, you can add any recipe that is in other layer.
If you copied xorg-font folder for that reason, it means that you need to copy all folders also of what you set in IMAGE_INSTALL.
You do not need to require the xorg-minimal-fonts recipe in the image recipe.
Also, IMAGE_INSTALL = .. will override the IMAGE_INSTALL of core-image class, so here is your custom image after some fixes:
# Inherit core-image because it already has:
#
# CORE_IMAGE_BASE_INSTALL = '\
# packagegroup-core-boot \
# packagegroup-base-extended \
# \
# ${CORE_IMAGE_EXTRA_INSTALL} \
# '
# ...
# IMAGE_INSTALL ?= "${CORE_IMAGE_BASE_INSTALL}"
inherit core-image extrausers
# Activate features
#
# Activate x11-base only if x11 is in DISTRO_FEATURES
IMAGE_FEATURES_append = " ${#bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11-base', '', d)}"
IMAGE_FEATURES_append = " ssh-server-dropbear hwcodecs"
IMAGE_FEATURES_remove = "allow-empty-password"
IMAGE_FEATURES_remove = "empty-root-password"
# Add custom recipes
IMAGE_INSTALL_append = " xorg-minimal-fonts"
my directory structure is
├── xxx
│ ├── 01.md
| └── 02.md
├── auth
│ ├── j1.json
│ ├── j2.json
│ └── j3.json
└── default.template.html
And I link jsons from markdowns like Auth. It makes sense as we use there files as test scenarios and in json files we have credentials and roles. But if I try to generate html it fails on unresolved internal reference: ../auth/aspect_admin.json. I tried to exclude the link checking but without any help. The best would be to leave it as a link in md file but somehow follow the link and include the json as code block in generated html. Is it possible?
It was a bug and will be fixed in next version https://github.com/planet42/Laika/issues/148
I would like to fake the LED (character device) of an embedded linux board (BeagleBone Black) in a user space library written in D.
Via the command line the led driver is represented to the user space as "device file" (e.g. for led "USER LEDS D2 0"):
debian#beaglebone:/sys/class/leds/beaglebone:green:usr0$ tree
.
├── brightness
├── device -> ../../../leds
├── invert
├── max_brightness
├── power
│ ├── async
│ ├── autosuspend_delay_ms
│ ├── control
│ ├── runtime_active_kids
│ ├── runtime_active_time
│ ├── runtime_enabled
│ ├── runtime_status
│ ├── runtime_suspended_time
│ └── runtime_usage
├── subsystem -> ../../../../../class/leds
├── trigger
└── uevent
Via the command line single entities like e.g. the brightness (turn on and off) can be written to and read from like files:
cd /sys/class/leds/beaglebone:green:usr0
echo none > trigger
echo 1 > brightness
echo 0 > brightness
I consider it reasonable to abstract the whole device as interface and implement a production class and a test class (hand-made fake object) which implements the interface. The client code of the library could then use either the production code or the fake class which could be injected using dependency injection.
Could a mock framework like https://github.com/QAston/DMocks-revived provide functionality to use a fake driver in client code out of the box instead of using the handmade fake led driver described above? (I guess to fake more complicated character devices it would be necessary to "hand-implement" anyway.)
Or are there better approaches to fake a character device (e.g. make the production class require a root path of the driver when creating an instance via "constructor injection")?
I am documenting a matlab code that I have with sphinx. I am using the package sphinxcontrib-matlabdomain.
My directory tree is as follows:
me:~/.../doc$ tree ../
../
├── doc
│ ├── conf.py
│ ├── make.bat
│ ├── Makefile
│ ├── index.rst
│ ├── BaseClass.rst
│ └── DerivedClass.rst
├── LICENSE.md
├── README.md
└── src
├── BaseClass.m
└── DerivedClass.m
The problem comes when I want to show inheritance diagrams. I have added the necessary things in my config.py file:
matlab_src_dir = os.path.abspath('..')
extensions = [
'sphinx.ext.autodoc',
'sphinx.ext.inheritance_diagram',
'sphinx.ext.graphviz',
'sphinx.ext.viewcode',
'sphinxcontrib.matlab',
]
primary_domain = 'mat'
And I have the following in the index.rst file
Welcome to BGK's documentation!
===============================
I am trying to have a diagram here...
.. inheritance-diagram:: BaseClass DerivedClass
:parts:2
.. graphviz::
digraph {
"From here" -> "To" -> "Somewhere";
"From here" -> "To" -> "Somewhere else";
}
And in the output the directive inheritance-diagram is ignored, obtaining directly the next diagram that I am using to test that I can plot diagrams.
Is there any incompatibility to plot inheritance diagrams with sphinx for matlab classes? Is there any way to go around the problem? Thanks!
Sphinx does not support this. The built-in sphinx.ext.inheritance_diagram extension is for the Python domain only. It does not work for Matlab. If it did, I'm sure it would say so in the Sphinx documentation (and a glance at the source code in sphinx/ext/inheritance_diagram.py confirms that it is only for Python).
The only way inheritance diagrams for Matlab could work is if some other extension provided the functionality. The sphinxcontrib-matlabdomain extension that you use does not.