We have a store that needs to accept 2 options for customer login.
The traditional way - email / pw
First name / last name / pw
We have an extension that allows for #2, but we also need to accommodate for #1.
Is this possible?
It is for sure possible. It has to be implemented as extension. Details depend on custom code of #2 and Customer Configuration.
Related
We are currently using a generic report which will be used differently by multiple usergroups. We have made this possible by creating linked reports with different settings of hidden parameters (such as 'show column x', 'enable feature y').
These settings (parameters) are needed on other reports as well, so we pass them along using the Go to ... Action.
To create the look and feel we are after, we are passing some additional parameters as well, HTML Viewer commands and Report Server commands such as &rc:Parameters=False (reference).
Unfortunately, this leaves us with only the option Go to URL, since Microsoft hasn't implemented these commands for Go to Report. This means we have to pass our settings (the hidden parameters) along in the URL. This results in a security issue, example given: &PARAMETER_ENABLE_FEATURE_Y=False.
The user might notice this parameter in the URL and is so given the possibility to enable this function by editing the URL to &PARAMETER_ENABLE_FEATURE_Y=True.
So my question is: how to use an Action in Reporting Services while preventing users from editing our sensitive parameters and while being able to use HTML Viewer commands and Report Server commands?
You will never get complete security in this sense if you absolutely have to use URL based parameters.
When navigating via the URL, the only way you can hide parameter values without hard coding them is to make them data driven. In your scenario however this will not be 100% secure as you will still need to pass the value that populates your data driven parameters.
This level of obfuscation is probably enough and can be achieved by collating a list of either every parameter combination or just the ones your need and assigning it an ID that you can call in a dataset. This can obviously still be changed by your users should they get curious and can be a faff to maintain.
I would say your only other option is to hide the URL bar completely by providing a 'landing page' for your reporting and displaying everything in an iframe. This frame can be targeted with a javascript link in your Go To URL:
="javascript:void(window.open('URL to open','iFrame Name'))"
If you are able to though, I would advise you group your users into Active Directory security groups and then maintain a collection of permissions and customisations per group. You can then check which groups a user is a part of using custom code similar to the answers here and return the required parameter values accordingly.
Doing things this way will also enable you to maintain which groups can see what from a central location, assuming you have rolled out the same parameter structure across all reports.
I want to create separate databases for different registrations.
First i was doing it via multiple sub-domain manually but now i want it to be automatic after registration when anyone sign up.
This is what am thinking to implement:
First i'll create a common database "user_databases" to just store "user email" and "user database name". So when any user login with his email then i will fetch its database name and then verify login password from users table of the fetched database.
But the problem is how will i achieve it?
Should i include the code in database.php of Config or in each model i use $useDbConfig (i don't want to use it due to some reasons)?
Are there any better methods for it? Am i thinking right to implement it?
Please help and guide.
database partitioning in cakephp is now a trivial task because of cake's event system. cakephp allows you to talk to its request and response objects early in the app startup process in form dispatch filters. markstory has written nicely about this http://mark-story.com/posts/view/using-cakephp-and-a-horizontally-sharded-database
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 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.