I've set up a private wiki for a class, and I'd like the students to create their own accounts (saving me from having to manually create them and email them instructions on how to login).
In LocalSettings.php, I changed the settings to the following:
# The following permissions were set based on your choice in the installer
$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
My intention is for anyone to create an account (I can add the ConfirmAccount extension if need be, but more likely I'll just change the flag to false after my students have signed up), but nobody can read or edit pages without becoming a user.
On the main page of the wiki, there is now a link to Create Account. However, clicking it just leads back to the Login prompt. The only way I can get the Create Account page is by changing all of the permissions above to true.
Is there a way to block read/edit access but allow account creation?
Okay I found a solution--surprising this wasn't included in the mediawiki documentation on the pages for managing users or restricting access.
Add this line to LocalSettings.php:
$wgWhitelistRead = array( 'Special:RequestAccount', 'Main Page', 'Special:CreateAccount' );
Related
hi i am working on SSRS report and all my reports are deployed in server with all the user permission but not sure why permission is not working sometimes when new user is providing permission.
as per my knowledge i know that i can set permission with 3 different ways.
1. Site level
2. folder Level
3. Report Level
when ever a new user need permisson to view the report, i follows the below.
Step: 1 opened the Reportmanager URL(http://toshiba-pc/MyReports) and click Home
Step : 2 clicking on "Folder Settings"
Step 3: Click on "New Role Assignment" and enter the domainname\TestUser with "Browser" role and click ok and TestUser user is automatically adding into all the folder
problem : some of user is not appearing into all folders some of the user is appearing into all folders.
to avoid above problem, i added DomainName\TestUser into folder security and it's again not appearing for all reports security , so again i have to add this user into the reports where use has not added.
this is very difficult to go each report to check whether reports has permission or not?
is there anything i am missing to configure , please let me know.
do i need to set role(system user, system administrator) for all the users to site setting. i never add user into site setting..
Please any one let me know what i am missing to configure.
Thanks
By default all permissions cascade to every item contained within the folder. This means that providing someone Browser access on the Home folder will give them Browser access to everything on the site.
This inheritance stops if at any point you have individually changed the security context of any item in the Report Manager. If you have ever done this, you will see the option to Revert to Parent Security when looking at that item's security settings:
Clicking this will remove the custom security context on that item and reset it to match the security context of the containing folder.
To find all items that have a security context different to that of your home directory so you can change them in the Report Manager (You can change this in the ReportServer database, but you run the risk of breaking your entire reporting catalogue and Microsoft will offer you no support for editing the database directly) run this query on the server which holds your ReportServer database:
select *
from ReportServer.dbo.Catalog
where PolicyID not in(select PolicyID
from ReportServer.dbo.Catalog
where Path = '' -- Home Path
and Name = '' -- Home Folder
)
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'm setting up samba on linux for single user access from Windows, and need to prevent password checking. I've added my linux username to smbpasswd. Despite the guest account setting in my smb.conf, files I create are owned by user nobody. How do I get samba to operate as my user id?
smb.conf:
[global]
security = share
guest account = liam
...
[goodstuff]
path = /home/liam
read only = no
guest only = yes
guest ok = yes
If this is a FAQ, apologies; I looked and looked for the answer.
This seems to be a common problem, for me it currently does NOT work if I have it in the share's section, but it works if it is in the global section. This is my share's definition:
[RepoDrive]
comment = USB drive
path = /shr
read only = No
create mask = 0777
directory mask = 0777
guest only = Yes
guest ok = Yes
browseable = No
According to the Samba manual, specifying guest account for the share SHOULD be okay and this is how it SHOULD be done... IMO, Samba has a LOT of issues. Note that if you want to find out as which user you are acting when you are a guest, make sure you have write permissions and create a folder, then you can check out the folder's owner, and this will be the user that samba used. For me, it is "nobody" (the default) if I specify the guest account in the share section.
Note that smbpasswd has nothing to do with these user definitions.
If all else fails, try to use testparm (you need sudo apt-get install samba-common-bin in order to get it). It will show you which parameters of your configuration are actually effective, and detect any irrelevant/incorrect parameters (it eliminates settings that you set to the default value, and rewrites synonyms, e.g. writeable = yes will become read only = no because these are antonyms).
The problem turns out to be
guest only = yes
With that removed, activity happens as the guest account user id.
The solution for me was to add "guest account = accountname" to the share in stead of the [global] part.
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.