Hi Joe, Hi Gary, Here is my idea. First of all we should implement a macro to create ticket tables. That is, the macro should take "number of tickets that the user is planning to create" as a parameter and return an empty table with essential field headers for the column names. (And that macro should only be used by the users who has granted with the TICKET_BATCH_CREATE permission.) Then they will be able to fill the table and click on "save" in order to create tickets. After that we need to load the wiki with ticket query table. That is we should implement a TicketQuery that will retrieve those tickets that have been added, from the database. Am I missing anything?
Thanks Dammina On Tue, Mar 11, 2014 at 9:25 PM, Joachim Dreimann < [email protected]> wrote: > 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> > -- Dammina Sahabandu. Undergraduate Department of Computer Science and Engineering University of Moratuwa Sri Lanka.
