Here's some suggestion I gathered up:
Suggestion #1:
--------------
Attribute order should be user defined, not necessarily alphabetical.
New attribute type: textarea (more than one line of text)
Example: When I add a bug issue, I want to write a short name for the issue and then a more detailed
information describing the problem. The comment thing only shows up on Issue History, which is not
very convenient. So what I would like to do is to add a Description attribute, which would allow me
to write a comment-like paragraph of text, and place it to the bottom of the attribute list.
Another option: Add a default property for every Issue Type which would place the first comment made by the
author of that Issue to the Issue Details page.
Suggestion #2:
--------------
Main view/Project list:
Would it be possible to show the amount of open/closed issues after each folder?
3rd useful column would be the issues assigned directly to me.
Suggestion #3:
--------------
An OSD type notification for new issues.
The webissues has a setting to update (for example) every 5 minutes. It would be very useful if it
could pop up an OSD like notification if there was some new issues found.
That's all for now. :)
- Log in to post comments
Thanks for sharing your ideas :).
Changing attribute order is a good idea. It could be done in a similar way like selecting columns in the list of issues, with the exception that all attributes would be shown, so only the order can be modified.
The problem with a text area / description is that attribute values are limited to 80 characters and dealing with longer / multiline text is problematic - think of the list of issues, history of changes etc. I have an opinion that all longer pieces of text should be included in comments, not attributes. But indeed, we could treat the first comment as the description and (optionally) show it on the details page. I'll see how this would look.
Showing the number of issues and notifying about new issues is something I had in my mind for some time. The problem is that the client doesn't know the contents of a folder until the folder is opened. A solution would be to allow to "subscribe" to a selected folder - it's contents would be periodically updated and you would be notified when new issues appear. Another thing is that configuring those notifications could get complicated - for example you might want to be notified whenever an issue assigned to you is modified or when an issue is closed etc., etc. What do you think?
Regards,
Michał
A weird question: Why exactly is the attribute value limited to 80 characters? MySQL surely supports varchar(255) or even longtext, so it must be a client problem?
But yea, I agree, the best way to do it would be the first comment made by the person who created the issue. And add it to the Issue Details.
And yes, the versatility of the notification is going to be a problem. :)
People want different things, so it should be planned well before even tried, in my opinion.
I like the idea of subscriptions, it would allow a person to subscribe to bugs, but not get notified of new feature issues, etc. if not wanted.
I don't think the notification should pop up if someone modifies an issue that belongs to you, I'd rather see it marked as changed or back to new status. (bold or something)
And when issue is closed.. I don't think anyone would want a notification out of that. But you never know. =)
The limit of 80 characters is only arbitrary - it just doesn't make sense to put more because you wouldn't see them anyway :).
If the notifications should only pop up when new issues are added then it's simple. As you said, you never know what someone would want, but it's a good start anyway, so maybe it's worth trying.
Marking issues as new or changed is also on my to-do list. One possibility is to mark issues as never opened, changed since last opening or up-to-date. Another possibility is to mark them as new or modified since last [login | opening the folder | refreshing the folder | something else], as probably you wouldn't want to see a 12 months old issue marked as "new" just because you never opened it. Or maybe use some combination of both? I have to think about it a bit more.
Regards,
Michał
Actually it doesn't really matter that you can't see more than 80 characters in the client, because I can think many other uses for the data stored in the database. For example, making a little script that prints solved issues from the database, etc. Or just porting the data to some other software, etc, etc. :)
You're right, but still the primary use of the data is the client. By the way, printing will be possible soon, so why would anyone ever want to use any other software? :)
Seriously now, this limit can theoretically be increased to 255 characters, but then there is a problem with pre-4.1 MySQL databases. They don't support UTF-8 and in the worst case they may treat an 80 characters long string as 240 characters long if each character is encoded as 3 bytes.
Regards,
Michał
You need to do the same as major software companies would do, drop support for pre-4.1 mysql. :)
And you're right, why would I need to use any other software, especially if you manage to squeeze in all these new features. =)
And when issue is closed.. I don't think anyone would want a notification out of that. But you never know. =)
Well, for instance, a user requests a new feature or a bug to be fixed. When the issue is closed by another user (i.e. fixed), wouldn't it be nice to get a notification to say "your bug is fixed - give it a try now?".
Perhaps in that case what is needed is a "notifications email" attribute for issues? If you choose to include that attribute then any email address entered against it get notifications of status changes?
This is, of course, where a general-purpose tool like WebIssues starts to get fiendishly complicated if it is to be capable of being customised as much as an individual implementor might like!
Attribute order should be user defined, not necessarily alphabetical.
New attribute type: textarea (more than one line of text)
What I'm doing is to just make the Name of the Attribute "01. Assigned To" etc. Not ideal, but it works!
Perhaps in that case what is needed is a "notifications email" attribute for issues? If you choose to include that attribute then any email address entered against it get notifications of status changes?
This is another very good use for a custom cron job; definitely not something to be included in the "core" of the WebIssues server.
Regards,
Michał
This is another very good use for a custom cron job; definitely not something to be included in the "core" of the WebIssues server.
The problem, of course, is that in the end anything can be done as a custom job, but that just means that many non-techy users never benefit. In which case the product becomes a bit like big-iron ERP systems (e.g. SAP) where you can have anything you like provided you're willing to spend the money on integration, but the core functionality is just a framework.
What I'm trying to do is to consider things (as I come across them in my evaluation of WI) that would make some sense (to me, at least) to be provided generically.
Perhaps what is needed is some way of writing "modules" that add specific functionality? That way I (or somebody else) can write something that is relatively generic, and then others can decide whether to use it or not?
You might say "but the WI server can't run a cron". No, it can't, but then nothing I've talked about so far necessarily needs to happen when no users are logged-in. So the periodic refreshes by clients can be the "trigger" and the server code just needs to implement an "if I'm refreshed and I haven't done this periodic job in the last 30 minutes, do it now".
Yes, I think extending the server with "modules" implementing custom "hooks" called in particular circumstances (or just periodically) is an excellent idea. That would allow advanced users to contribute to WebIssues easilly and non-techy users to get out-of-the-box solutions. If you can help with writing such modules (as my resources are limited), that would be really great. We could think about some kind of interface for integrating the server code with the modules.
Regards,
Michał
Hi
OK, I'll have a think about this. My name's Silas, by the way; please to "meet" you!
I need to spend a bit of time examining the server code, so I may go quiet for a day or two whilst I do that. Also, is the client code identical (i.e. just recompiled for each platform)?
Suggestion #3:
--------------
An OSD type notification for new issues.
The webissues has a setting to update (for example) every 5 minutes. It would be very useful if it
could pop up an OSD like notification if there was some new issues found.
The issue of what notifications to provide and when would need to be configured on a per-Folder basis. So we'd need new attribute types. We then need to decide what the notifications should be. Here are some suggestions:
Attribute type: Notification (email)
Attribute value: Email Address
Attribute value: Email sender
Attribute value: Email title
Attribute value: Email priority
Attribute value: Which value change as trigger?
Attribute value: Which new value to notify on?
Attribute value: Notify on new issues?
Attribute type: Notification (sms)
Attribute value: Destination mobile number
Attribute value: Message (limited to xx characters)
And so on and so forth - the list of potential attribute values is quite long, but could be made very configurable.
There are wider issues here. We'd need email capability, sms and pager gateway libraries, and so on. But it is all achievable with code that is not at all unavailable!
But first I think the modules issue needs to be considered so that a sensible plug-in framework can be developed to make this stuff work well.
Nice to meet you too :).
Things like emailing and sending sms messages are good candidates for modules. However to configure them per-folder you cannot use attributes - you can assign attribute values to issues, but not to folders.
Perhaps the modules could have a simple web interface which would allow the administrator to configure notifications for folders. Doing this through the desktop client would be much more difficult - the modules would need the ability to extend the communication protocol and the client would have to detect and support these modules. Since this is a purely administrative job, I think a web interface would be perfectly sufficient, and this way creating new modules does not require modifying the client. What do you think?
Edit: Yes, client code is identical for all platforms.
Regards,
Michał
Things like emailing and sending sms messages are good candidates for modules. However to configure them per-folder you cannot use attributes - you can assign attribute values to issues, but not to folders.
Perhaps the modules could have a simple web interface which would allow the administrator to configure notifications for folders. Doing this through the desktop client would be much more difficult - the modules would need the ability to extend the communication protocol and the client would have to detect and support these modules. Since this is a purely administrative job, I think a web interface would be perfectly sufficient, and this way creating new modules does not require modifying the client. What do you think?
Sorry, I was getting ahead of myself and not explaining. Instead of changing the architecture to include "attributes" for folders per se, I thought instead about creating "hidden, system attributes" for issues which only the administrator could see (checkbox against each attribute). These would be set in the Issue Types screen (so, yes, it would mean Issue Types set up this way would be only applicable to a single folder, but for my purposes I haven't got any re-usable Issue Types at all yet!) and would be set automatically for every issue that was created, but would be invisible to the Clients in the normal viewing of issues.
This would enable a simple server-side parser to be implemented, which simply parsed all the issues every (say) 5 minutes, looked at the attributes of every issue in turn, and decided what to do with it. This would be very easy to implement now.
Alternatively one could have the same hidden, system attributes for a folder, but implement it that way only as an interface decision (i.e. it still tacks on the attributes to each item, but just adds them to items in that folder, not for all items of that Issue Type).
Another alternative is, as you say, to change the architecture and/or develop a plugin, and use a web interface to configure it. But then you've got a whole new code base to maintain for the web interface, and so on.
Obviously a plugin could still be the way to implement this ("plugin Notifications EXTENDS Base or somesuch").
Silas