What is the use / purpose of logging menu in the
Settings -> Technical -> Database structure -> Logging
It seems that you can store all the log messages in that view (model ir.logging) as long as you use the parameter --log-db your_database_name when executing odoo-bin in the command line (or add log_db = your_database_name in your Odoo config file).
Check out Odoo 11 info about command line parameters: https://www.odoo.com/documentation/11.0/reference/cmdline.html
--log-db
logs to the ir.logging model (ir_logging table) of the specified database. The database can be the name of a database in the “current” PostgreSQL, or a PostgreSQL URI for e.g. log aggregation
This is the theory, but honestly, I was not able to make it work, and I did not waste much time in trying to know why.
EDIT
As #CZoellner says, it seems that log messages stored in ir_logging table (log messages you see clicking on the menuitem Settings -> Technical -> Database structure -> Logging) come only from scheduled actions. If you create an scheduled action which executes some Python code, you have the following available variables to use in your method code:
env: Odoo Environment on which the action is triggered.
model: Odoo Model of the record on which the action is triggered; is a void recordset.
record: record on which the action is triggered; may be void.
records: recordset of all records on which the action is triggered in multi-mode; may be void.
time, datetime, dateutil, timezone: useful Python libraries.
log: log(message, level='info'): logging function to record debug information in ir.logging table.
Warning: Warning Exception to use with raise To return an action, assign: action = {...}.
If you use the log one, for example:
log('This message will be stored in ir_logging table', level='critical')
That log message and its details will be stored in ir_logging table each time the scheduled action is executed (automatically or manually). This answers your question, but now I am wondering what is the parameter --log-db, as I have tested it and these log messages are stored in ir_logging no matter this parameter is set or not.
Related
I have a requirement where I need to set assignee's to all the "user-tasks" in a process instance as soon as the instance is created, which is based on the candidate group set to the user-task.
i tries getting the user-tasks using this :
Collection<UserTask> userTasks = execution.getBpmnModelInstance().getModelElementsByType(UserTask.class);
which is correct in someway but i am not able to set the assignee's , Also, looks like this would apply to the process itself and not the process instance.
secondly , I tried getting it from the taskQuery which gives me only the next task and not all the user-tasks inside a process.
Please help !!
It does not work that way. A process flow can be simplified to "a token moves through the bpmn diagram" ... only the current position of the token is relevant. So naturally, the tasklist only gives you the current task. Not what could happen after ... which you cannot know, because if you had a gateway that continues differently based on the task outcome? So drop playing with the BPMN meta model. Focus on the runtime.
You have two choices to dynamically assign user tasks:
1.) in the modeler, instead of hard-assigning the task to "a-user", use an expression like ${taskAssignment.assignTask(task)} where "taskAssignment" is a bean that provides a String method that returns the user.
2.) add a taskListener on "create" to the task and set the assignee in the listener.
for option 2 you can use the camunda spring boot events (or the (outdated) camunda-bpm-reactor extension) to register one central component rather than adding a listener to every task.
After implementing the answer to this question on how to set up a script for time visualization in this project (which uses a small extension to the published Log::Timeline that allows me to set the logging file from the program itself), I still get the same error
12:18 Timeline connection error: Could not get timeline data: java.net.ConnectException: Conexión rehusada
(which means refused connection). I've also checked the created files, and they are empty, they don't receive anything. I'm using this to log:
class Events does Log::Timeline::Event['ConcurrentEA', 'App', 'Log'] { }
(as per the README.md file). It's probably the case that there's no such thing as a default implementation, as shown in the tests, but, in that case, what would be the correct way of making it print to the file and also connect to the timeline visualizer?
If you want to use the timeline visualization, leave the defaults for logging, commenting out any modification of the standard logging output. In my case:
#BEGIN {
# PROCESS::<$LOG-TIMELINE-OUTPUT>
# = Log::Timeline::Output::JSONLines.new(
# path => log-file
# )
#}
Not really sure if this would have happened if an output file is defined using an environment variable, but in any case, better to be on the safe side. You can use the output file when you eventually drop the script into production.
I'm trying to create an Intergration Automation Script for a PUBLISHED Channel which updates a database field.
Basically for WOACTIVITY I just want a field value setting to 1 for the Work Order if the PUBLISHED channel is triggered.
Any ideas or example scripts that anyone has or can help with please? Just can't get it work.
What about using a SET processing rule on the publish channel? Processing rules are evaluated every time the channel is activated, and a SET action will let you set an attribute for the parent object to a specified value. You can read more about processing rules here.
Adding a new answer because experience, in case it helps anyone.
If you create an automation script for integration against a Publish Channel and then select External Exit or User Exit there's an implicit variable irData that has access to the MBO being worked on. You can then use that MBO as you would in any other script. Note that because you're changing a record that's integrated you'll probably want a skip rule in your publish channel that skips records with your value set or you may run into an infinite publish --> update --> publish loop.
woMbo = irData.getCurrentMbo()
woMboSet = woMbo.getThisMboSet()
woMbo.setValue("FIELD", 1)
woMboSet.save()
What is different between:
test = self.env['my.example'].sudo().create({'id':1, 'name': 'test'})
test = self.env['my.example'].create({'id':1, 'name': 'test'})
All example work, but what is the advantages when using sudo()?
Odoo 8–12
Calling sudo() (with no parameters) before calling create() will return the recordset with an updated environment with the admin (superuser) user ID set. This means that further method calls on your recordset will use the admin user and as a result bypass access rights/record rules checks [source]. sudo() also takes an optional parameter user which is the ID of the user (res.users) which will be used in the environment (SUPERUSER_ID is the default).
When not using sudo(), if the user who calls your method does not have create permissions on my.example model, then calling create will fail with an AccessError.
Because access rights/record rules are not applied for the superuser, sudo() should be used with caution. Also, it can have some undesired effects, eg. mixing records from different companies in multi-company environments, additional refetching due to cache invalidation (see section Environment swapping in Model Reference).
Odoo 13+
Starting with Odoo 13, calling sudo(flag) will return the recordset in a environment with superuser mode enabled or disabled, depending if flag is True or False, respectively. The superuser mode does not change the current user, and simply bypasses access rights checks. Use with_user(user) to actually switch users.
You can check the comments on sudo in Odoo code at odoo -> models.py -> def sudo().
Returns a new version of this recordset attached to the provided
user.
By default this returns a ``SUPERUSER`` recordset, where access
control and record rules are bypassed.
It is same as:
from odoo import api, SUPERUSER_ID
env = api.Environment(cr, SUPERUSER_ID, {})
In this example we pass SUPERUSER_ID in place of uid at the time of creating a Enviroment.
If you are not use Sudo() then the current user need permission to
create a given object.
.. note::
Using ``sudo`` could cause data access to cross the
boundaries of record rules, possibly mixing records that
are meant to be isolated (e.g. records from different
companies in multi-company environments).
It may lead to un-intuitive results in methods which select one
record among many - for example getting the default company, or
selecting a Bill of Materials.
.. note::
Because the record rules and access control will have to be
re-evaluated, the new recordset will not benefit from the current
environment's data cache, so later data access may incur extra
delays while re-fetching from the database.
The returned recordset has the same prefetch object as ``self``.
This happens when a Project/User drops his task unto a destination stage containing tasks not owned by him.
Apparently, Odoo remembers the stack ordering of tasks within a stage via project.task.sequence, and updates all the task cards' sequence fields when the Project/User completes the drop action. But since the Project/User is not authorized to modify other users' tasks (of project.task object type). The Odoo server raises the exception shown below.
Access restriction is implemented via the following record rule for Project/User:
Name: Project/Task: only assignee and creator can modify task
Object: Task (project.task)
Apply for: Write
Domain filter: ['|',('user_id','=',user.id),('create_uid','=',user.id)]
Group name: Project/User
Is there any workaround to this problem?
At time of writing, the error can be reproduced at http://demo.odoo.com currently running Odoo version 8.saas~6.
Note that by default Human Resources / Employees are allowed to modify tasks not assigned to them, so the write and delete access of record rule "Project/Task: employees: public, portal, employee or (followers and following)" must first be removed.
Couldn't think of a better solution, so I just did the following hack instead:
Add to top portion of _write function of openerp.models.BaseModel in the file ODOO_ROOT/models.py:
def _write(self, cr, user, ids, vals, context=None):
# use admin if just writing to 'sequence' field of model 'project.task'
if self._name == 'project.task' and vals.keys() == ['sequence']:
user = SUPERUSER_ID
This is probably OK since the sequence field is not really a very important field to protect from casual modification by non-owners.