Projects: Issueshttp://projects.andriylesyuk.com/http://projects.andriylesyuk.com/plugin_assets/andriy_lesyuk/images/s-andy.ico2013-09-03T14:20:15ZProjects
Redmine ISSUE-id - Support #ISSUE-1 (Deferred): Need a function to display issue idhttp://projects.andriylesyuk.com/issues/ISSUE-12013-09-03T14:20:15ZAndriy Lesyuks-andy@andriylesyuk.com
<p>The ISSUE-id plugin adds the <code>issue_id</code> function, which is used to generate the featured id. Also the <code>to_param</code> function is used by Redmine to put the correct ID into links etc. The plugin also patches a <ins>lot</ins> of other native Redmine functions to replace native Redmine issue id with the featured one.</p>
<p>This could be <ins>much easier</ins>, if Redmine came with a special function for displaying issue ids, which could be named, e.g., <code>display_id</code>! So when the plugin is released I need to make such suggestion to Redmine guys...</p> Extended Fields - Support #2221 (Deferred): Need a fix for _list.html.erbhttp://projects.andriylesyuk.com/issues/22212013-09-03T14:15:07ZAndriy Lesyuks-andy@andriylesyuk.com
<p>I just found (that is, remembered) that the only reason the Extended Fields comes with the pre-patched <code>_list.html.erb</code> is that the <code>group</code> variable is not translated into string. This could be fixed in the core Redmine and can potentially lead to other bugs in third-party systems and Redmine itself.</p>
<p>So, I need to check this again and file a fix request to Redmine.</p> WikiNG - Feature #2076 (Open): HTML Color previewhttp://projects.andriylesyuk.com/issues/20762012-06-28T12:30:35ZAndriy Lesyuks-andy@andriylesyuk.com
<p>If WikiNG meets HTML color code like #C07600 it can make an inline preview by rendering a little box before the color code...</p> Projects - Enhancement #2036 (Open): Global newshttp://projects.andriylesyuk.com/issues/20362012-05-21T22:13:42ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Some news can be global... That is related to all projects (for example: <a href="/news/42">Upgrade is pending</a>).</p>
<p>So it would be cool to have some “Global” checkbox in the news edit form.</p> Extended Fields - Feature #1881 (Open): Support wiki toolbar for "Default value"http://projects.andriylesyuk.com/issues/18812011-10-26T20:39:05ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Right now it seems to be very complicated and is not critical... So “postponing”.</p> Projects - Feature #1837 (Open): Andriy is now working on...http://projects.andriylesyuk.com/issues/18372011-08-31T17:03:21ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Just an idea:</p>
<p>I usually work on one of the projects... So on the website somewhere can be a status e.g. “Andriy is now working on <ins>Download</ins>” (where <ins>Download</ins> is a link). On the other hand if I don’t work on any of the projects (e.g. freelancing) - “Andriy is now working on his other projects...” <span class="wiking smiley smiley-smiley" title=":)"></span></p>
<p>The status should be triggered manually (using e.g. <a href="/projects/orangutan">Orangutan</a>).</p> Projects - Feature #1804 (Incomplete): Arrows (or similar solution) for project menuhttp://projects.andriylesyuk.com/issues/18042011-07-14T03:26:05ZTim Lin
<p>See attached picture.</p> SCM Creator (+Github) - Feature #1757 (Incomplete): Allow subdirectorieshttp://projects.andriylesyuk.com/issues/17572011-05-30T09:47:58ZJean-Sébastien Bourjsb@zenexity.comOrangutan - Enhancement #1600 (Open): Change configuration file formathttp://projects.andriylesyuk.com/issues/16002011-02-01T13:15:49ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Current configuration file format is too simple and too limited. I believe Orangutan configuration should be flexible and extendable. So change of configuration file format is needed.</p>
<p>What is the problem? There were an idea to allow changing weight of contexts using configuration file. With current format it would look like this:<br /><pre>
contexts.weight = Issue:-10
contexts.request_weight = Issue:-10
contexts.response_weight = Issue:undef
</pre></p>
<p>This looks odd... <span class="wiking smiley smiley-sad" title=":("></span></p>
<p>So the idea is to change to something like:<br /><pre>
Context Issue {
Weight {
Request -10
Response undef
}
}
</pre></p>
<p>The current file will look like this:<br /><pre>
Changelog Changelog
DisplayName "%f %s"
Admin user@localhost
Manager user@localhost
UsersDirectory Users
UsersData Data
ContextsDirectory Contexts
MonkeysDirectory Monkeys
Contexts {
Policy Exclude
Include Issue
Include Task
...
}
Monkeys {
RedMonkey redmonkey@localhost
}
Jabber {
Hostname localhost
Port 5222
...
}
Context Issue {
Field SomeField Value
Option SomeOption Value
}
Include weights.conf
</pre></p>
<p><strong>Note:</strong> The format is subject to change.</p>
<p>It would be also great if functions to access configuration values would look like this:<br /><pre>
$main::config::Monkeys::RedMonkey;
</pre></p> Orangutan::Redmine - Enhancement #1596 (Open): PostgreSQLhttp://projects.andriylesyuk.com/issues/15962011-01-29T18:55:45ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Currently Orangutan supports only MySQL. Redmine support MySQL and PostgreSQL. So what about adding support for PostgreSQL in Orangutan?</p>
<p>Of course, this is not a “critical” task for the moment. But for people using Redmine with PostgreSQL it would be great to have PostgreSQL support...</p> Orangutan - Enhancement #1465 (Open): Paginationhttp://projects.andriylesyuk.com/issues/14652010-12-28T17:57:53ZAndriy Lesyuks-andy@andriylesyuk.com
<p>With functionality growth more and more contexts output a huge text... Some clients may handle such huge messages slowly. Anyway such messages are not readable and sometimes users do not want to receive such huge messages (e.g. user requested for issues list but did not know that there is a huge number).</p>
<p>Making pagination for each context is not accessible, I believe... So the idea is to create Pagination context. Which would “catch” huge messages in output filter and split them into smaller. This context would store split messages in internal buffer and will output the them on requests. Samples:</p>
<pre>
User: Show page 2
User: Next page
User: Next
</pre> Orangutan - Enhancement #1075 (In Progress): Separate Orangutan core (reusable bot code) from Red...http://projects.andriylesyuk.com/issues/10752010-10-30T13:44:08ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Orangutan architecture is quite flexible and allows to create bots quickly and easy. So the bot platform can be much more popular than Orangutan Redmine bot...</p>
<p>However currently Orangutan and its Redmine part are actually the same. For example, one of the core objects is Query which is responsible for accessing DB. Many bots won’t need it - so it should be “removed” from the core.</p>
<p>Also some of contexts require extending core objects like Date etc. I think it can be done by “monkey patching” technique...</p> Orangutan - Enhancement #994 (Open): Topics or response modeshttp://projects.andriylesyuk.com/issues/9942010-10-14T14:16:31ZAndriy Lesyuks-andy@andriylesyuk.com
<p>The Comment context switches input into “catch all” mode - that is everything typed is taken as notes (but before this context there are NonASCII, YesNo, Cancel and some other contexts). If you for some reason decided not to post comment but already switched to this “catch all” mode. And already called some othe contexts (for example, typed cyrillic text (NonASCII)) the “undo” will not work! So there will be no way to cancel context...</p>
<p>Actually would be. As a temporary solution I modified Cancel context to check if the Comment context is in “catch all” mode and if it is it will always cancel it. But this is only a temporary and dirty solution...</p>
<p>Situations like this make me search for some way to extend Orangutan architecture... I think that such “modes” can be a normal thing and in future and many other contexts can use them. In this case tweaking the Cancel context won’t help. Some of these context can require some other context to be before them in the queue - so moving the Comment to the beginning also won’t help...</p>
<p>Currently this is only idea which is to be developed but... We can add “modes”. Modes will have their own set of contexts. A sample of a mode can be issue creating mode (by the way one of the future tasks). In this mode there will be many special context for editing. Modes would also allow the same context to behave different depending on the mode set (MainIssue and Issue context could be merged if special “task editing” mode was added).</p>
<p>Some possible API look:</p>
<pre>
$user->Enter('issue', %options);
$user->Exit('issue');
</pre> Orangutan - Enhancement #974 (Open): Rich text/formatting supporthttp://projects.andriylesyuk.com/issues/9742010-10-12T17:25:15ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Many times I thought it would be great if text written by Orangutan would be “colorized”... This way we can highlight urgent issues, highlight important part of messages etc.</p>
<p>Preliminary research if it is possible did not give any results. Looks like XMPP library used does not support this (rich text messages). But... Should it stop us? <span class="wiking smiley smiley-smiley" title=":)"></span> There is always possibility to improve things even if this is third party lib...</p>
<p>Any help (with research e.g.) would be appreciated!</p> Orangutan - Enhancement #910 (Open): Subjects or make Orangutan remember issue id, project etchttp://projects.andriylesyuk.com/issues/9102010-09-20T13:42:31ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Many new contexts are coming... Most of them are related to issues.</p>
<p>Right now when we work with tasks we talk like this:<br /><pre>
User: Working
Orangutan: Ok...
User: Change activity to Development
Orangutan: Ok...
User: Started at 15:00
Orangutan: Ok...
</pre></p>
<p>That is we do not refer to the task... Orangutan “remembers” current task and does not require as to specify its ID or something like this...</p>
<p>With issues we have completely different situation - we need to specify ID each time!.. But why not?:</p>
<pre>
User: #203
Orangutan: Issue #203...
User: I like it!
Orangutan: Glad you do!
User: It's my main issue now
Orangutan: Ok...
</pre>
<p>You see? Orangutan can remember such things...</p>
<p>How to implement?</p>
<p>I see the following solution:</p>
<pre>
$user->SetTopic('issue', $issueid);
</pre>
<pre>
if (!defined($issueid)) {
$issueid = $user->GetTopic('issue');
}
</pre>
<p>That is I suggest to implement “topics” - internal variables which contain the topic of discussion... Of course many context should be modified to use/save topics... Topics should have time out (SetTopic should save current time).</p>