[Apache Bloodhound] Proposals/BEP-0011 modified

[Apache Bloodhound <de...@bloodhound.apache.org>]

Page "Proposals/BEP-0011" was changed by dammina
Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0011?action=diff&version=2>
Revision 2
Changes:
-------8<------8<------8<------8<------8<------8<------8<------8<--------
Index: Proposals/BEP-0011
=========================================================================
--- Proposals/BEP-0011 (version: 1)
+++ Proposals/BEP-0011 (version: 2)
@@ -1,91 +1,156 @@
 *Placeholder for Dammina's GSoC proposal*
-= BEP 0011 : <BEP title> #overview
+= BEP 0011 : Batch create tickets from wiki list #overview
 
 [[PageOutline]]
 
-|| '''BEP''' || <BEP number> ||
-|| '''Title''' || <BEP title> ||
-|| '''Version''' || <leave blank> ||
-|| '''Last-Modified''' || <leave blank> ||
-|| '''Author''' || Author With Email <us...@dom.ain>, Author Name Only, or The Bloodhound project (see [wiki:/Proposals#bep-header-preamble BEP preamble explained]) ||
+|| '''BEP''' || 11 ||
+|| '''Title''' || Batch create tickets from wiki list ||
+|| '''Version''' ||  ||
+|| '''Last-Modified''' ||  ||
+|| '''Author''' || Dammina Sahabandu <dm...@gmail.com> ||
 || '''Status''' || Draft ||
-|| '''Type''' || <BEP type (see [wiki:/Proposals#bep-types BEP types explained])> ||
+|| '''Type''' || Standards Track BEP ||
 || '''Content-Type''' || [wiki:PageTemplates/Proposals text/x-trac-wiki] ||
-|| '''Created''' || <leave blank> ||
-|| '''Post-History''' || <leave blank> ||
+|| '''Created''' ||  ||
+|| '''Post-History''' ||  ||
 
 ----
 
 == Abstract #abstract
 
-<Delete text in this section and add a short (~200 word) description of the technical issue being addressed. Take a look at sample abstract below>
-
-This template provides a boilerplate or sample template for creating your
-own BEPs.  In conjunction with the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines]  
-, this should make it easy for you to conform your own
-BEPs to the format outlined below. See [#howto How to Use This Template] for further instructions.
-
-**Note**: if you are reading this template via the web, you should first try to create a new wiki page by selecting `ProposalsRst` |page template guide|.  **DO NOT EDIT THIS WIKI PAGE IN ORDER TO CREATE A NEW BEP! **
-
-If you would prefer not to use WikiFormatting markup in your BEP, please see  [wiki:/Proposals/Formats/RestructuredText reStructuredText BEP guidelines].
-
-== Motivation ==
-
-<The motivation is critical for BEPs that want to change the copy of ''Trac'' patched using vendor branch . It should clearly explain why the existing ''Bloodhound'' solution is inadequate to address the problem that the ''BEP'' solves. ''BEP'' submissions without sufficient motivation may be rejected outright. >
+Currently Apache Bloodhound provides a method for creating tickets by filling a form with relevant information. But as it provides the functionality just for add one ticket a time, for a user who requires to create a large number of tickets could be really tedious process. So the major idea of this project is to implement a functionality which will make it possible for the users to batch-create tickets by converting !WikiFormatted tables into set of tickets.
+----
 
 == Proposal #proposal
 
-<The technical specification should describe any new features , detail its impact on the components architecture , mention what plugins will be included as a result , whether they are hosted by ​[http://trac-hacks.org trac-hacks.org] or not , and any other relevant technical subject . The specification should be detailed enough to allow competing, interoperable implementations for any of the current supported database platforms (e.g. ''SQLite'', ''Postgres'', ''MySQL'') and server technologies (e.g. ''Apache HTTPD server'', ''nginx'', ''mod_wsgi'', ''CGI'').. >
+Built on top of Trac Apache Bloodhound is a software development collaboration tool, including issue tracking, wiki and repository browsing (see:http://bloodhound.apache.org). Bloodhound extends Trac (http://trac.edgewall.org/) with multiple product support, advanced search functionality, ticket relations, a simpler installer and sleeker user interface. Apache Bloodhound recently graduated from the Apache Incubator as a stand-alone Apache project.
+
+Among other issue tracking systems Apache Bloodhound makes itself uniquely special by providing the best user experience. So though it is important to add new features to Apache Bloodhound we need to be very careful on preserving and improving the usability of the software. The target of the feature I'm proposing to be implemented, will not only add new functionality but also it will boost Apache Bloodhound into a new better user experience level.
+
+Apache Bloodhound already provides a method for the users to track issues by providing functionality of creating tickets. It is a dropdown form which contains the some of the relevant fields to be filled and saved in the backend database. Somehow if the user requires to fill one or more of the other fields that doesn't display in the dropdown he will be redirected into a new page which contains the complete form of relevant fields. If the user just wants add one ticket at a time this method will work fine. But if the user wants to a large number of tickets he has to go over and over again through this process which will be really  exhausting experience for the user. As I mentioned earlier one of the major power of Apache Bloodhound is it's great user experience. So it is really necessary to provide a separate method which will make this process easier for the users.
+
+So the proposed idea is to provide functionality for the users to batch-create tickets by just converting an existing wiki table into tickets. This engages three major steps.
+
+1. User add a ticket table into the wiki.
+1. User fills the ticket table.
+1. User clicks on save button to display the created tickets.
+
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Batch-cretetickets.png?t=1395118296)]]
+
+'''''Use case diagram'''''
+----
+
+First the users will be able to create a 'ticket table' with a simple macro. 
+
+----
+Format of the macro will be:
+{{{
+[[TicketTable(numberOfTickets)]]
+}}}
+(Figure 01)
+----
+
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_026.png?t=1395118317)]]
+
+'''''Figure 01'''''
+----
+
+As it conveys the macro takes an user argument "number of tickets" that the user is going to add to the ticket table. Then the macro will be able to render a table with required fields as column headers and "numberOfTickets" number of empty rows to be filled by users.(Figure 02) 
+
+Then the user will be required to fill the ticket table with appropriate issue data.(Figure 03)
+
+After filling the table the users will be able to click on the save button which will be positioned under the ticket table and batch-create tickets. After that the wiki page will be modified, that is the table will be modified into a normal ticket query table where the ticket id and ticket summary will be links redirecting to appropriate tickets that have been created.(Figure 04)
+----
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_030.png?t=1395118322)]]
+
+'''''Figure 02'''''
+----
+----
+
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_033.png?t=1395118334)]]
+
+'''''Figure 03'''''
+----
+----
+
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_034.png?t=1395118333)]]
+
+'''''Figure 04'''''
+----
+----
+
+When retrieving the tickets it is required to identify the tickets that have been created. For that the idea is to retrieve based on the creation time. For that it will be require to extend the !TicketQuery macro to handle absolute time stamp values.
+
+----
+{{{
+[[Widget(TicketQuery, query="created=2007-01-01 00:00:00..2008-01-01 23:59:59", max=10, title=Batch Created Tickets)]]
+}}}
+----
+
+And obviously in an organization where they use Apache Bloodhound as there issue tracking tool they will be a need to control the use of this functionality. That is this functionality should not be given to each and every user in the organization. Because miss using this functionality will lead into a huge mess as it is capable of creating huge numbers of tickets by a single click of the user. So the idea is to create a new permission level for using this functionality. Admins of the organization will be the only ones who will granted with this permission level 'TICKET_BATCH_CREATE' by default, and they will be able to grant it to other users as they wish.
+
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Permission.png?t=1395118300)]]
+----
+----
+
+However the best thing about this feature is ,as this uses simple macros which can be used within wiki syntax, the users will be able to use this anywhere  where it supports wikiFormating. So hopefully this will be a real nice feature which will increase the usability of Apache Bloodhound significantly.
+
 
 == Rationale #rationale
-
+[This section will be completed soon!]
+{{{#!comment
 <The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other issue trackers or ''Trac'' hacks . The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. Take a look at sample rationale below>
 
 ''BEP'' submissions come in a wide variety of forms, not all adhering to the format guidelines set forth below. Use this template, in conjunction with the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines], to ensure that your ''BEP'' submission is easy to read and understand.
 
 This template allows to create BEPs and is very similar to [http://www.python.org/dev/peps/pep-0012 PEP 12] . However it has been optimized by moving long explanations to the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] . If you are interested take a look at the  [?action=diff&old_version=1 differences]. The goal is to redact new BEPs just by following in-line instructions between angle brackets (i.e. **<** **>**) . Even if this will allow to write BEPs faster , it is highly recommended to read the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] at least once in your lifetime to be aware of good practices and expected style rules . 
+}}}
+----
+----
+----
+----
+----
+== Time Line
 
-== How to Use This Template #howto
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_024.png?t=1395118304)]]
+----
+----
 
-<BEPs may include further sections. This is an example.>
+[[Image(http://i1173.photobucket.com/albums/r600/dammina/Selection_025.png?t=1395118308)]]
+----
+----
+== About Me
 
-Quick edits will consist in following the instructions inside angle brackets (i.e. **<** **>**) . That should be everything needed to write new BEPs. To be more informed about advanced considerations please read the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] . If there is no point in including one of the sections in this document then feel free to remove it.
+I’m Dammina Sahabandu a third year undergraduate at University of Moratuwa (Department of Computer Science and Engineering) which has had the most Google Summer of Code students for an impressive 7 years in a row. And currently I’m doing my internship at WSO2 which is completely open source middleware organization who has a really close relationship with Apache Software Foundation ![2]. In WSO2 I’m working in the ESB(Enterprise Service Bus) team which is built upon Apache Synapse and Apache Axis 2. So I have a great experience on working with open source community and have a good idea about their standards. And working with large code bases is my everyday work.
+Also, all the technologies related to this project are very much familiar to me. So I feel really confident and looking forward to completing this project successfully.
 
-== Backwards Compatibility #backwards-compatibility
+[My internship period is from 11-11-2013 to 11-04-2014. From that day onwards I'll be having a vacation and will be able to work full time on this project.]
 
-<All BEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ''BEP'' must explain how to deal with these incompatibilities. ''BEP'' submissions without a sufficient backwards compatibility treatise may be rejected outright. >
+![1] http://google-opensource.blogspot.com/2013/07/google-summer-of-code-full-of-stats.html
 
-== Reference Implementation #reference-implementation
+![2] http://wso2.com/
+----
 
-< The reference implementation **must** be completed before any ''BEP'' is given status **Final**, but it need not be completed before the ''BEP'' is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation **must** include test code and documentation appropriate for either the wiki pages in ''Bloodhound'' users guide or an specific wiki page in the [http://issues.apache.org/bloodhound issue tracker] . >
+=== Contact Information
 
-<In order to list tickets related to a given proposal edit sample text provided below by including the appropriate **<BEP number>**. Target tickets have to be tagged with `bep-<BEP number>` keyword. Do not forget to remove curly braces so that the tickets list will be actually rendered.>
+E-mail : dmsahabandu@gmail.com
 
-{{{
-[[Widget(TicketQuery, query="keywords=~bep-<BEP number>&col=id&col=summary&col=status&col=priority&col=milestone", title=BEP <BEP number> ticket summary)]]
-}}}
+IRC : topiya
+
+Blogger : http://dweebslair.blogspot.com/
+
+!LinkedIn : http://lk.linkedin.com/pub/dammina-sahabandu/32/300/43b
+----
 
 == Resources #resources
 
-<Provide links to useful resources related to the subject discussed. See sample text below>
-
-See WikiFormatting for more help on the markup used to write wiki pages.
-
-== References #references
-
-<List the references included in BEP body>
-
-  1. PEP 1, PEP Purpose and Guidelines, Warsaw, Hylton
-     http://www.python.org/dev/peps/pep-0001/
-  2. PEP 9, Sample Plaintext PEP Template, Warsaw
-     http://www.python.org/dev/peps/pep-0009
-  2. PEP 12, Sample reStructuredText ''PEP'' Template, Goodger, Warsaw
-     http://www.python.org/dev/peps/pep-0012/
-  3. http://www.opencontent.org/openpub/
+1. Apache Bloodhound Widgets: https://issues.apache.org/bloodhound/wiki/BloodhoundWidgets
+1. Wiki Macros: https://issues.apache.org/bloodhound/wiki/WikiMacros
+1. Permissions: https://issues.apache.org/bloodhound/wiki/TracPermissions
+1. Ticket Queries: https://issues.apache.org/bloodhound/wiki/TracQuery
+----
 
 == Copyright #copyright
-
-<In this section all licensing issues should be meticulously exposed . Library and plugin dependencies are among the most important topics . On the other hand each BEP will be explicitly labelled with a copyright statement like shown below, so should not change that. Requests for a different copyright statement have to be posted to bloodhound-dev@incubator.apache.org . For more details consult [wiki:/Proposals#what-belongs-in-a-successful-bep BEP structure explained] .>
 
 Copyright © 2009-2012 The [http://www.apache.org Apache Software Foundation] [[BR]] 
 Licensed under the [http://www.apache.org/licenses/LICENSE-2.0 Apache License, Version 2.0].
-------8<------8<------8<------8<------8<------8<------8<------8<--------

--
Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0011>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound issue tracker

This is an automated message. Someone added your email address to be
notified of changes on 'Proposals/BEP-0011' page.
If it was not you, please report to .