Modify

Opened 4 years ago

Closed 6 months ago

Last modified 6 months ago

#7872 closed defect (fixed)

BMT leaking into other trac projects that have BMT plugin enabled

Reported by: anonymous Owned by: obs
Priority: high Component: BlackMagicTicketTweaksPlugin
Severity: blocker Keywords: black, magic, leaking, duplicating, instance,
Cc: louise.howells@… Trac Release: 0.11

Description

I have installed BMT on a project, edited the ini file within the project, edited the permission policies section of the ini file as stated in the instructions.
This worked great ( I added permissions and labels etc)

It worked so great another TRAC project wanted something similar. So I installed the plugin within the new projects environment, edited the new projects ini file and now I have a mixture of the 2 settings.

It leaks through if there are two fields the same, for example the trac default fields like milestone, type and summary.

If I refresh in web browser that sometimes displays the correct view, if I refresh again the incorrect view re-appears.

Can you please help?

Attachments (0)

Change History (8)

comment:1 Changed 3 years ago by anonymous

  • Severity changed from major to blocker

I have the exact same problem.

Project 1 has

[blackmagic]
tweaks = summary
summary.notice = Test of notice

Project 2 has

[blackmagic]
tweaks = type
type.disable = True

both project ran in the with the same parentdir in tracd, like this:
tracd -port 8000 -r -e /path/to/parentdir

What happens now is that the type tweak (disabling) is affecting BOTH projects, while the notice tweak is only in the correct project where it was configured.

comment:2 Changed 3 years ago by anonymous

It may not be relevant for the issue, but one piece of advice: You should never install a Python module or plugin twice within the same running Python process. One tracd process cannot load a module more than once, so it will likely load the code from the first project that gets a request. When loading project 2 it will see that plugin is already loaded and skip it.

Use [inherit] plugins_dir setting to share plugins between projects, or install them globally and selectively enable.

see trac:wiki:TracPlugins for more details on plugin loading.

comment:3 Changed 3 years ago by osimons

I got curious about this bug, and quickly scanned the plugin source. It is obvious why this happens. The plugin implements class-level dict and list definitions, and being mutable they will be shared between any component instantiated from the same class. As from my previous comment (as 'anonymous') the two components enabled (one from each environment/project in same running tracd process) will share data structures such as self.enchants and self.extra_permissions. All code in the plugin just updates these class-level variables that are initialized when class is defined and not when a new object is created.

This really needs fixing... One way would be to make sure to initialize new structures for every component in __init__(), like:

def __init__(self):
    self.enchants = {}
    self.extra_permissions = []
    # ... remaining method as before

To make sure class-level data is not shared, either remove it or use enchants = None or similar to signify existence without providing a mutable data structure.

comment:4 follow-ups: Changed 3 years ago by grendelson

I'm having exact same issue where one site of 12 or so uses a defined permission CHANGE_OWNER and only allows member of a group to have this permission to change owner.
However all the other sites ( none of which have this setting but DO use BLM plugin ) are getting "owner is invalid" errors when trying to change status that updates owner by authenticated users. I traced the error to the sites trying to verify CHANGE_OWNER in the debug logs.
I've added osimons' fix above and stopped the httpd recycle every 10 minutes that was my attempt to work around the error by flushing the cached plugins.
I'm running debug logging on 2 of the sites that are heavy users that were getting this error frequently and will update results.

comment:5 in reply to: ↑ 4 Changed 3 years ago by anonymous

Replying to grendelson:

I'm having exact same issue where one site of 12 or so uses a defined permission CHANGE_OWNER and only allows member of a group to have this permission to change owner.
However all the other sites ( none of which have this setting but DO use BLM plugin ) are getting "owner is invalid" errors when trying to change status that updates owner by authenticated users. I traced the error to the sites trying to verify CHANGE_OWNER in the debug logs.
I've added osimons' fix above and stopped the httpd recycle every 10 minutes that was my attempt to work around the error by flushing the cached plugins.
I'm running debug logging on 2 of the sites that are heavy users that were getting this error frequently and will update results.

forgot to include:

diff blackmagic.py blackmagic.py.ORIG
42,43d41
<       self.enchants = {}
<       self.extra_permissions = []

comment:6 in reply to: ↑ 4 Changed 3 years ago by bjornar

Replying to grendelson:

I've added osimons' fix above and stopped the httpd recycle every 10 minutes that was my attempt to work around the error by flushing the cached plugins.
I'm running debug logging on 2 of the sites that are heavy users that were getting this error frequently and will update results.

Hello, do you have some updates to this testcase, did you find a good solution?

comment:7 Changed 3 years ago by fleeblewidget

I had this problem too, I'd renamed some of the core ticket fields in one project and when I started using the plugin on another project my modified field names overflowed into the new project.

osimons' fix worked just fine for me, using the 0.12 branch of the plugin with Trac 0.12.2.

comment:8 Changed 6 months ago by rjollos

  • Resolution set to fixed
  • Status changed from new to closed

In 13734:

0.11.2 / 0.12.2: Move class attributes to instance attributes, to avoid reported issues with shared state between Trac environments. Fixes #7872.

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.