I'm trying to configure a Bugzilla instance, which will allow my clients to login, and file bugs for their website under development/maintenance.
For e.g: I have created 2 products called "TestProject", "TestProject2" and a user called "TestClient". What I'm trying to achieve is when TestClient logs in, he can only see TestProject, TestProject2 and only add/modify bugs in there.
TestProject, TestProject2 should not be listed for any other client.
I believe this has do with granular controls in the 'Groups' administration section, however I'm unable to figure it out.
Thanks
You are on the right track. This is the process I use and it works well for me.
Create a group for each of you clients.
Create or edit the product the client will use.
On the edit products page click "Edit Group Access Controls"
Select the following for the Group you want to have access
Enable entry, member control = mandatory, other control = mandatory, enable can edit.
Create a user and add them as a member of the new group.
To use this method all bugs have to be associated with a group like this or the users would see their bugs and any non group specific tickets.
Related
I want to allow user to update data from form, but not from direct table. I added Before Change event on table, and raising error if the user group is 'basic'. This is working as expected if I enter data in table. But, it is also raising error even if saving data from form. Can anyone help me to resolve this issue?
Thanks in advance!
In general the way to deal with permissions in Access is to only ever show your users the forms; they should never directly interact with a table or query. So instead of adding Before Change code to your table, you instead want to hide the table.
The things you need are in the Current Database section of the Access options. For this example I'll assume you just have the one form, but the same applies if you have many forms and a "Home" form.
Use the "Display Form" dropdown to select the form you want the user to see when they open the application.
Un-check "Use Access Special Keys" to prevent keyboard shortcuts showing objects you don't want shown.
Un-check "Display Navigation Pane" to hide the object list.
Un-check "Allow Full Menus" to prevent users from creating new objects (or use other database development functions)
With this done, the user will see only the form interface you selected and the basic data entry toolbar.
Note that when you want to make changes to the file as a developer you must hold down Shift when opening the application, which will display the navigation pane etc. Of course, any user who knows about the Shift override could do the same. Which is why distributing in a compiled accde, which cannot be unlocked, is a good idea. But you need to set up the application using the above options before that matters.
I am trying to debug a weird issue with one user's roster in ejabberd.
He is having a roster group "_root" show up in his client (PSI).
The server is using mod_ldap for user authentication.
Things tried so far:
deleting the group from the client -> the group appears again after a while
unregistering the user with /ejabberdctl unregister user domain.com -> the group appears again after a while
Only one user is affected by this on the server, which makes me think it has to be something specific to this one user's settings (or client). But we have a bunch of people also using PSI with no problems.
Is there a way to look at the roster groups defined for a specific user in the database directly?
Thanks,
kaza
That "_root" value must come from the roster module data. You did not say which roster module you use, but I guess the server is configured to use mod_roster_ldap and possibly mod_shared_roster_ldap. Check the configuration of the module and explore the content of the LDAP directory to see if you see that value. I would think that value comes from there.
We have a closed wiki - and we want to set all existing users accounts to be confirmed. (when the user was added the email was added)
We also want to have that setting automatically set to true for new users.
What I want to do:
Default the email confirmed to true for all new users that we create/add
Set the email confirmed for all existing users without requiring the user to take any action
(I realize this may not be desirable however, it is a closed system and the emails have already been vetted/verified)
How can I achieve this?
EDIT:
I tried using the ImportUsers plugin - with the 'emailconfirmed' user group populated - but that did not work as I had hoped. It did work for other group names.
Is there a way I can get to the database directly?
To confirm all currently unconfirmed users you could run this query against the database:
UPDATE `mw_user`
SET `user_email_authenticated`= DATE_FORMAT(NOW(),'%Y%m%d%H%i%s')
WHERE `user_email_authenticated` IS null
The information to access your database should already be present in your LocalSettings.php file, you can access the database using the credentials saved there with a tool like Navicat or MySQL Query Browser
However, there seems to be no simple way already present in MediaWiki to automatically set newly registered users to confirmed.
There are some plugins that hook into the code when a new user is registered, so technically it would be possible to write an extension that does exactly what you want. Or you could run this query manually when you register a user.
It might help to also ask yourself - why do you need them confirmed?
I was in a similar situation and the answer for me was to remove this line from the server's LocalSettings.php:
$wgEmailConfirmToEdit = true;
Now my users don't have a reason to confirm their emails.
With the admin user I can do everything, add, delete, modify, etc. As it should be.
Then using this user added a new one, with full access to sales and accounting options as some other ones needed for sales operations. Then tried to add a new supplier and it throws a warning:
Access Denied
The requested operation cannot be completed due to security restrictions.
Please contact your system administrator.
(Document type: Pricelist, Operation: read)
Tested all the possible combinations on user rights and ended up giving full access to all options. Nevertheless I'm unable to create any new contact/customer/supplier/etc with this user. I'm running out of options, I don't know what else to test or where to look.
EDIT
Got an answer on the brand new OpenERP discussion site recommending to uncheck the Portal user rights for the user. Uncheking it partially worked. The warning still appears but when I click OK, fill the supplier and save, the new supplier is added without errors. Any recommendation?
I really think that's not a bug.
it's a conflict of "Rights" (in Access rules and ACL).
A "Portal or Anonymous" user, is an external user (from the company) and have only some limited rights for accessing some public informations or it can be an exteranl partner which can access his private documents and informations related to his relation with this company.
A normal OpenERP user (a company employee with some or all rights "let's call it an internal user") can't be and should not be in the same time a "Portal or Anonymous" user (with very limited rights), and vice-versa.
Just uncheck these two options for an internal OpenERP user.
Is a reported bug that seems to be related to multi-company option selection and user rights.
Go to multi company Access Denied Document type: Partner, Operation: read where the bug was reported and is followed up by other users. Hope a patch is created soon.
I agree, I don't think that's a bug.
I got that error with a user when I created an employee linked to this user.
You have to be at least an employee from the society to add a new client.
Link to create a new employee :
http://yoururl:PORT/?ts=1369948181483#view_type=kanban&model=hr.employee&menu_id=273&action=328
I got the error when I granted Portal rights to a contact/customer, then when a Quotation is sent (testing), opeing the Quotation yields the error message:
Access Denied
The requested operation cannot be completed due to security
restrictions. Please contact your system administrator.
(Document type: Partner, Operation: read)
However, clicking OK, can get past it and proceed to pay. This is a major ongoing sort of issue with OPENERP. It should be fixed by now...
I just faced a similar problem, may solution was to add a record rule for the Administration / Settings group, here is how:
1- Go to Settings->Groups and select Administration / Settings. (Make sure this group is assigned to de new user)
2- Click the Edit button and go to the Rules tab. (It should be empty)
3- Click the Add button, this action open a modal window, click the Create button on it.
4- Give the new rule a semantic name - e.g. Partner: administration settings: see all - and make sure all the access rights are selected.
5- In the object drop down type res.partner, it will allow you to select the object named Partner referenced in the error.
6- Click the Add button in the Groups section and select the Administration / Settings group.
7- Finally click the Save & Close button and save the group changes by clicking the Save button.
Hope this is helpful for beginners in OpenERP. Actually I already have used this solution patter more than once for similar error related to permissions a given user was expected to have.
Its a rules issue. Deactivate the rule Product Template . Rules overrule access writes setup under the user setup. So it looks like users have identical access but these rules bypass your customisations.
i think you should active developer mode, and go to setting/user -> select the user have this error. Then click edit and uncheck public in "Other Extra Rights" section. After that, click save.
I understand how to restrict entire pages, or even components by implementing <cflogin> and roles. For example:
<cfif IsUserInRole("Admin") OR IsUserInRole("Accounting")>
...You can view this page...
<cfelse>
...You can not view this page...
</cfif>
But how is it recommended to restrict certain facets of a page? Say for example an "Admin" is allowed to send Global Messages to all users, but that option is not available for a regular "User"
I suppose I could use the Session to manipulate my Views (pages). How is this typically handled?
You're right, securing a page and securing elements is different.
In my opinion and in practice, I think tying any code to a role or user is actually the wrong approach. Instead, tie permissions to elements and pages - then tie roles to those permissions. And of course, users are assigned roles.
It is important to have all three :
Users
Roles
Permissions <-- this is what you're missing
Permissions are what secure elements and pages, not roles or users Your code should have no clue (because it doesn't need to) what users or roles there are - just names of permissions.
When a user logs in, I grab their role(s). Then I grab all the permissions that are assigned to those roles (simply a list of string values).
For example, on a page I might have :
Add item
View item
Delete item
When I code that page, I actually secure each of those elements with permission strings named similar ( addItem, viewItem, deleteItem).
<cfif listContainsNoCase( session.permissions, 'addItem' )>
<!--- code to add item --->
</cfif>
(Note: I recommend using a custom tag or function for this, but for purposes of an example, the above works fine).
If you do it this way, it provides maximum flexibility and abstraction. If you secure elements based off of roles, you limit yourself :
Adding new roles will require a lot of code changes!
Changing permissions between roles requires a lot of code changes!
If you do it as mentioned above, you will never need to change your security code within the code base, because "addItem" permission should always be on the "add item" logic, right? :)
Now if you happen to need to create a "manager" type role, that has all the user roles and a select few admin rights, you simply create that role, and assign it the correct permissions (maybe addItem and editItem, but not deleteItem). Bam! Now I have a manager role to assign to users with no code changes!
If I had sprinkled my code with "is user this role" type of stuff - I would have to go edit my code everywhere to allow my new role "manager" - yuck!
Make sense?
=)
Things start going awry when businesses like to change the permissions that a Role has often because they don't know how else to give someone rights to do something.
So lets say a user in Marketing wants "update" rights to do some task. Someone in the business gives them the Update permission. But an IT Manager also has "update" rights which gives him access to things that the Update permission for Marketing should not.
So... I actually go one step further and specify Roles that have Permissions based on what Department that user is in. Yes its very complex and very tedious to manage hence I ended up on this question in my search for a better way to do it.