Projects: Issueshttp://projects.andriylesyuk.com/http://projects.andriylesyuk.com/plugin_assets/andriy_lesyuk/images/s-andy.ico2018-02-20T10:11:57ZProjects
Redmine WikiNG - Bug #2440 (Open): Footnotes ignore < pre >http://projects.andriylesyuk.com/issues/24402018-02-20T10:11:57ZИльфат Аминов
<p>Inside of < pre > blocks footnotes (double parentheses) not ignored by Wiking formatter.</p>
<p><img src="http://projects.andriylesyuk.com/attachments/download/670/wikiedit.png" alt="" /></p>
<p>⇒</p>
<p><img src="http://projects.andriylesyuk.com/attachments/download/671/wiki.png" alt="" /></p> WikiNG - Feature #2438 (Open): Screen texthttp://projects.andriylesyuk.com/issues/24382018-01-05T14:56:29ZAndriy Lesyuks-andy@andriylesyuk.com
<p>I often need to highlight somehow a text, which is displayed by the user interface of a discussed application. For example:</p>
<ul>
<li>Click the “Apply” button</li>
<li>Go to “Administration” → “Settings” </li>
<li>Use “to these roles only”</li>
</ul>
<p>The last example demonstrates, why it’s imported to have such text highlighted (otherwise, it can be unclear, where the screen text ends).</p>
<p>It would be ideally, if something like back quotes could be used (which are used for code in Markdown). Quotes look natural. But, I don’t think, that just quotes are a good option. Such screen text should also have different color and/or decoration.</p>
<p>As an option: double single quotes, i.e., <code>''Apply''</code>.</p> Orangutan - Improvement #1620 (Open): Fix foreign handlers APIhttp://projects.andriylesyuk.com/issues/16202011-02-03T16:17:29ZAndriy Lesyuks-andy@andriylesyuk.com
<p><code>Orangutan::Context</code> has API for accessing, setting and managing foreign handlers... But they are called “manually” that is a developer needs to define handler and write special code for calling foreign handlers of the context. This looks like “hack”! I believe with foregn handlers defined the context can be (and even should be) without the handler. And the handler should be define only to overwrite the default handling of foreign handlers!</p>
<p>So we need to improve foreign handlers API so the context without the hander would be able to use foreign ones.</p> Orangutan - 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::Redmine - Enhancement #1616 (Open): Redmine notification for changes made in Orangutanhttp://projects.andriylesyuk.com/issues/16162011-02-03T12:15:15ZAndriy Lesyuks-andy@andriylesyuk.com
<p>When a change is made in Redmine - both Orangutan and Redmine will notify users about a change. But when a change is made in Orangutan - only Orangutan will know about it. In some way this <strong>breaks</strong> proper behaviour of Redmine. And this should be fixed (I guess users won’t be happy if they miss something).</p>
<p>Possible solution is to create special Redmine REST API for notifications. When a change is made Orangutan will call some “function” to let Redmine know about the change. Then Redmine will emulate the change and notify everyone (we should ensure that Orangutan won’t get these notifications or will be able to recognize them).</p> Orangutan::Redmine - Bug #1613 (Open): Guarantee that a notification will come to end userhttp://projects.andriylesyuk.com/issues/16132011-02-02T18:31:15ZAndriy Lesyuks-andy@andriylesyuk.com
Right now Orangutan notifies users about changes made to issues etc. But... There are several problems here:
<ol>
<li>If Orangutan crashes it won’t notify about changes made until crash (if he have not yet) – that is Orangutan should save the “pool” of notifications somewhere;</li>
<li>It does not take into account user’s Redmine notification settings (see <a class="issue tracker-6 status-7 priority-4 priority-low2" title="Respect user&#39;s Redmine notifications settings (Open)" href="http://projects.andriylesyuk.com/issues/1029">#1029</a>);</li>
<li>It does not send everything in a pool to a user – it sends only notifications less than 5 days old.</li>
</ol>
<p>I’m not sure about the last. Are you interested in getting notifications older than 5 days?!..</p>
<p>If this should be done better I guess to inform users about older notifications this way:<br /><pre>
Orangutan: ... <Actual notification 1> ...
Orangutan: ... <Actual notification 2> ...
Orangutan: ...
Orangutan: ... <Actual notification <N>> ...
Orangutan: There are 10 older notifications... Whould you like to check them?
User: Yes
Orangutan: ... <Old notification 1> ...
Orangutan: ...
</pre></p> Orangutan - Enhancement #1601 (Incomplete): Configuring contexts weightshttp://projects.andriylesyuk.com/issues/16012011-02-01T13:45:11ZAndriy Lesyuks-andy@andriylesyuk.com
<p>This was a part of <a class="issue tracker-7 status-5 priority-4 priority-low2 closed" title="Disabling contexts + maybe changing weight from config file (Closed)" href="http://projects.andriylesyuk.com/issues/1081">#1081</a> but I figured out that current configuration file format is too limited.</p>
<p>With current format such could be done with:<br /><pre>
contexts.request_weight = Issue:10
contexts.response_weight = Issue:10
contexts.filter_weight = Issue:10
</pre></p>
<p>This is odd!..</p>
<p>There should be an easier way to change weight like:<br /><pre>
Context Issue {
Weight 10
}
Context Task {
Weight {
Response 10
}
}
</pre></p>
<p>Changing weight maybe needed to change the priority of contexts. This way Orangutan will became more flexible.</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 - Enhancement #1562 (Open): Localisationhttp://projects.andriylesyuk.com/issues/15622011-01-23T13:58:51ZAndriy Lesyuks-andy@andriylesyuk.com
<p>The number of potential international users grows. There are several services in IF which can use Orangutan too. So the fact that it is only English can become a problem.</p>
What should be internationalized:
<ul>
<li>Output messages;</li>
<li>Input regexp queries;</li>
<li>Holidays calculation.</li>
</ul>
<p>The problem is that it is not so easy to localise program like Orangutan... Let’s review in details:</p>
<a name="Output-messages"></a>
<h3 >Output messages<a href="#Output-messages" class="wiki-anchor">¶</a></h3>
<p>Sample output message looks like this:<br /><pre><code class="php syntaxhl"><span class="CodeRay"><span class="local-variable">$message</span> .= <span class="constant">Orangutan</span>::<span class="constant">Context</span>::<span class="constant">Random</span>(
<span class="string"><span class="delimiter">'</span><span class="content">Be ready to receive emails now.</span><span class="delimiter">'</span></span>,
<span class="string"><span class="delimiter">'</span><span class="content">Emails are coming now... ;)</span><span class="delimiter">'</span></span>,
<span class="string"><span class="delimiter">'</span><span class="content">As you command...</span><span class="delimiter">'</span></span>
);
</span></code></pre></p>
<p>This should be replaced with something like:<br /><pre><code class="php syntaxhl"><span class="CodeRay"><span class="local-variable">$message</span> .= <span class="local-variable">$user</span>-><span class="constant">Localise</span>(<span class="string"><span class="delimiter">'</span><span class="content">Be ready to receive emails now.</span><span class="delimiter">'</span></span>);
</span></code></pre></p>
<p>Here “Be ready to receive emails now.” is a “base” message which refers to an array of localised messages...</p>
<p><ins>Note</ins>: String should be localised depending on user’s settings (on global ones if user’s settings are not set yet). That is user will choose the language.</p>
<a name="Input-regexp-queries"></a>
<h3 >Input regexp queries<a href="#Input-regexp-queries" class="wiki-anchor">¶</a></h3>
<p>It is perhaps the most complex part...</p>
<p>Sample request:<br /><pre><code class="php syntaxhl"><span class="CodeRay">response => [
<span class="string"><span class="delimiter">'</span><span class="content">^(?:Please )?((?:do(?:n</span><span class="char">\'</span><span class="content">t| not)|never|stop) )?notify(?:ing)?(?: me)? (?:by|using) e?-?mail(?: messages)?!*</span><span class="content">\.</span><span class="content">*$</span><span class="delimiter">'</span></span>,
<span class="string"><span class="delimiter">'</span><span class="content">^(?:I )?(do(?:n</span><span class="char">\'</span><span class="content">t| not) )?(?:want) to be notified (?:by|using) e?-?mail(?: messages)?!*</span><span class="content">\.</span><span class="content">*$</span><span class="delimiter">'</span></span>,
<span class="string"><span class="delimiter">'</span><span class="content">^(?:(Disable)|enable) (?:Redmine )?e?-?mail notifications!*</span><span class="content">\.</span><span class="content">*$</span><span class="delimiter">'</span></span>,
<span class="string"><span class="delimiter">'</span><span class="content">^Turn (?:on|(off)) (?:Redmine )?e?-?mail notifications!*</span><span class="content">\.</span><span class="content">*$</span><span class="delimiter">'</span></span>
],
</span></code></pre></p>
<p>Should be something like:<br /><pre><code class="php syntaxhl"><span class="CodeRay">response => <span class="constant">Orangutan</span>::<span class="constant">Lozalise</span>(<span class="string"><span class="delimiter">'</span><span class="content">^(?:Please )?((?:do(?:n</span><span class="char">\'</span><span class="content">t| not)|never|stop) )?notify(?:ing)?(?: me)? (?:by|using) e?-?mail(?: messages)?!*</span><span class="content">\.</span><span class="content">*$</span><span class="delimiter">'</span></span>);
</span></code></pre></p>
<p>Again, here "^(?:Please )...(?: messages)?!*\.*$” is a base query which will be translated to localised ones (more than one).</p>
<p><ins>Note</ins>: Unlike output messages input queries should be translated to queries using global settings. Besides it should be possible to define several languages for input queries. For example, for IF Orangutan should support ukrainian, english and russian. Anyway user’s settings (e.g. if user selected polish) can be taken into account too.</p>
<a name="Holidays-calculation"></a>
<h3 >Holidays calculation<a href="#Holidays-calculation" class="wiki-anchor">¶</a></h3>
<p>For holidays there should be special API allowing to extend Orangutan::Date.</p>
<a name="Conclusion"></a>
<h3 >Conclusion<a href="#Conclusion" class="wiki-anchor">¶</a></h3>
<p>Apparently we can’t use standard PO solution for Orangutan. At least because we need to support arrays etc. So own flexible solution is to be developed.</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 - 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> 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>