Im having troubles restricting the analytic timesheet so that employees only can see and edit their own hours.
I tried restricting it with the rule [('user_id','=',user.id)] but I guess I entered the rule to the wrong place.
How exactly do I do this?
Thank you!
Your rule looks fine, but it needs to be "Apply on Read" also.
Currently, it's not applied on read, so users would be able to view all other employees' hours, but not create/edit/delete.
Additionally, the Object may need to be changed. Currently your record rule is applying on the Users object, when it sounds like you want to apply it on the account.analytic.line object so that your rule applies to the Timesheets.
Record Rules Documentation
Related
Is it possible to assign an order manually in the backend to a customer?
I couldn't find anything about it.
Unfortunately this is a regular task of our customer support.
You can create a new order manually in the administration.
You can't however retroactively change the customer of an order placed via the storefront, if that is what you meant. In theory you could do it programmatically by replacing customer specific associations of the order with new ones, based on another customer. It's still likely this would come with a few undesired side effects though.
I guess you mean: You want to create a order for a customer via the administration. For this, have a look into the docs:
https://docs.shopware.com/en/shopware-6-en/orders/create-order-in-admin
Hi everyone and I new to complex SQL and to Clickhouse both. So sorry if this seems like a simple question, but I still can't figure it out.
Challenge:
I want to build an event path that leads to a specific event.
You probably have seen these types of analysis in Google Analytics, for instance:
Basically, based on a target "end event", I am looking to build the path taken by the user to arrive at that event.
Suppose I have a table like this:
date
event_name (purchase, add_to_cart, search, browse)
user_id
Now, given the final event, let's say "purchase", I want to understand what are the common paths for users to arrive at that event, just like the picture above.
How would you go about accomplishing that?
I am using Clickhouse for this analysis.
Thanks
I am using odoo 10. I want to restrict the project users to see or edit their own tasks only. And the project manager can assign tasks to them and can see all the tasks. That means project manager should have full permissions.
I tried many solutions from the forums but none of them are working as expected. Any help is highly appreciated.
I have created a new record rule:
Object: project.task
Domain filter: [('user_id','=',user.id)]
When I save it as global then each task is seen by its assignee only but this rule is applying for project manager also. Project manager also not able to see or create his tasks for his team now. But I need project manager to have full permissions.
If I select the group as Project/User: In this case the effect is gone and all the users are able to see all tasks.
Also I have created a record rule for Project/Manager with domain filter [(1, '=', 1)]. But still my required result is not achieved.
First you need to read the documentation about Odoo Security carefully. Basically Odoo provides two main data-driven mechanisms to manage or restrict access to data.
Access Control
Record Rules
In your case you just need to copy the setting from other similar case. For example "Sales Manager" and "User: Own Documents Only" for sales.
Access Control. Create both groups and give permission to the model, in your case project.tasks
Rules. Add a rule only for the "User: Own Documents Only", in your case "Project/User":
Read this carefully. https://www.odoo.com/documentation/12.0/reference/security.html
Global rules are subtractive, they must all be matched for a record to be accessible
Group rules are additive, if any of them matches (and all global rules match) then the record is accessible
Turns out the global rules are subtractive, the group rules are additive. If you apply globally then only users that satisfy your domain user_id = user.id will be readable/writable. But if you apply only to a group, it won't restrict the access because it's additive and users are granted access somewhere else.
What I did for a similar scenario is apply a global rule so that
task is only seen by its assignee. Then apply a group rule to manager so that manager can see all tasks.
Hope this could help you
In this thread I verified that the correct approach for hiding some individual fields from a composite field is done correctly. That seems to be confirmed by other sources as well. However, despite a rule defined like so:
I still get the stupid fields to show up when on account form. It looks as the following image depicts and is a high level annoyance and reason for my teeth grinding. What am I missing? (Yes, I did activate the rule and I reloaded the form.)
If there are any issues with business rule (i.e. when attempting to hide a field not present on the targeted form, as is the case, due to mix-up between country and county), it wouldn't proceed, the execution will stop but there won't be any complaints or any errors thrown.
Credits to #Daryl for: "I've had issues where hidden fields were the first field on the form and the method the MS uses to select the first field, made it visible."
I need to set up different permission on an object based on its workflow state. For instance, 'manager group' can edit the object only if state=draft but 'super manager group' can edit it also if state=validated.
It seems that's not possible using ir.model.access and I'm evaluating if it could be done using ir.rule. It seems not...
Is there a official way to get this or do I need to implement this feature (maybe by adding a condition into ir.model.access machinery).
This is not possible by default with ir.model.access, because this permission model is designed to act like simple Unix permission on CRUD operations, and it is statically defined, per-model and per-group.
You may be able to implement something like this using ir.rule, as it implements dynamic per-record access control based on field values. By having a set of rules defined only on the write and unlink operations and based on the state field, you will be able to prevent some groups from modifying records in certain states. By using the technique of an always-true rule [(1,'=',1)] you can then relax a non-global rule for users who have a "super-access" group. See also this answer.
This option will have important caveats however:
Be careful not to make those rules apply for read, as it will make the records completely disappear, and generally wreak havoc in your processes
The interface will not become read-only when the rule is in effect, and if you want to make the fields and buttons read-only you will have to find a way to specify this via attrs in a manner that depends on the user's groups. See also this Launchpad question.
the Save button in the UI will not be disabled
The standard error reporting in case of ir.rule restriction is not very clear, so it will certainly confuse users (note: it's being improved for 7.0)
As you see, using ir.rule filters for this purpose is far from a perfect solution, and you will first need to find appropriate solutions for the above issues.
Ultimately, you might have an easier task of implementing your own logic for this, plugging a new mechanism in the ORM primitive API methods: fields_view_get (for making fields dynamically read-only based on the user groups) and the CRUD methods (for actually restricting the operations)
There is another way instead of hacking web-client.
You can always have 2 views for the same Object .
For manager group.
For super manager group.
In manager group you can use attrs = {'readonly': [('state', '!=', 'draft')]}
or any condition as you needed.
And in the same way in super manager group, you can put his condition for fields.
I have this feature working on a production environment, using just Record Rules: in Project Issues, "basic users" can create and cancel issues, but can't open or close them.
Despite the GUI limitations mentioned by #odony, it works perfectly.
These are the Record Rules used::
There is a special case that needs attention: changing from a read-write State to a read-only State:
In the action's method, if the the State is changed after other write operations, the user will be able to change the State; but if there are some write operations after the State update, the user will not be able to change State.
In my example, the Project Issue method to Open an issue is case_open(). It first changes State and then does additional changes, like settting Open Date, User and Message history. Because of this, basic users can't Open issues. If you want them to be able to do so, case_open() must be overridden so that it changes State after all other write operations are done.
I got a similar requirement...
My requirement was to make a char field(say "test_123") readonly in the sale.order if the user comes under the group "sale user" otherwise editable for the group "Sale Manager".
That is, if the sale order is in draft state then anyone can edit, but it the sale order is confirmed then this field "test_123" is only editable for "Sale Manger"
What I did is I added a functional field (is_group_manager) which returns True if the user comes under the group "sale manager" and the state is not "draft" otherwise false.
Then in the xml view I added the field "test_123" with attribute attrs="{'readonly':[('is_group_manager','=',0)]}"
for example
<field name="is_group_manager" invisible="1"/>
<field name="test_123" attrs="{'readonly':[('is_group_manager','=',0)]}"/>
This will work only in openerp v6.0. Maybe this will be helpful for you. :)