I've lost the ability to edit a bucket's permissions ( I want to enable a bucket to be publicly readable ), but I cannot seem to fund the old icon that used to be clicked on to edit permissions ( the 3 vertical dots ). They seem to have disappeared after one of the last cloud console design updates.
Here's a shot of one of my test projects:
This is from the docs
Where did those 3 little dots go?
I am logged in as the project owner and seem to have complete control of the project.
Sorry for the not very code-centric question, but its been puzzling me for a while now.
If you're missing the bucket menu options (the 3 vertical dots), it might be because:
you haven't enabled billing for your project, which is required to start using Cloud Storage
you don't have sufficient permissions to edit the bucket's permissions or metadata
Related
My company is moving to DevOps and Azure Boards from our previous environment in JIRA and we've encountered a very big issue with permissions.
At the moment, we have configured various Areas to support our development teams; we also have an Area dedicated to the Product team, where business requirements are first input and then reviewed. Each team has permission to edit work items in its own Area and it can't edit work items in other areas.
So, basically this is our structure:
Engineering: the main Area of the project; only administrators can edit work items
Engineering\Mobile: child area for the Mobile team; only members of the Mobile team and administrators can edit work items
Engineering\Backend: child area for the Backend team; only members of the Backend team and administrators can edit work items
Engineering\Device: child area for the Device team; only members of the Device team and administrators can edit work items
Engineering\Product: child area to review business requirements that are then moved to the appropriate area; everybody can edit work items
Now we're trying to give anybody from any team the permission to comment (aka. use the "Discussion" section) a work item regardless of the Area where it is, but it looks like the ability to comment is strictly related to the permission of editing the work item… In other words, we haven't been able to enable the Discussion section without giving the permission to edit a work item, which isn't ideal.
Is there a way to enable the Discussion section for anybody while keeping editing restricted?
Unfortunately, it's not able to do this in Azure DevOps at present.
Unless you give the users permission "edit work items in node" permission, otherwise he will not be able to comment in the discussion field separately.
There is already a user voice here--Add support for for/not rules in the inherited process model
According to our PM's reply:
We currently do not have any plans enable field level security. But we
will continue to track this suggestion. If we begin to see more votes
we will take it under further consideration.
You could vote that ticket and track the process. Sorry for any inconvenience.
I created a trivia app in Google Actions following this link. I followed all the steps but when trying to submit for production (officially launch the Action to all the Google Assistant users) I get the following error:
I double checked all the constrains they suggest in the tutorial (like using photos of a specific size, having proper Privacy Policy and Terms of Service , checking that the app name is not taken etc).
One thing to mention: this is not a network issue, as I tried from multiple PCs and networks.
Is there a log file where I can look and pinpoint the issue? Or somebody else encountered this issue?
As suggested I've reached out Google support team (https://developers.google.com/actions/support/) . They answered really fast.
The fix was simple: make another copy of the spreadsheet used and try again.
Good afternoon,
I'm having some issues with VSTS and i am unable to find a single reference to anyone else experiencing this issue.
We use Microsoft's Test and Feedback browser extension for our support team and developers to add useful screen shots or walk through videos of bugs and tasks into VSTS.
This is affecting everyone except me (i'm administrator) which leads me to think this may be a permission issue that i am not finding the settings for. But certain images added to tasks or bugs are broken for my developers - as if they do not have permissions to view them. And as i said they display fine for me.
UPDATE:
I believe this is directly related to Test and Feedback images that have the following URL: xxxxxxx.visualstudio.com/DefaultCollection//TestManagement/v1.0/…?..... When user clicks the broken image they get:
"You do not have the appropriate permissions to read to the project."
This makes no sense because they are able to read other tasks and image in the same project, including other tasks with images generated by Test and Feedback. It does not appear to be happening with directly uploaded images.
Additionally i have some users who are unable to use the # tagging in comments in VSTS, whihc i suspect is also a permisisons issue.
What permissions do i need to give (if any) to allow users to view images added to bugs and tasks via Test and Feedback or allow users to tag other people in comments?
Thanks
There has no additional permissions to view images in work items (such as bugs or tasks).
If the images are not display when you open a work item, please check the browser you are using. Options you can have a try as below:
Use another web browser to check if the images can be displayed.
Clear browser cache and cookies etc, then open a work item again.
I have 3 BlueMix accounts, each with at least one organization. I am in an account with two organizations, and see no way of switching. each org has at least one space. This used to be part of the menu options but I no longer see it?screenshot of menu
The option has moved in the new console layout. Use the menu in the top left to get to the dashboard, then along the top you should see your resource groups, regions, orgs and spaces listed and be able to get where you need to go. Hope that helps!
Ok, I found it - for anyone who wants to reference, enter image description heresee the snapshot below...
I'm having a very interesting problem w/ content appearing on my publish instance. Let me just run down the situation and see if anyone can help.
I have an author and publish instance set up.
Authors have and still do successfully replicate items from Author to Publish with no issue.
All of my code base has been migrated over, my jars are fine -- i even rebuilt the individual jars in the publish instance crx just to make sure.
------- now for the issue.
I went to publish a new page and it did not show up on the publish instance. It's not a new template or component type, just another page to add to the list. These are the actions I took and what i found. I currently have 2 publish instances set up, but will refer to them synonymously as "publish" since their states appear to be identical.
Activated to publish -- did not show up in publish
logged into publish/crx/de/index.jsp to make sure it was replicated properly.
the content did make it fine and is in the proper path in /content
The ACL and access control permissions are the same as all the other content nodes of the same type. (Just to note, those content nodes are perfectly viewable).
No stacktrace errors in my logs. However, when going through the dispatcher I get this error: org.apache.sling.servlets.get.impl.DefaultGetServlet No renderer for extension js, cannot render resource JcrNodeResource, type=XXX, superType=null, path=/content/XXX/jcr:content
I went ahead and logged in as admin in my publish/crx/de and hit the content page in question and everything looked fine. What this means is the content is available to administrators but not anonymous users.
edit: I made sure to check the anonymous context in all 3 instances -- both publish instances directly and through dispatcher.
From here I figured it had to be an issue w/ the access control, but the new node has identical permissions to nodes that are available to the anonymous user context.
To check if it was a matter of replication, I went and deactivated some of the other similar nodes, saw they disappeared, reactived them and saw them come back. Following this train of thought I deactived the group (old nodes + my new node) and then reactived them -- all the old nodes showed up, and still the same permissions issues w/ the new node.
Is the access control available anywhere else? I'm curious if there are other places for me to look at in order to figure out what's wrong with this piece of content.
thank you,
Brodie
You can set "read" permissions for the group "everyone". Ultimately, you will want to put a dispatcher in front of your publishers, and prevent public access to your publish instances directly (preferably sitting behind a VPN).
This means that your dispatcher will be denying access to /apps anyway, and your instances will still be secure, and the ACL for the publisher won't really matter as long as an anonymous user can render the page under /content
Have you tried hitting the page directly as an anonymous user on the publisher (bypassing the dispatcher)? That would help you rule out whether it is a dispatcher issue.
This article may also help: http://forums.adobe.com/message/4263731 It include this:
"The issue was that after creating a new site on an author instance,
when viewing it on the publish site the page was not rendering
correclty. The visible symptom was that initial HTML tags (for HTML,
HEAD, META, and BODY) were being generated, but the content was not be
filled in. I did Activate my content properly, however, because it
was a new site, and I had generated new components and site templates
which resided in the "apps" folder and assets in the "etc" folder,
they were not available to be rendered and so the HTML page was blank
(because they could not be found on the publish instance). What I did
was use the "Activate Tree" under the Tools section to publish content
in /content/mysite. What I missed was using the Activate Tree to
publish items I had created in /etc/designs/mysite and /apps/mysite."
So this is on solution I found, but I don't feel like it is the best solution.
The root issue was that access control was restricted on the Views of the component. This is because /apps has a default deny to read for the "Everyone" group.
I changed this, but was told that of cq5.4 this was put in as a security precaution.
So as this fixes my problem, I fear it may introduce new ones. I'd like to get some more responses before resolving this out.
WEN U ZIP FROM PACKAGE MANAGER FOR USER AND GROUP PERMISSIONS ADD ALL THE NODES WHICH U HAVE WITH THE NAME OF "REP:POLICY"'S AND INSTALL IN NEW CQ