In memory Cockpits in SpagoBI 5 for different users - spagobi

We met a problem when we build an in-memory cockpits document for different users.
The problem is, user 'A' built a cockpit, and user 'B' (end-user) wanted to edit it as a template in his personal folder, but he doesn't allowed to do it. Some of the buttons like "add widgets" were missing.
We found that the authorship of this document still was user A, after it had been copied in user B's personal folder.
Is there any way we could edit the other user's in-memory cockpits as a template, like Qbe?
Thanks!

Related

SonarQube 6.0 authorization using groups

I am using SonarQube (SQ) 6.0 community version and trying to setup authorization using groups and project permissions. There doesn't appear to be a way to assign permissions to a created group, even though the defined SQ groups have permissions assigned to them. What I wanted to do was assign permissions to a created group via the Admininistration->Security->Global Permissions process. But this action only returns the Anyone and sonar-administrators defined groups based on the usage of the internal API api/permissions/groups, which only returns groups with permissions. This same API is used in the action Administration->Projects->Management->Actions->Edit Permissions. From this last action the goal was to remove permissions for this project from the Anyone group and allow permissions from a created group (which would apply to the users in that group). But that doesn't seem possible. I've looked at permission templates, but that doesn't seem to allow association to a group. What I'm really attempting to do is a common RBAC process, which SQ does not seem to support. Is there a solution in SQ for this capability?
Yup, the UI is very confusing in this area, I struggled for quite some time before realising what to do.
What you need to do is first search for a string in the search box ("sonar" is a good query), and then the list will be populated with all users/groups matching that query. You can then assign them permissions as you see fit.
There are two different concepts at work here. Global permissions grant users and groups the ability to make global-level changes, i.e. changes that effect everyone such as which plugins are installed and what rules are active in a Quality Profile. Project permissions grant users and groups the ability to see and change individual projects.
Once your group is created and populated, you have two options:
Edit Permissions of Individual Permissions
Give the group specific permissions to individual projects by navigating to the project, then Administration > Permissions. This could get tedious if you have a lot of projects to update.
Create a Permissions Template
Create a permission template (Administration > Security > Permission Templates) and populate it by granting the group specific permissions. At this point no permissions have actually changed.
Once your template is properly constructed, you can apply it to projects individually, en masse, and/or by default as new projects are created via the template's Project Key Pattern. You can also make your new template the default so that its settings are automatically applied to all new projects regardless of project key.
Note that there is no ongoing relationship between a Permissions Template and the projects to which it has been applied. Subsequently editing a template will not update the permissions of any project.

Do TYPO3 have a user configuration cache?

I have been watching a strange issue that is making me think that TYPO3 has a sort of user configuration cache and don't know how to clean it.
The website has some users and some groups of users. There are some extensions to manage records on tables.
Some of the fields of those extensions are of type "group" to reference files.
The strange thing is that the old users in the same group don't see the upload button in those fields, but when create new users in the same group they do see the button.
There is no difference between the configuration of the old and new users.
What might be happening?
More Info:
They are BE users and the problem is in the Web->List view.
No special modules and no disabled_controls in the TCA for those fields.
It is also interesting that if I duplicate an old user, the duplicated one is not able to see the buttons, either.
Images
This is how the old users see the fields:
And, this is how the new users see the field:
I would expect, that there are Options in TSUser Config or in user settings are set.
Have a look in TSConfig of that Users and Usergroups:
setup.default.edit_docModuleUpload = 0
setup.override.edit_docModuleUpload = 0
Perhaps it is set in the user settings:

Joomla 3: How to set different user permissions?

I currently have a Joomla site that has 5 different departments of people accessing the backend content. Basically, everyone's looking and poking at other departments contents. So how would I set a different account for everyone and allow them to only modify their own content? E.G.
The salt department can post whatever articles they want, but they cannot modify the sugar department's article.
Does Joomla have this kind of ability or any extensions out there?
That is pretty simple on Joomla 3 system.
Firstly, you create 5 different User Groups in Joomla under Users menu.
Go to Content > Article Manager > click Options button on the top right side > Permissions Tab
In the Permissions Tab, click on each User Group and you have tons of permission to tweak such as: Create, Edit, Edit Own, ...
Hope it helps.
If you haven't configured it yet, the key term to look for is ACL (Access Control List).
Basically you need to create 5 users groups (which are not Super Users).
Here is an article to get you started:
Joomla ACL: Configuring back-end ACL

Joomla 3.1 Front end editing - Deleting and article

I have set up user group called "Article Editor" with a parent of Administrator. Within that group I have a user of "Agent" and assigned them to the "Article Editor" User group.
I have a blog page in which when they are logged in they can create an article (only with a particular category called blog) and they can edit all articles, however, I cannot get any option anywhere to enable them to delete any article they have created within the "blog" category. I have gone into the article manage and made sure the permissions are set to enable Edit, Delete and Create.
Any ideas how I allow the user to log into the front end and have the option to delete? Ive tried everything I can think of an am going around in circles now.
The Delete permission should be given only to trusted administrators (with intended access to the back-end) and can be performed in the back-end.
From your description, you don't want this group of users to have access in the back-end and even more have delete permissions, as these users if they log-in to the backend they will be able to delete many things.
These users should be able to edit state (publish/unpublish) their own articles.
So, concluding:
Give this group only front-end access, with permissions similar to the author (core joomla group) with the addition of edit state.
So they will be able to create and publish/unpublish (**addition- or trashing) their articles.

Umbraco how to create account related pages?

I would like to create some pages related to a member account in umbraco 4.
In asp.net webforms, an account folder is created and in it are the account related pages, such as Login.aspx, ForgotPassword.aspx, etc...
Now, these pages are not actual content pages, but are more of the adminitrative type.
I've created user controls for the login, register, etc.
Should I create a document type in umbraco for each page type, and put the respective user control in each template ? what is the recommended way to do this in umbraco ?
On the content manager, just right click on the page or node you want to protect, right click on and select "Public Access".
In there you can apply permissions to individual users and/or roled based. The Roled based one will require for you to have "Member Groups".
That is it. All the security is kept on the "\App_Data\access.config" file; you can review it for more details on how they are achieving this.
hth,
-covo

Resources