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.
Related
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.
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.
Sorry for my english...
In my project I use ACL with SonataAdminBundle, but I can not understand why they did so, you need to have to create a record in the database, even when I want to use only Class-scope without Object-scope.
Also, when you create, for example, comments, SonataAdminBundle automatically creates an entry in acl_object_identities, it clutters up this action database.
I created a role that has the right to full access to all records in a table, regardless of who created the records, but SonataAdminBundle only displays them and prohibits editing.
The documentation for SonataAdminBundle reads:
because the object ACL permission is checked, the ACL for the object
must have been created, otherwise the AclVoter will deny EDIT access
for a non super admin user trying to edit another non super admin
user. This is automatically done when the object is created using the
Admin. If objects are also created outside the Admin, have a look at
the createSecurityObject method in the AclSecurityHandler.
But why? How to avoid this?
Do not want to write hooks.
Thank you in advance for any comments and help on this.
You can generate the object ACLs with php app/console sonata:admin:generate-object-acl
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.
I would like to allow the logged user to edit MediaWiki/Common.css without adding them to the sysop group.
I understand that this will allow user to change it to harful ways but it is a closed wiki so that is not a problem.
Any solution is acceptable even changing php code :)
Create a new group, add give it "editinterface" privilege. In LocalSettings.php it's done like this:
$wgGroupPermissions['mynewgroup']['editinterface'] = true;
Then add the user to you new group.
Or if you want to give that right to all logged-in users, do it like this:
$wgGroupPermissions['user']['editinterface'] = true;
// user is the default group for all logged-in users
For details see MediaWiki manual.
Probably safer to use;
$wgAllowUserCss = true;
See Mediawiki Manual for the complete details.
"When enabled, users are able to make personalised customisations over and above the normal choice of skins within the 'preferences' display."
A similar setting is available for Javascript.