[PATCH] Add EDIT_FILES permission, new options (ini-admin enabled), preserve list order

[dnedelchev]

New and improved features after applying this patch:

• Added: EDIT_FILES permission
• Added: trac.ini new options (list vew: replace rules; show/hide paths)
• Modified: EditFile: info header
• Fixed: file list order preserved as it is in [edit_file] section in trac.ini
• Fixed: Leading/trailing white space now is preserved at file save (with an exception - see below)

Known issues in [8676] of the plugin not fixed by this patch:

• Bug: A wrong file can be overwritten if files list in the [edit_files] section of trac.ini is modified while a file is being edited. Workaround: ensure trac.ini is not modified at the same time.
• ToDo: Files can't be marked as read-only. Workaround: set to read-only at file-system level.
• ToDo: Creating a backup of the file before saving. It should be an option though.
• Bug: (However that's bug maybe is not in the plugin itself) If the edited file starts with a new-line, its stripped (apparently when file is read, not when written). Workaround: do not start the file with an empty line - if a space is inserted in the top of the file, the subsequent new-line is not stripped (and the line still looks like if its empty).

---

I intended to use this plugin to edit the trac.ini files of all projects from a single place. When I configured the plugin in my main trac environment I got an randomly ordered list with a lot of .. trac.ini items. That proved to be quite useless for me so I decided to try fixing it...
So I did.

The final result exceeded my expectation. I was vastly amazed how easy it was for an absolute python newbie like me (say "Hello World +" level) to implement it!

[dnedelchev]

The proposed patch (tested with 0.12 @ WinXP and @ Linux)

[dnedelchev]

The cryptic EditFiles list that forced me to modify the code

[dnedelchev]

An example of improved EditFiles list after customization

[dnedelchev]

The new edit_files admin panel

[dnedelchev]

So I have to submit some tickets for the Known issues items...
For some of them I can propose one or more possible approaches. But for sorry I don't have enough free time to implement them by myself...

P.S. About this patch: Oh yes, I didn't implement that today! I coded and tested it (mainly last weekend at home) for about tree days. Today I just updated my code with the changes in [8676] and did test it again.

[anonymous]

Great, thanks for this stuff. Glad you're having fun with python and finding this to be useful.

When I get time I'll go ahead and add you as a contributor; at the moment I'm not sure what I need to do to get you keys to the repository here. If that works out you can make the changes yourself, if not I'll get to it myself in the next couple of days. Thanks again.

[dnedelchev]

I've tested it only with Trac 0.12 since I don't have any Trac 0.11 installation to test with. It would be fine if someone can test it. In case there are any problems with 0.11, a 0.12 branch can be created.

BTW 0.12 branch could be created right now and until a separate branch is really needed, there would be just one file stating that 0.11 branch can be safely used for Trac 0.12 too.

[Ryan J Ollos]

Replying to anonymous:

When I get time I'll go ahead and add you as a contributor; at the moment I'm not sure what I need to do to get you keys to the repository here. If that works out you can make the changes yourself, if not I'll get to it myself in the next couple of days. Thanks again.

You'd need to ask the maintainer otaku42 to provide write access to additional contributors.

Alternatively, if you let me know what needs to be checked-in, I can take care of it (I have global write access and TRAC_ADMIN permisssions, but don't have permissions to modify repository permissions).

[matthew von rocketstein]

dnedelchev, shall I add you as a contributor? =]

Hrm, I haven't committed this yet because I am confused. I successfully applied your patch and I can confirm it doesn't appear to break anything for 0.11 or 0.12. Odd thing is despite all the new code nothing seems to work any differently than before.. I built my environment from scratch with virtualenv (and still ran trac-admin upgrade afterwards) so I feel pretty sure it's not the problem.

Before I dig deeper, is it possible that you left a file out (a template maybe?) of the patch?

[dnedelchev]

Hi, I've been very busy last days and didn't check my e-mail till now. It's pretty strange... I'll verify may working copies consistency (since I have two - one for my local repository and another - for the trac-hacks.org) and try creating and checking the patch again.

[dnedelchev]

1. The patch visually looks consistent to all the changes I've made, however I reverted my trac-hacks.org working copy then applied the patch. The result was identical to the up-to-date working copy of my local repository.
   
2. I uninstalled the plugin at our production trac installation (it had been a little different version there) and installed it again from the head of my local repository. After restarting apache I see the changes took the expected effect.
   

Actually I modifyed two files:

• editfilesplugin/0.11/edit_file/edit_file.py@8676​ - a lot of differences
• editfilesplugin/0.11/edit_file/templates/edit_file.html@8610#L12​ - a single difference in just one line.

For the release you'll probably want to bump the version (changing also the editfilesplugin/0.11/setup.py@8610#L4​)

(As you know, to be able to see the admin/tracini/edit_file pane you should have the IniAdminPlugin plugin enabled too)

[dnedelchev]

A couple of code change notes:

1. I decided not to use the os.path.sep and instead added as a deafault first transformation rule replacing '\' with '/' since os.path.sep didn't work satisfactory for me on windows: In fact Windows accepts both '\' and '/' (and even arbitrary mixes of them like C:\parent1/parent2/dir\file.txt) while os.path.sep is aware only of windows' native '\' path stile.
2. I discarded the CUT_OFF margin variable (though initially I intended to implement it to work properly) to keep the number of option parameters reasonably small because using only replace-rules turned to be enough to allow flexible and easy configuration.