On 11 March 2014 04:45, Dammina Sahabandu <[email protected]> wrote:
> Hi Joe, > Yes my idea was to first create the tickets using the list (taking the list > elements as ticket summaries). Then display those created tickets as a > table where the users can add other details about those created tickets. > And when they click on 'save' those tickets will be updated accordingly and > display in a ticket query table. > > However it seems like your idea is more fitting for our requirements. So > please help me to interpret your idea more clearly. So your idea is to > create a table instead of a list in the fist place inside the wiki, and > the users should be able to add data to that table. Finally, when the user > clicks on 'save', the tickets get created, and using them we should modify > the table into a query table right? > That's right. - Joe > > > On Mon, Mar 10, 2014 at 8:45 PM, Joachim Dreimann < > [email protected]> wrote: > > > On 9 March 2014 08:44, Dammina Sahabandu <[email protected]> wrote: > > > > > Hi Joe, > > > Thank you very much for your valuable feedback and offering me help and > > > guidance in the implementation stage. And it really increases my > > > confidence. > > > > > > >> Yes, this should even be possible using plain CSS. If you position > the > > > >> button absolutely within the <ul> element to the top right for > > example, > > > you > > > >> can then set it to display: block; on ul:hover, display: none; > > > otherwise. > > > > > > Thanks for the snippet Joe ;) I'll use this for sure. (Just to be > clear, > > I > > > didn't mean we MUST use AJAX. In my opinion the technology doesn't > > matter. > > > AJAX,JAVA SCRIPT, CSS or whatever, please help me just to identify the > > best > > > way to get the best out come.) > > > > > > >> One way to do this would be to let users create a 'ticket table' > with > > a > > > >> simple macro: each row would be a new ticket, each column one > required > > > >> field. Once they are filled in and the user clicks save on the wiki > > > page, > > > >> all rows would be converted into tickets. > > > > > > Again thank you very much for the idea Joe. This will be a really good > > > solution, and somehow it never did come to my mind. I have attached > > another > > > mockup at [1]. Please take a look and let me know whether is that what > > you > > > have meant :) > > > > > > > Yes, your mockup is one approach that could work. When saving the > document > > this should turn into a normal ticket query table however, like we use > > elsewhere [0]. > > > > The other approach I meant to suggest is that this table gets created > > instead of a list, which users then fill in. When they 'Save' the tickets > > get created. Your mockup suggests that the list already exists and the > > tickets are created before the table gets displayed for the first time > > (links are in place). > > > > [0] See the 'starter tickets' table here: > > https://issues.apache.org/bloodhound/wiki/BloodhoundContributing > > > > > > > > > > [1] > > > > > > > > > https://issues.apache.org/bloodhound/attachment/ticket/231/design_mockup_v2.png > > > > > > > > > On Fri, Mar 7, 2014 at 9:59 PM, Joachim Dreimann < > > > [email protected]> wrote: > > > > > > > On 6 March 2014 15:42, Dammina Sahabandu <[email protected]> > > wrote: > > > > > > > > > Hi Gary, > > > > > First of all thank you very much for the quick reply. > > > > > > > > > > > Hi Dammina, > > > > > > I'll go through this in more detail later but I notice that the > > > > > > attachments that your refer to are not available. > > > > > > > > > > I know you got a really busy schedule. And of cause I'm not in a > > hurry. > > > > So > > > > > no worries, please take any amount of time to reply :) (And I'm > > really > > > > > sorry if I'm disturbing you with these minor issues). However, I > did > > > > attach > > > > > that mockup snap into the location that you suggested. You can find > > it > > > at > > > > > [1]. > > > > > > > > > > [1] > > > > > https://issues.apache.org/bloodhound/attachment/ticket/231/mockup.png > > > > > > > > > > Thanks > > > > > Dammina > > > > > > > > > > > > > > > On Thu, Mar 6, 2014 at 5:20 PM, Gary Martin < > > [email protected] > > > > > >wrote: > > > > > > > > > > > Hi Dammina, > > > > > > > > > > > > I'll go through this in more detail later but I notice that the > > > > > > attachments that your refer to are not available. I suspect our > > list > > > > just > > > > > > doesn't allow them to be added. That leaves a question of the > best > > > > place > > > > > to > > > > > > put them. Attaching them to https://issues.apache.org/ > > > > > > bloodhound/ticket/231 might be appropriate for now I suppose. > > > > > > > > > > > > Cheers, > > > > > > Gary > > > > > > > > > > > > > > > > > > > > > > > > On 06/03/14 11:38, Dammina Sahabandu wrote: > > > > > > > > > > > >> Hi Gary, > > > > > >> > > > > > >> Thank you very much for the quick detailed feedback. It really > > helps > > > > me > > > > > >> and motivates me a lot. Here I have briefly described few design > > > > > decisions > > > > > >> on how to solve the issues that we have discovered already. > > > > > >> > > > > > >> Regarding List tracking in a wiki page: > > > > > >> A regex pattern matching search for '*' , '1.' etc. markups in > the > > > > > >> complete content on the wiki page will be able to find all the > > > > numbered > > > > > >> lists and bullet pointed lists. But still I have to face the > > problem > > > > of > > > > > >> Intrusiveness. So I'm thinking of several ways to solve this > > issue. > > > > May > > > > > be > > > > > >> setting up a hidden comment(It should be some universal > > identifier. > > > > For > > > > > an > > > > > >> example > > > > > >> {{{#!comment > > > > > >> TicketList > > > > > >> }}} > > > > > >> ) in the wikitext to identify only the relevant lists will be a > > good > > > > > >> solution. I guess it won't be a considerable overhead for the > > user. > > > Or > > > > > may > > > > > >> be we can just implement an AJAX script for the buttons > > visibility. > > > > > That is > > > > > >> the 'Create Tickets' button for a particular list will only be > > > visible > > > > > for > > > > > >> the user when he is pointing the mouse pointer over that > > particular > > > > > list. > > > > > >> So by that way the user will only see one button at a time (Hope > > it > > > > > won't > > > > > >> be a big headache ;) ). So what is your opinion, will something > > like > > > > > this > > > > > >> work? > > > > > > > > > > > > > Yes, this should even be possible using plain CSS. If you position > the > > > > button absolutely within the <ul> element to the top right for > example, > > > you > > > > can then set it to display: block; on ul:hover, display: none; > > otherwise. > > > > > > > > I'm happy to help you with these sorts of things when you get to the > > > > implementation stage. > > > > > > > > > > > > > Anyway I will do some more thinking and try to figure out a better > > > > > >> alternative. > > > > > >> > > > > > >> Missing details in auto created ticket: > > > > > >> As you have mentioned, for this issue there are lots of > solutions > > > > > >> available. Currently I'm thinking of the following solution, > and I > > > > have > > > > > >> attached few mockups to describe the it. > > > > > >> 1. [mockup01] displays the initial view of the wiki when mouse > > > pointer > > > > > is > > > > > >> not over a relevant list. > > > > > >> 2. When mouse pointer is over a relevant list, the button > 'Create > > > > > >> Tickets' will be visible. [mockup02] > > > > > >> 3. After the user clicks on the button the creating process will > > run > > > > and > > > > > >> display the links to appropriate tickets. And when the user > > pointed > > > > the > > > > > >> mouse over a certain ticket a button to update details of that > > > ticket > > > > > will > > > > > >> appear.[mockup03] > > > > > > > > > > > > > The bit about update details for a ticket seems inconsistent with how > > > users > > > > can normally interact with ticket links they encounter elsewhere. I > > think > > > > it's ok if the user just clicks the link to go to the ticket page, > with > > > no > > > > extra button appearing here. > > > > > > > > > > > > > >> 4. Then if the user click on the button, there are two thing we > > can > > > > do. > > > > > >> i. Simply redirects the user to update ticket details pages. > > > > > [mockup06] > > > > > >> ii. Or generate a button list of required fields [mockup04] . > > > > (Assume > > > > > >> the state of the ticket will be 'new' and the reporter should be > > the > > > > > user > > > > > >> who add these list of tickets) > > > > > > > > > > > > > I think we can set sensible defaults for all required fields. > > > > > > > > > > > > > >> 5. If we choose the process (4. ii.), then the user can add > > details > > > > in > > > > > to > > > > > >> the fields one by one. [mockup05] > > > > > > > > > > > > > To edit multiple tickets, we should provide a link to an > appropriately > > > > scoped custom query that shows the tickets just created. We should > try > > to > > > > avoid introducing a separate way to do the same thing. > > > > > > > > >> > > > > > >> Hopefully all these user side changes can be achieved by few > AJAX > > > > > scripts. > > > > > >> > > > > > >> Another easier way to solve this is to define a standard way to > > > write > > > > > >> these ticket lists in wiki pages. So we just have to process the > > > list > > > > > and > > > > > >> extract the data appropriately. (Please let me know if this > seams > > > > > >> interesting to you. Then we can discuss this in detail.) > > > > > > > > > > > > > One way to do this would be to let users create a 'ticket table' > with a > > > > simple macro: each row would be a new ticket, each column one > required > > > > field. Once they are filled in and the user clicks save on the wiki > > page, > > > > all rows would be converted into tickets. > > > > > > > > > > > > > >> Another thing is I'm not really clear about the idea of handling > > > > > >> permission to add tickets using this feature. I mean as you > > > suggested > > > > > in an > > > > > >> earlier message we need to think about, to whom we should > provide > > > > > >> permission to use this functionality. Initially, I was thinking > > that > > > > > >> whoever has the permission to add tickets in the usual way > should > > be > > > > > able > > > > > >> to use this functionality. But I'm not really sure about that. > So > > > > there > > > > > I > > > > > >> need a little help from you to make it clear. > > > > > > > > > > > > > Yes, your suggestion seems sensible. > > > > > > > > Cheers, > > > > Joe > > > > > > > > >> > > > > > >> So what are your opinions on my suggestions. Obviously these > > designs > > > > > need > > > > > >> to improve a lot and for that the feedback from the community is > > > > really > > > > > >> important. > > > > > >> > > > > > >> Another thing is at the moment I'm trying to come up with some > > more > > > > > >> suggestions on expanding the functionality of this feature. So > if > > > you > > > > > have > > > > > >> anything in your mind please let me know :) > > > > > >> > > > > > >> Thanks > > > > > >> Dammina > > > > > >> > > > > > >> > > > > > >> On Tue, Mar 4, 2014 at 10:46 PM, Gary Martin < > > > > [email protected] > > > > > <mailto: > > > > > >> [email protected]>> wrote: > > > > > >> > > > > > >> Hi Dammina, > > > > > >> > > > > > >> Firstly I should point out that this project would > ultimately > > be > > > > > >> defined by you and so it is of particular importance that > you > > > make > > > > > >> this both challenging enough and realistic enough for you to > > > > > >> achieve in the available time. > > > > > >> > > > > > >> You have spotted a very interesting issue that you might > want > > to > > > > > >> solve as part of this project and if I were you I would > > > certainly > > > > > >> use this to strengthen your application. The ability for > users > > > to > > > > > >> specify details like ticket type, milestone, components and > > > other > > > > > >> fields certainly seems very desirable to me but there are > > going > > > to > > > > > >> be various solutions to the problem which will vary in > > > complexity > > > > > >> of implementation and actual usability. > > > > > >> > > > > > >> If you come up with some suggestions, we could discuss what > > the > > > > > >> community would prefer (and there is a good chance that we > > will > > > > > >> make more suggestions if we can) but remember to continue to > > > > > >> balance our advice with what you think is achievable. You > may > > of > > > > > >> course need our help to understand what may be easy or > > > difficult. > > > > > >> > > > > > >> Anyway, it is great to see that you are spotting issues that > > > might > > > > > >> be solved. > > > > > >> > > > > > >> Another area you might want to give a little consideration > to > > is > > > > > >> whether there might be anything you could take advantage of > > from > > > > > >> the context that the list is found in. In case you have not > > > noted, > > > > > >> wiki syntax is available in a number of places including > wiki > > > > > >> pages, ticket descriptions and comments. > > > > > >> > > > > > >> I hope that answered your question well enough! > > > > > >> > > > > > >> Cheers, > > > > > >> Gary > > > > > >> > > > > > >> > > > > > >> On 04/03/14 12:02, Dammina Sahabandu wrote: > > > > > >> > > > > > >> Hi Gary, > > > > > >> Another thing that I wanted to clarify is, by this > method > > we > > > > > >> will only be > > > > > >> able to add summaries for the created tickets. May be it > > > will > > > > > >> be possible > > > > > >> to fetch the reporter information too. But there are > many > > > more > > > > > >> important > > > > > >> fields in a ticket that should be filled such as type > and > > > > > >> priority. So do > > > > > >> we need to address this issue? > > > > > >> > > > > > >> Thanks, > > > > > >> Dammina > > > > > >> > > > > > >> > > > > > >> On Tue, Mar 4, 2014 at 4:03 PM, Gary Martin > > > > > >> <[email protected] <mailto: > > [email protected] > > > > > >> >>wrote: > > > > > >> > > > > > >> > > > > > >> On 04/03/14 04:32, Dammina Sahabandu wrote: > > > > > >> > > > > > >> Hi All, > > > > > >> > > > > > >> I'm Dammina Sahabandu, a 3rd year Computer > > > Engineering > > > > > >> Undergraduate at > > > > > >> University of Moratuwa, Sri Lanka. Currently I'm > > > doing > > > > > >> an internship at > > > > > >> WSO2 inc which is an open source middleware > > > > > >> organization. So I do have > > > > > >> experience in several Apache projects (Axis2, > > > Synapse > > > > > >> etc.). So as the > > > > > >> first step I did some background research about > > the > > > > > >> Apache Bloodhound > > > > > >> project. And also I did checkout the svn repo > and > > > > > >> installed > > > > > >> it successfully. > > > > > >> After going through the JIRA list I found > several > > > > > >> interesting ideas, but > > > > > >> I'm particularly interested in the idea of > > creating > > > > > >> tickets using a > > > > > >> wiki list [1]. So as I understood simply the > idea > > is > > > > > >> to provide a button > > > > > >> when there is a list in the wiki(numbered or > > bullet > > > > > >> pointed). And we need > > > > > >> to implement a system to create tickets using > the > > > list > > > > > >> after the user > > > > > >> clicking on that button. Then we need to update > > the > > > > > >> wiki page(the > > > > > >> > > > > > >> relevant > > > > > >> > > > > > >> list) replacing the list with the links to the > > > created > > > > > >> tickets. > > > > > >> Is that correct? Can you please give me a > feedback > > > to > > > > > >> clear up the idea. > > > > > >> And it would be really great if you can provide > > some > > > > > >> more details about > > > > > >> > > > > > >> the > > > > > >> > > > > > >> project. > > > > > >> > > > > > >> [1] > > > > > >> > > > > > https://issues.apache.org/jira/browse/COMDEV-110?filter= > > > > > >> 12326260 > > > > > >> > > > > > >> Thanks > > > > > >> Dammina > > > > > >> > > > > > >> Hi Dammina, > > > > > >> > > > > > >> Great to hear from you. For quick reference here, > the > > > > > >> associated ticket > > > > > >> for bloodhound is > > > > > >> https://issues.apache.org/bloodhound/ticket/231 > > > > > >> > > > > > >> I believe your interpretation of the ticket is > > > reasonable. > > > > > >> What has been > > > > > >> stated so far is probably not a full specification > for > > > the > > > > > >> problem so it > > > > > >> would be worth considering: > > > > > >> > > > > > >> * Permissions - who is appropriate for the button > to > > > be > > > > > >> presented to > > > > > >> and who can use the button? > > > > > >> * Intrusiveness - not all lists will need to be > > turned > > > > > >> into tickets so > > > > > >> could there be means to determine this? > > > > > >> > > > > > >> That is a shorter list than I thought I would come > out > > > > > >> with but feel > > > > > >> free to add to this, Dammina. As this would be your > > > > > >> project, it might be > > > > > >> better if you try to answer those questions rather > > than > > > > > >> getting us to > > > > > >> prescribe answers. This may be useful for > > strengthening > > > > > >> your final > > > > > >> project proposal too. > > > > > >> > > > > > >> Cheers, > > > > > >> Gary > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> Dammina Sahabandu. > > > > > >> Undergraduate Department of Computer Science and Engineering > > > > > >> University of Moratuwa > > > > > >> Sri Lanka. > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Dammina Sahabandu. > > > > > Undergraduate Department of Computer Science and Engineering > > > > > University of Moratuwa > > > > > Sri Lanka. > > > > > > > > > > > > > > > > > > > > > -- > > > > Joachim Dreimann | *User Experience Manager* > > > > > > > > WANdisco // *Non-Stop Data* > > > > > > > > e. [email protected] > > > > twitter @jdreimann <https://twitter.com/jdreimann> > > > > > > > > > > > > > > > > -- > > > Dammina Sahabandu. > > > Undergraduate Department of Computer Science and Engineering > > > University of Moratuwa > > > Sri Lanka. > > > > > > > > > > > -- > > Joachim Dreimann | *User Experience Manager* > > > > WANdisco // *Non-Stop Data* > > > > e. [email protected] > > twitter @jdreimann <https://twitter.com/jdreimann> > > > > > > -- > Dammina Sahabandu. > Undergraduate Department of Computer Science and Engineering > University of Moratuwa > Sri Lanka. > -- Joachim Dreimann | *User Experience Manager* WANdisco // *Non-Stop Data* e. [email protected] twitter @jdreimann <https://twitter.com/jdreimann>
