Account-manager should be able to disallow users to delete their account

[hans@…]

The account manager plugin allows users to delete their account. In a enterprise environment this should not be allowed. Users are created using the account manager plugin by the ticket-manager.

[Steffen Hoffmann]

Not an enterprise grade contribution. Sorry, if I mistook your questions, but instantly I felt offended by the tone of the second sentence. As a matter of fact I'm maintaining and developing this as well as other plugins especially with enterprise applications in mind. My own employer uses it too. Guess what? With the user account deletion disabled, of course.

Did you ever care for the built-in TracWiki docs? TracIni will be your friend. After some information regarding Trac configuration concept and history it exposes all options of every locally installed plugin.

[account-manager] is lexically bound to be top section and allow_delete_account the second option in there. It advertises itself as Allow users to delete their own account. Translates into:

[account-manager]
allow_delete_account = false

The account removal section in users preferences will be switched off, if configured like that, and you're done.

What else do you require?

Consider using our th-users mailing list for support questions. This is an open development tracking system. You should really ask more kindly, respectfully, next time. Please.

Totally OT: ​Version control comparision requires a review of Mercurial (Hg) these days, honestly. :-)

[hans@…]

First of all: Thank you for your fast response!

Replying to hasienda:

Not an enterprise grade contribution. Sorry, if I mistook your questions, but instantly I felt offended by the tone of the second sentence. As a matter of fact I'm maintaining and developing this as well as other plugins especially with enterprise applications in mind. My own employer uses it too. Guess what? With the user account deletion disabled, of course.

I didn't have the same tone in mind as you interpreted from my second sentence. Maybe I should have added an emoticon to prevent misinterpretation. Sorry for me offending you. In my experience, the internet as a communication medium is bad for ones feelings.

Did you ever care for the built-in TracWiki docs? TracIni will be your friend. After some information regarding Trac configuration concept and history it exposes all options of every locally installed plugin.

As a matter of fact, I did search for the option; I even looked some 10 minutes into your source code, though didn't trace back all the way to the option-parsing module or whatever of python. I did it after posting this defect though. I could see there is an option, but I couldn't figure out from the code what (I tried some 5 configuration variables).

[account-manager] is lexically bound to be top section and allow_delete_account the second option in there. It advertises itself as Allow users to delete their own account. Translates into:

[account-manager]
allow_delete_account = false

The account removal section in users preferences will be switched off, if configured like that, and you're done.

What else do you require?

Consider using our th-users mailing list for support questions. This is an open development tracking system. You should really ask more kindly, respectfully, next time. Please.

Well, I might feel offended now, but I don't. I really thought this was a missing feature and still think it's a documentation defect (please do not feel offended). My resolution would be to document this feature on the wiki page of your otherwise fantastic(!) module.

Totally OT: ​Version control comparision requires a review of Mercurial (Hg) these days, honestly. :-)

Hmm. Maybe when I've got more time, I'll look into mercurial :-).

[Steffen Hoffmann]

+1 for editing the wiki to get this in. It has been a documentation bug indeed, in fact I noticed this when writing comment 1 and had no reference other than TracIni to throw at you. ;-)

Sorry for my misinterpretation of your approach to the issue too. You made you point clear now, so I stand corrected. Good thing.

You're welcome for your praise of the plugin, but I'm merely responsible for the last year of development and especially maintenance. The original author and users as yourself deserve equally much recognition for starting this effort with a bunch of clever ideas and for continuing interest and helpful feedback and patches respectively. Thank you.

After a rather short time with SVN I started with Hg, and never looked back. All my current work for Trac plugins here originally happens inside a local mirror of t-h.o SVN repo via a hgsubversion extension; most time spent writing and testing temporary changesets with the help of Mercurial Queues, another extension resembling a quilt-like patch stack management.

[Chris Nelson]

(In [11402]) Try to propagate dependencies to all children. Refs #9163.

This actually seems to get back to the original implementation. I broke it trying to optimized.

The logic now and originally is:

for each child
   if the child doesn't depend on any cousins
      copy dependencies down
   recurse to process grandchildren

The optimized, broken, intermediate version did:

if there are dependencies
   for each child
      copy dependencies down
      recurse to process grandchildren

If any level of the tree had no dependencies, propagation was interrupted. If a "root" ticket had no dependencies, all of its descendants were ignored.

[Chris Nelson]

Replying to ChrisNelson:

(In [11402]) Try to propagate dependencies to all children. Refs #9163. ...

Sorry. This commit was misattributed. It's for Trac-JSGantt, not Account Manager.

[Chris Nelson]

(In [11427]) Raise an error when there is a dependency loop. Refs #9163.

Bad data validation as much as bad algorithms can cause loops in tickets. This detects and reports them and doesn't keep recursing.