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.
Related
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.
I created new user - 'exampleuser' and new role - 'examplerole' in JasperReports Server version 5.6.
The new user - 'exampleuser' has 2 roles: 'examplerole' and 'ROLE_USER' that is attached to the user by default in the JR Server.
For every folder in jasper I gave the 'examplerole' and 'ROLE_USER' the permissions - Execute only.
According to my understanding, if I will login with the 'exampleuser' user I won't be able to see any folder, of course not be able to delete any file inside that folder.
What actually happens is that I'm able to see all the files inside any folder, add and delete files as I wish and change permissions to the files.
Could not find any information about it - according to the JasperReports Server manual I'm not doing anything wrong or do I?
The 'exampleuser' doesn't have any permissions to the folder e.g. 'NO ACCESS' permission.
And there were no errors in the logs.
Is someone ran into this situation before? Is it fixable or it is some bug of JasperReports Server?
-----------------------------EDIT---------------------------------------
I've found out that this situation happens only in Google chrome browser. If I use IE for example, everything is as it should be.
Anyone? Any idea?
Edit user(exampleuser) and assign only new role(examplerole) which you created for new user remove ROLE_USER and save.
Now right click on the folder on which you want to give permission to new user(exampleuser) and select "Permission" , there you can see all the roles and there access permission.
Change permission No Access to Read only for examplerole and remove the access form other roles i.e. select No Access option.
Now after that you need to check remaining other directories whether they have ROLE_USER access or not , if they have remove permission from ROLE USER i.e set it to No Access.
Question:
How can I get a list of all checked out files per user in Sourcegear Vault?
Use of this functionality:
From time to time we have developers leaving files checked out and although this results in drastic punishment (they owe a coffee to the person who needed the checked out file) we are still left with files checked out and work held up.
We would like to display a list of all current number of files checked out by each developer. This way they can check if they have anything checked out before they go home or out the office.
In the Vault Client app, use the Search tab at the bottom of the window.
Select Search By: "Checked Out By" to see a list of all files checked out by a specific user, or by any user.
You can choose to search a specific sub-folder, or from the root, recursively or not.
To automate this, use the Vault Command-Line client (vault.exe)
vault -host myhost.mydomain -user something -password something -repository myrepo listcheckouts
Will give you a list, in XML, of all checked-out files and their users. You can transform the results, or use the command-line client's source code (provided as an example with the Vault .NET API) as a starting point to write your own version.
The various clients and APIs can be grabbed from http://sourcegear.com/vault/downloads.html - didn't want to link to a specific version that would be outdated after the next release.
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.
mercurial-server manages user database under keys folder. Users and groups are represented by files and folders.
AclExtension relies on linux user group through ssh.
they don't seem to match. or did I miss something?
I have managed to make mercurial-server work. but just don't see how to integrate AclExtension with it so I may have finer grained access control.
Unfortunately, the AclExtension does key its access off of usernames. If you are creating separate UNIX user accounts for each using with hg-ssh you've got everything you need, but if all of your ssh users are using the same Unix user account then the AclExtension isn't going to work for you.
Unless...
I did just look into the acl.py file and it looks like it uses the getpass.py module's getuser which checks the environment for the user name using this code:
for name in ('LOGNAME', 'USER', 'LNAME', 'USERNAME'):
user = os.environ.get(name)
if user:
return user
so it might be possible to fake that out by setting an environment variable in the hg-ssh user's authorized_keys file like this:
command="hg-ssh path/to/repo" environment="LOGNAME=fakeusername" ssh-dss ...
where then you could put fakeusername in ACL rules, and could have a different fakeusername for each key, all running under the same UNIX account.
BTW: Everyone seems to just use hg-ssh alone, I never see the (non-official) mercurial-server app used anymore.
The environment trick doesn't seem to work on my Solaris box; my solution was to pass in the fakeusername as a parameter to hg-ssh and have that set os.environ['LOGNAME'] so that getpass sees it.
command="hg-ssh fakeusername" ssh-dss ...