Projects

This is a fully maintenance release as it has no new features and only adds support for Redmine 1.4.x, 2.0.x and 2.1.x. This release is accompanying the release of the Extended Fields 0.2.0b, what is natural as the Extended Profile plugin uses the Extended Fields for building user profiles.

This release also removes the extended_profile table, which was used by the version 0.x.x of the plugin. This table, as well as version 0.x.x, is now obsolete.

The release also contains the fix for the bug #1972, reported by Ki Won Kim.

This version was also planned to include the Twitter “Follow” button instead of just link to the user profile on Twitter... But in the very last moment I changed my mind. Why? I thought, that before following someone I, personally, would want to check, what actually he/she tweets...

However, let it be the bonus of this news. If you want to have the Twitter “Follow” button, replace the content of the app/views/custom_values/string/_twitter.html.erb file with:

<% mention = custom_field.value.start_with?('@') ? custom_field.value : "@#{custom_field.value}" %>
<% username = custom_field.value.gsub(%r{^@}, '') %>
<a href="https://twitter.com/<%= h(username) %>" class="twitter-follow-button" data-show-count="false"><%= h(mention) %></a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

Or download it from export:v1/app/views/custom_values/string/_twitter.html.erb@37 (this is the older version of the file).

To be notified about future releases of the Extended Profile plugin subscribe to this project using the subscription form on the sidebar. This form is provided by the Subscription plugin, which has not been released yet (need to port every other plugin to Redmine 2.x first)...

P.S. The next plugin is the Author Box, which the Extended Profile utilizes (if installed, of course) by addings additional data to author boxes...

This the third my plugin I ported to Redmine 2.0 and the first plugin I ported to Redmine 2.1. Unfortunately, the delay between this release and WikiNG release (the previous port to Redmine 2.0) was still big as I got very busy, then had a vocation, then found difficulties in implementing extended fields under Rails 3 and then got to port for Redmine 2.1, which switches to jQuery...

• Vitaly Klimov discovered that issues grouping by custom fields got broken after installing this plugin... Vitaly also made research of the issue, what helped me much! Thanks, Vitaly! The new version does grouping by custom fields just fine! See #2015.
• V.E.O. discovered that you can’t export issues listing to PDF with any extended column enabled! But it’s not the case anymore with this new release. See #2023.

As Redmine 1.4.x introduced multiple repositories support I also did some modifications to reflect these changes... In particular, I added the “Repositories” extended column, which show the number of repositories in the project. Besides I added two other extended columns: “Forums”, which shows the number of forums in the project, and “Forum messages”, which shows the number of messages in all project forums.

This version also comes with the Turkish translation, thanks to Ismail Sezen!

Did you wonder how does one know, when new Redmine version is released?.. I get to know this, usually, by checking #redmine tag in Twitter... How can you know when new Extended Fields is released?.. You can: a) Follow me on Twitter, b) Subscribe to the news feed which is available under the News tab and... c) Oh, yes! You can subscribe to the Extended Fields project using the subscription form on the sidebar! There you can choose what types of notifications you want to receive (down to notifications about commits). This functionality is provided by my Subscription plugin, which has not been released yet.

P.S. What plugin is the next?.. And the next plugin is... Extended Profile!

So this is the second my plugin which is released with Redmine 2.x support (Changes made by user#294 in his fork on Github were very helpful! Thanks, user(Oleg)#294!)! In addition to support of new versions this plugin comes with bug fixes which make it more stable and not a beta anymore.

However there are also some features... For example, now along with the “Help” link for Wiki formatting you will find “More” link. Clicking on this link opens quick reference for WikiNG syntax. So now a user will be able to see what syntax options are available and by which plugin are they provided (there is an “advertisement” at the bottom of syntax reference). The latter, I believe, is very important as I don’t want users to get confused with Redmine Wiki syntax.

By the way, thanks to Dave Carlton for the idea to make such syntax reference!

The new version includes also some other minor features: Thus now WikiNG support dashes – and —, replaces single quote with apostrophe, and supports arrows: ←, ↔, →, ⇐, ⇔ and ⇒.

Hidden text¶

But the most interesting bug fix (which can be treated as a new feature though) is... ability to see the hidden content! You can say: Hey! What is the sense of hiding content if it can be seen? My answer would be: It’s not so simple!..

You see, right now any user can add a hidden content! This means that a user having write permission to Wiki content can write, e.g.:

This is the {{version < 2.0}}beautiful!{{version}}/{{version >= 2.0}}awful!{{version}} plugin! Do you agree?

And when checking content administrators will fail to see the hidden text! On release of 2.0 this content will becomes visible and meanings of all Yes-answers will change...

I thought a lot how to prevent this... The first idea was to add “Add hidden content” permission. But Redmine does not provide any way to verify Wiki content! Of course, it is still possible to verify it but there are too many objects/models where this should be done! Even if I did this the Wiki content verification in objects provided by third-part plugins would get broken. As a result WikiNG plugin can conflict with other Wiki-enabled plugins... So I came to the idea of showing this content to users which have permissions to see it... For this purpose I added “View hidden content” permission. Hiden content is shown for such users a little bit transparent:

ChiliProject notes¶

Unfortunately in addition to additions... this version contains subtractions... But they apply only to ChiliProject!

!{{version}} and !{{date}} have syntax of macros (while they are not macros, in fact). In ChiliProject inside {{ ... }} you specify variables... Tags, analogue of macros in ChiliProject, are specified using {% ... %} (thus {{hook}} macro have syntax {% hook(...) %} there). This is the first conflict...

On the othet hand ChiliProject already supports conditions with its Liquid markup language. E.g.:

{% if ... %}
Dynamic content
{% endif %}

So, if I had to design version and date condition for ChiliProject, I would conclude that it should be something like:

{% if project.version >= x.x.x %} ... {% endif %}
{% if date < '2012-04-21' %} ... {% endif %}

In other words it should be a completely different solution for ChiliProject! For this reason I decided to disable !{{version}} and !{{date}} macros for ChiliProject 3.x and above...

Unfortunately right now I cannot find time to provide a solution for ChiliProject... The problem is also that I’m not sure that ChiliProject does not have an alternative... Thus, it supports project variable but only name and identifier seem to be available? It’s possible to display date using something like 'now' | date format but can it be used in if?.. Overall I got the feeling that I need some advice... Please contact me if you can help!

Subscription¶

Reminding you that you can subscribe to this project using the form on the sidebar. Having subscribed you will receive the latest news, will be notified about new releases and so on (depends on items you choose).

P.S. So the next is... Extended Fields!

SCM Creator 0.4.0 was aimed to support Redmine 2.0.x and Rails 3... So to port it I installed clean Redmine 2.0.x with SCM Creator 0.3.0 and the first thing I noticed was that I could not migrate the plugin because of error:

uninitialized constant RepositoryObserver

So I applied the fix:

Rails.configuration.active_record.observers << :repository_observer

After that the plugin migrated! Being happy with it I continued porting...

Then, almost before making the release, I discovered that RepositoryObserver does not get called! And, to my surprise, returning to ActiveRecord::Base.observers << :repository_observer worked for Redmine 2.0! I assumed that there was something else, that I had fixed along with this issue, and made the release...

But then it has been discovered that it does not work for all of us! Fixing this weird issue has ended with this emergency release!

Many thanks to Rob Landry for discovering the issue and assisting in fixing it!

Thanks also to Ismail SEZEN for Turkish translation and to Fabien Crespel for update of French translation!

Redmine 1.4.x and Redmine 2.0.x were released quite a long time ago and only now SCM Creator supporting these versions was released! And it is only the first my plugin for 2.0.x...

This release could not, perhaps, come so “early” without the kick of Takashi Okamoto! He assisted me a lot in porting SCM Creator to multiple repositories and Rails 3/Redmine 2. He even created a fork for doing this on Github: https://github.com/okamototk/redmine_scm_creator. Thanks Takashi Okamoto!

Before I planned to release it as 0.3.1. But thanks to Okamoto who suggested 0.4.0 I changed my mind. It’s too much changes for versioning it as 0.3.1. So it is 0.4.0!

So let’s talk about changes:

Support of multiple repositories, which appeared in Redmine 1.4.x, was not a feature for me... it was a headache!

Before there was a single repository and one, who was willing fo have all repositories created, could just set auto_create to force and deny_delete to true. This one could be sure that no one was going to add external repositories. Now this got broken!.. So as a workaround I added only_creator option which allows only creating repositories and denies adding, however SCMs not supported by this plugin should be disabled...

But that was not the main issue! How many repositories can one create?.. So I thought it’s not a good idea to let users creating infinite number of repositories. That’s why I also added max_repos option. This option specifies the limit of repositories which can be created using SCM Creator.

A long time ago Blaž Podržaj discovered an obvious issue which I missed for some reason... When auto_create was set a user was suggested (or forced) to create a repository on project creation. And it got created despite the value of the “Repository” checkbox under modules list... With this release SCM Creator takes this value into account and won’t create repository if it is not checked! But...

What should those users do who liked this behaviour?.. Before they were getting repository despite of the “Repository” module availability. I can imagine that some users reckon on the old behaviour... So for such users I added force_repository option which just enables “Repository” module and does not let disabling it!

Note that it is still possible to disable the “Repository” module later in project settings! It’s not a bug - it’s current implementation as I want to see what users think about the force_repository option... And by disabling “Repository” users will just hide it, not remove.

Also all the time in Redmine there was a security issue... Redmine guys name it “invalid configuration issue” and recommend giving the :repository_manage permission only to trusted users. I don’t agree. You can trust users but can you trust their passwords? Can you trust their Internet connection?.. With multiple repositories this issue became even more noticable so I decided to provide and enforce the solution. This solution uses two new options: allow_add_local and allow_pickup.

This release of SCM Creator has also a special meaning for my other plugins - having practiced with porting Redmine plugins to Rails 3/Redmine 2, I’m sure, I will port other plugins faster (unless they contain some bugs)...

Also reminding that you can subscribe to news, new versions, commits etc by using Subscription block on the sidebar.

P.S. WikiNG, you come next!

Having created this plugin I thought that I would perhaps never update it... It’s too small and too complete! But thanks to Bynn Ies who have found a bug (#1966) in this plugin you can now download its new version.

The previous version of the plugin supported only automatic activation i.e. anyone who was able to login into OpenID provider was about to get access to Redmine. While usually it’s not a problem some administrators may need to control who is having access...

Redmine supports three options of new account activation: a) automatic (was the only one supported by this plugin before), b) manual (support for which has been added) and c) email activation. Only email activation is not supported by this plugin and is not planned to be supported as I assume that you trust OpenID providers enough not to validate user emails provided by them. But if you believe that support for email activation still needs to be added please file a bug report and explain why do you think so.

As I usually recently do in news... I suggest you to subscribe to this project using the form on the sidebar. This form is added by my Subscription plugin which is going to be released soon...

Ok, I ask my users for a company they work in (using Extended Profile plugin which uses Extended Fields)... But how do I see what they answer?.. No, really? Of course, I can check profiles. But, hey, right now I have around 150 active (in terms of Redmine) users’ profiles to check!.. Honestly – my opinion is that custom fields are useless unless you can easily list them...

The same applies not only to custom fields. I always wondered how can I list projects and their download counts. Even used SQL to do that! Even planned to write a plugin for this (see #1745)... But I found the workaround! And it became the main feature of the Extended Fields plugin version 0.1.0!

So now the Extended Fields plugin extends... listings! In partucular – users listing and projects listing which are available for administrators. The plugin adds customization to these listings by allowing to specify which columns and/or custom fields to show (like it is already done for issues listing). Besides just columns the plugin also adds special columns allowing to show calculated data (that’s how I get download counts)...

As a part of The Rename the identifier of the project has been renamed to extended-fields with this release! Most users won’t feel the change! Only those who use SVN. SVN users will need to execute the following command to fix their repositories:

$ svn switch --relocate http://svn.s-andy.com/redmine-fields http://svn.s-andy.com/extended-fields

All users should also consider subscribing to the project using the form (on the sidebar) provided by my new Subscription plugin (which suffer testing right now – that is by subscribing you also help me testing it). Why subscribing? For example, being subscribed you would get notification about this release and this news...

P.S. I thought about changing plugin name to something what reflects new features as Extended Fields name does not tell anything about listings... But what name? Extended Fields & Listings?.. Extended Columns?.. Maybe Extended Redmine? Well... Fields are related to listings and columns! So decided to leave its current name.

Download Download Button 0.0.3

The new version would not be as it is without efforts of Andreas Schuh! Current implementation of the most cool new feature in 0.0.3 – of the !{{download}} Wiki macro – is his merit! He suggested inline customization of button properties, cross-project Wiki buttons, CSS customization and so on. He also did a lot to make the “Download” button work in ChiliProject 3.0!

Two other guys – Mario Luzeiro and Varun Shoor – also influenced the plugin. Thanks to them I decided to always show the “Download” tab (but with a warning if a closed version is not available) and added important notes to new file, version and other forms...

With this release the project also changes its identifier from redmine-download to download-button! Thanks to Project Alias the old identifier will still work!.. But not for SVN! For SVN to work you need to execute in your SVN project root directory:

$ svn switch --relocate http://svn.s-andy.com/redmine-download http://svn.s-andy.com/download-button

By the way, I would like to announce my another plugin - Subscription (it is in testing right now)... With its help you can now subscribe to the “Download” button project news (use the “Subscription” form on the sidebar).

Along with the update I also changed SVN URL (and project identifier)... But forget to notify! Oops! Sorry!

To update your SVN repository you should do:

$ svn switch --relocate http://svn.s-andy.com/redmine-profile http://svn.s-andy.com/extended-profile/v0

This command will just correct your SVN repository! That is you still will be using version 0.0.x!

To upgrade to 1.0.0 follow this guide...

I love Redmine for its Wiki! But have you felt that you are missing some Wiki rules?..

I often felt that I would like to add a warning or a notice. The only way to do this was using custom style classes like p(custom-class).. But I found this too late... And this is not about writing Wiki - it’s about creating HTML page with custom CSS styles! So I decided to write <warning>, <notice> and <tip> rules.

Sometimes also when I was writing a Wiki page I used to come to a section I could not describe yet (e.g. a feature not yet ready). As a developer I wanted to write something like {TODO}... You can do this now with this plugin:

This feature is and many markers are . If you have some ideas what markers can be added (meaning write me) or feel to issues list...

I also got used using smileys. I even use them in Redmine while I do know Redmine does not support them. Well... Did no support them! Cause this plugin adds support for smileys as well...

My procedure for releasing new versions of plugins is:

• Write the code;
• Update documentation;
• Release.

The problem is that it takes time to update documentation. Therefore for some time Wiki pages became too new. So I thought it would be great to have a macro for hiding some content untill new version is released... Now this can be done with {{date}} and {{version}} macros.

You probably know that I also have written the Hooks Manager plugin which is actually a hooks content manager (going to rename it). When working on it I thought that I missed some hook which would add ads to content of a Wiki page. I thought a lot on how this could be done... The solution I found is to add a new Wiki macro {{hook}}. You just write !{{hook(name,arguments)}} and this plugin will add and call :wiking_hook_name hook... So if you are an HTML guy you can add any content to a Wiki page!

For more information on the syntax provided by this plugin check this page. Use the Playground to play with the syntax.