I've somehow caused a Project created in Phabricator to have an edit policy which prevents me from administering membership, or making any other changes.
The Project History looks as follows:
<myusername> created this project
<myusername> added a member: <myusername>
<myusername> changed the visibility from "All Users" to "Subscribers"
<myusername> changed the edit policy from "All Users" to "Subscribers"
<myusername> changed the join poliy from "All Users" to "Subscribers"
<myusername> added members: <memberA>, <memberB>, <memberC>, <memberD>
<myusername> changed the visibility from "Subscribers" to "<ProjectName> (Project)"
The end result is now I'm unable to Add Members or Edit the Project in any way.
The database format is not quickly discernible. I'm digging through sources but wondering if someone else already has been through this.
Is there some standard method for viewing/editing Phabricator ACLs? I'm reviewing documentation also but the info is sparse.
Thankful for any insight!
You need to unlock the objects with ~/phabricator/bin/policy:
NAME
policy - manage policies
SYNOPSIS
policy command [options]
Administrative tool for reviewing and editing policies.
WORKFLOWS
help [command]
Show this help, or workflow help for command.
show D123
Show policy information about an object.
unlock D123
Unlock an object by setting its policies to allow anyone to view and
edit it.
Use help command for a detailed command reference.
Use --show-standard-options to show additional options.
To get the PHID of a project use the Conduit method called phid.lookup:
https://<phabricator-URI>/conduit/method/phid.lookup/
Now you can use the PHID like this:
~> ./bin/policy show PHID-PROJ-mwyszvfopzei2xfnncda
Related
After configuring Portal Site Map for a report I get Error#0. Please see details below.
Not seeing anything on this question - Can someone point me to the documentation on this. I've been told this has to be completed via a customization project - before heading down that path surely I'm not the first to want to expose a report.
Thank you.
Mark Mynatt
Error:
2/19/2019 10:13:15 PM Error:
Error: You don't have enough rights on 'QQ301000.rpx'.
The error message implies that the report is visible on the portal. That's a great start. If it isn't/weren't visible you would have to first add it to the portal files and then add it in the sitemap.
The error message suggests it is an Access Right problem that prevents access to the report. Make sure the report is visible in sitemap and then lookup screen Access Rights By Role (SM201025) to see if Portal User and Portal Admin have access right to the report. If it's Not Set, that could be your problem. Try giving higher access rights (delete is the most permissive right you can give):
I understood from icCube release notes that there is a $Monitoring Cube...
I cannot see it anywhere (not in the report designer nor in the MDX IDE...
Where should it be? in a $Monitoring schema?
Is there something to set up to make it available?
The $Monitoring schema is activated via a configuration settings within the file icCube.xml:
<monitoringConfigurations>
<counters>
<activated>true</activated>
...
Then you need to log in with a user with "administrator" role.
Hope that helps.
When I first created my Plone (4.1) site, I made a mysite.policy add-on to include some custom users and a custom workflow.
I need to make some corrections to both the workflow and the permissions. I updated the src to include these changes, but updating the package in through the Plone add-on manager (uninstall - install) does not work. As soon as I uninstall the status of all my entries switches to "local policy", so I cannot get the fine-grained status setttings back when I reinstall.
Also, the user permissions do not seem to change. Possibly because they were already created at set-up of the site. But I cannot figure out how to code a change to permissions versus a setup of permissions in the rolemap.xml. I assumed that whatever is in that xml is what rules my plone world, but that does not seem to be working.
So far I cannot find anything about this in the manuals and books I have at hand. Any hints how to solve this? Perhaps the only way to go about this is a series of manual changes through ZMI, but it is so much less elegant to do it that wat.
There's plenty of options. I'll try to describe a couple of them.
If your changes include only changes in Generic Setup profile of your site policy (./src/my/site/policy/profile/default/-files) and you don't want to automate the upgrade, you could simply update the profile-files and re-run those specific import steps for your policy:
Open ZMI (site/manage) for your site and look for portal_setup.
Select Import-tab when on portal_setup.
Select the profile of your site policy from Select Profile or Snapshot-list (the title of your profile is defined by the registerProfile-directive in configure.zcml or profiles.zcml of your policy product).
Click to select import steps for Role / Permission Map and Workflow Tool.
From the bottom of the page, deselect Include dependencies.
Click Import selected steps-button.
Go to portal_workflow-tool on ZMI and Update security settings, if your workflow update should modify permission in existing workflow states.
These steps should re-import only the selected import steps of you site policy product's Generic Setup -profile. Re-importing individual steps this way should be quite safe, but be careful: accidental clicks at portal_setup screens may have unpredictable consequences.
These steps can also be automated by defining something called Generic Setup Upgrade Step.
I hope that the default Generic Setup -profile of your site policy product includes metadata.xml with line <version>1</version>.
Update that line to <version>2</version>.
Open the zcml-file with registerProfile-directive and, after it, add
<genericsetup:upgradeDepends
source="1" destination="2" sortkey="1"
title="Upgrade my.site.policy (1 to 2)"
description="Upgrades my.site.policy's default profile from version version 1 to 2."
profile="my.site.policy:default"
import_steps="rolemap workflow"
run_deps="false"
/>
These steps should register such an upgrade step from the profile version 1 to 2, which re-imports steps rolemap and workflow (rolemap.xml and workflows.xml). You should be able to run the upgrade step from the Plone Site Setup's Add-ons-screen, where there should now be an upgrade button after your installed policy product.
As mentioned by #toutpt, the Collective Developer Manual has more examples on upgrade steps. If you have ever wondered, why it's recommended to use integers in metadata.xml, usually independently from the product's release version number', this is the reason :).
Any changes that need upgrade must be shown by increment the number in profile/default/metadata.xml (keep integer). Next you have to write an upgrade step. It will add an upgrade button in the addons control panel.
Please follow this tutorial to learn how to create an upgrade step: http://collective-docs.readthedocs.org/en/latest/components/genericsetup.html?highlight=upgradestep#upgrade-steps
I need to implement a workflow in my Drupal website. I have a simple workflow:
contributer: Who create nodes in draft status saves new versions of a node
publisher: Do the same as the contributer and change the state of the draft node to published status.
I'm confused between Maestro, Workbench and Workflow modules.
Does anyone know which one is the most appropriate in my case?
Thank you very much.
Regards.
For this approach no need any Contributor module.Login as admin give the create permission to the normal user(may be fall under some roles) expect "administer nodes".If we disable this permission to the particular role who will not get a option to publish the content.
I usually use Workflow module http://drupal.org/project/workflow.
1) What you need is to create workflow.
2) Create workflow states
3) Give required state change roles to the roles
4) Go to the Permissions, remove all permissions from the Node, for you will give them in the workflow settings page
Suppose I have two content typs, "Job Listing" and "Job Application". A job application has a field (using the CCK module) to reference the job listing (a required field). Suppose the job application has a field "Status" with values like "new", "accepted", "rejected".
I would like to set permissions so that the job application status can only be set by the creator of the job listing it corresponds to. If there is an addon that can do this great. I would also like general direction as to how a custom addon might implement this.
(I am following the scenario in Ch. 3 of O'Reilly's "Using Drupal")
I don't know if there is a module for this but this can be done pretty easily with some custom code though.
Use hook_form_alter to add your own validate handler to the node_edit form for the application content type.
Check to see if the value has changed
Set an error is user isn't the creator or has the administer content permission.
You're done.
Directions by googletorp are on the right track but you will have to take care of some more permissions also.
Remove the edit own permission for the application content type.
Also you probably do not want author of one job listing editing the applications in response to some other job listing. This is hard to do with any built in permissions. So check in the form_alter hook that current user is the same as the author of the job listing to which the application being edited is connected to.