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? 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.
