Projects: Issueshttp://projects.andriylesyuk.com/http://projects.andriylesyuk.com/plugin_assets/andriy_lesyuk/images/s-andy.ico2012-06-28T12:30:35ZProjects
Redmine 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> 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 #1618 (Open): Support subrequests in single request messagehttp://projects.andriylesyuk.com/issues/16182011-02-03T13:13:51ZAndriy Lesyuks-andy@andriylesyuk.com
<p>One of the limitations of Orangutan is that he mades currently a single change to Redmine. While in Redmine you can change several properties...</p>
Let me explain... Check this scenario:
<ol>
<li>User tells “100% done”, Orangutan saves this</li>
<li>Orangutan asks if user wants to close the issue</li>
<li>User agrees, Orangutan changes status + sets due date (in separate context)</li>
</ol>
What we will have? We will have three journals:
<ol>
<li>Changed done ratio to 100%</li>
<li>Changed status to Closed</li>
<li>Changed due date to XX/XX/XXXX</li>
</ol>
<p>The last two journals will have exactly the same date of creation!.. This can end up with many little journals!</p>
One of the possible solution is (when posting change) to "add" changes to the previous journal. But the issue with this solution are:
<ul>
<li>Some user will already get notifications about the journal without new change</li>
<li>The change date won’t be accurate</li>
</ul>
So the another (and better) solution is:
<ul>
<li>Support subrequests in user messages like:<br /><pre>
User: #1617 is 100% done, close #1617 and change due date to today
</pre><br />This should be the same as:<br /><pre>
User: #1617 is 100% done
User: Close #1617
User: Change due of #1617 date to today
</pre><br />But this should only create a single journal.</li>
<li>Postpone commit to the end of message handling.<br />That is if some another context is changing something on some event in its event handler it will be added to the same journal.</li>
</ul>
<p>P.S. Subrequests can be of completely different types, e.g.:<br /><pre>
User: #1617 is Closed and I am free now
</pre></p> Orangutan - 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 - Improvement #1089 (Open): Migrate to contexts dependencies/relations from weightshttp://projects.andriylesyuk.com/issues/10892010-11-03T12:10:12ZAndriy Lesyuks-andy@andriylesyuk.com
<p>When the project started I decided to use “weight” for contexts sorting in queue because it was easier... Now I needed to change all weight to “normalize” them. Besides if users begin write their own contexts there will be conflicts in weights. So now it seems better to use dependencies.</p>
<p>This means that “weight” member is to be removed and replaced with two or more members, e.g.:<br /><pre><code>...
after => [ 'Number', 'YesNo' ],
before => 'Task',
requires => [ 'Number', 'YesNo' ]
...
</pre></pre></p></code></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::Redmine - Improvement #1051 (Open): Allow applying only some tasks by number from sugg...http://projects.andriylesyuk.com/issues/10512010-10-25T22:22:47ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Let’s check WorkHours dialog:</p>
<pre>
09:47:29 Orangutan: There should be added 7 more hours to Tuesday. May I suggest you some tasks to add?..
09:47:37 User: yes
09:47:37 Orangutan: I would add the following tasks:
09:47:37 Orangutan: 1) 09:15 - 13:00: Working on #XXX for Project (Normal)
09:47:37 Orangutan: 2) 14:00 - 14:50: Working on #XXX for Project (Normal)
09:47:37 Orangutan: Should I add this?
</pre>
<p>What about allowing to select only some tasks?.. For example:</p>
<pre>
09:47:39 User: Apply 1)
09:47:39 User: Cool! X more hours left...
</pre> 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::Redmine - Improvement #973 (Open): Issue description change notificationhttp://projects.andriylesyuk.com/issues/9732010-10-12T17:22:14ZAndriy Lesyuks-andy@andriylesyuk.com
<p>If one changes issue description no one will get notified about this! This is a Redmine bug. But Orangutan could find some way to “fix it” for his users...</p>
<p>As an option - try finding some “hook” in Redmine which would allow to catch description change... How to implement this is to be investigated.</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> Orangutan - Improvement #862 (Open): Support user first and last name in requestshttp://projects.andriylesyuk.com/issues/8622010-08-31T13:43:42ZAndriy Lesyuks-andy@andriylesyuk.com
<p>Right now if you need to specidy user for some context you need to enter the username or Jabber ID... This is not very friendly...</p>
<p>The idea is to support queries like:</p>
<pre>
User: Assign to Andriy Lesyuk
User: Assign to Kostyantyn
User: Assign to Sergiy F.
User: Assign to Dmytriv
</pre>
<p>The algorithm should be smart enough to determine who is this user... For example, if user tells “Andriy” Orangutan should claim that there are many Andriy’s. If user tells “Kostyantyn” Orangutan should use Kostyantyn Kornienko because he is the only Kostyantyn etc.</p>