In Trac is possible to set the "owner" for a new ticket to the logged in user ?
I've tried with different value for default_owner in trac.ini but no luck
From trac.edgewall.org authoritative documentation in Trac tickets (wiki):
default_owner: Name of the default owner. If set to the text "< default >" (the default value), the component owner is used.
So this is cannot help you for sure. There are a few more approaches left, depending on you Genshi template knowledge, Python skills etc. Your requirement is not hard to fulfill, but you cannot get it with stock Trac. You'll need to modify the (new) ticket template or add a relatively small plugin (tested with Trac-1.1.1):
import re
from trac.core import Component, implements
from trac.ticket.api import ITicketManipulator
class DefaultTicketOwnerManipulator(Component):
"""Set ticket owner to logged in user, if available."""
implements(ITicketManipulator)
def prepare_ticket(self, req, ticket, fields, actions):
pass
def validate_ticket(self, req, ticket):
if not ticket['owner'] and req.authname:
ticket['owner'] = req.authname
# Optionally report-back manipulation, so require a second POST.
# return [(None, "Owner set to self (%s)" % req.authname)]
return []
Hint: Use commented-out 'return' in pre-last line to not alter owner silently right on save, good for test too.
The following applies to Trac 1.1.3 or later, which is scheduled for release on 1st Jan 2015. It is implemented on the Trac trunk, which we do a pretty good job of keeping stable. The default create workflow actions are:
create = <none> -> new
create.default = 1
create_and_assign = <none> -> assigned
create_and_assign.label = assign
create_and_assign.operations = may_set_owner
create_and_assign.permissions = TICKET_MODIFY
To have the create action assign to the current user, just add:
create.operations = set_owner_to_self
Renaming the action might be appropriate, putting the ticket into either the assigned or accepted state:
create_and_accept = <none> -> accepted
create_and_accept.label = accept
create_and_accept.default = 1
create_and_accept.operations = set_owner_to_self
Related
So I created a model for storing credentials from Gmail users.
I wanted to make migrations but it says that there is no such table:
django.db.utils.OperationalError: no such table: mainApp_credentialsmodel
My models:
from django.db import models
# Create your models here.
from django.contrib.auth.models import User
from django.db import models
import json
class CredentialsModel(models.Model):
id = models.ForeignKey(User, primary_key=True,on_delete=models.CASCADE)
credential = models.CharField(max_length=1000)
Calling that model for checking authorization:
SCOPES = 'https://www.googleapis.com/auth/gmail.readonly'
store = CredentialsModel.objects.all()
creds = store.get()
if not creds or creds.invalid:
flow = client.flow_from_clientsecrets('mainApp/client_secret.json', SCOPES)
creds = tools.run_flow(flow, store)
service = build('gmail', 'v1', http=creds.authorize(Http()))
python manage.py makemigrations
If that error keep happening, check your migrations folder and check the files inside. Also check If your database is online, in case you have a database online, I've got this problem last week, but it was a problem with azure.
In last case I would create the table (model) again, changing the name to something similar, but If you have a significant amount of data in that table, then I think you can't do that.
It looks like your authorization code - including the query on CredentialsModel - is at module level. This means it runs when the module is imported, which happens before the migration has had a chance to run.
You must ensure that any database-accessing code is inside a function or method and is not invoked globally.
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.
We are trying to run code that modifies a document when it loads as part of schema maintenance. We have a document such as
from mongoengine import Document
from mongoengine.fields import IntField, StringField
class User(Document):
version = IntField(default=0)
name = StringField()
Instances of User are created with version=1 and saved.
Later on, we modify this class as follows:
class User(Document):
version = IntField(default=0)
name = StringField(max_length=20)
Some of the version 1 documents now need to be truncated:
def upgrade_1_to_2(self):
self.name = self.name[:20]
We want to automatically run that function whenever a User is retrieved from the database, and only if version == 1. (Future upgrades would be upgrade_2_to_3(), and so on.)
Where in this API can I put code that runs when a document is retrieved?
Looks like it's a good candidate for the post_init signal and you can do a check there.
See: http://docs.mongoengine.org/guide/signals.html
I'm looking for a way to create (not update) a trac ticket in response to a commit message like "Hack code to not kill your dog (TODO: fix this properly to avoid chasing kittens instead)".
I want the trac system to react on the "TODO" keyword and create a ticket with the content of the commit message, the owner set to the committer and the opening commit already referenced.
While searching on SO I found Open and close trac tickets with a single commit which basically says how I could roll my own solution. Which I'd do if there isn't a pre-made one available. So - is there?
I would suggest looking at the official Trac package for python: http://pypi.python.org/pypi/Trac/0.11.4 and docs http://www.edgewall.org/docs/tags-trac-0.11.7/epydoc/trac-module.html
This is what we use to create tickets in Trac from a python script and I think it's fairly simple to use. You could run this python script as a post commit hook for your VCS.
You can start up a trac environment using your project settings and then new up tickets and save them. There's probably a little more to it for you, but this should give you a good idea:
from trac.env import Environment
from trac.ticket import Ticket
env = Environment(projectSettings, create=0)
tkt = Ticket(env)
tkt['summary'] = 'first line of commit message'
tkt['description'] = 'full commit message'
tkt.save_changes(commitAuthor, '')
Needless to say, current Trac stable is 0.12.3, but of course development needs to go with your current version. (You didn't tell us in you question.)
On you question, there is a hint on how to implement different functionality on-top of the CommitTicketUpdater from Trac core. It has update and close as built-in actions, so you'll need to do some change like so (based on current Trac trunk):
create an additional option commands_create for commands, that create a new ticket with reference to the changeset, as a space-separated list
add a class-wide variable self.comment in both of changeset_added and changeset_modified right after comment assignment
add a module cmd_create like (untested)
def cmd_create(self, ticket, changeset, perm):
if not self.check_perms or 'TICKET_CREATE' in perm:
# Commit messages in general is used for a ticket comment.
# New tickets require summary and we'll want description too,
# because comment is ignored on ticket creation.
# So we need to do message processing here beforehand.
ticket['comment'] = None
ticket['description'] = self.comment
ticket['owner'] = changeset.author
ticket['status'] = 'new'
ticket['summary'] = ' '.join(['TODO from', str(changeset.rev)])
ticket.insert()
alter ticket_command so the regexp matches not only the default function-ticket(s) pairs but the unary 'TODO:' as well (sorry, can't make this working right-away now)
extend the private module _parse_message to include another case before if func:
if cmd.startswith('TODO'):
tickets.update({None : ['create']})
continue
change _update_tickets to make the comment saving conditional, because you won't need/want an additional comment on new tickets)
if ticket['comment']:
ticket.save_changes(changeset.author, comment, date, db)
Ok, ask back as required, if you like to try this approach.