Bugzilla – Full Text Bug Listing
| Summary: | provide custom fields in query form | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Andrey Larionov <anlarionov> | ||||||||||||||
| Component: | Mylyn | Assignee: | Project Inbox <mylyn-triaged> | ||||||||||||||
| Status: | CLOSED MOVED | QA Contact: | |||||||||||||||
| Severity: | enhancement | ||||||||||||||||
| Priority: | P3 | CC: | bloodycelt, daniel.weber.dev, eclipse.dserodio, gaionim, j.o.h.n.stephi, jim.kass, jtk499 | ||||||||||||||
| Version: | 3.6 | Keywords: | helpwanted | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | All | ||||||||||||||||
| OS: | All | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Andrey Larionov
Yes, that needs to be added to the query dialog. Do you have ideas how to integrate that with the current user interface? I think first of all Mylar Trac.core ticketAttribute class must comply Trac's model. Now in XML-RPC getTicketFields returning: type, lable, order, and depending on type other properties of field (like possible values). I think this properties is enough for dynamic building of query page. After Friday i took mylar sources to home and start working on this patch. I'm very new to Eclipse and SWT but i think i could make a core functionality. Please note that I have added a class TracTicketField that contains meta information about a field. ITracClient.getTicketFields() returns a list of all fields and could be used to construct the query page. It is in the CVS head. I checked out e_3_2 branch. Because i have Eclipse 3.2. As i Know Head need Eclipse 3.3 Is this changes incompatible with 3.2 branch? The change is not incompatible but it may take a long time for it to appear in the 3.2 branch. The branch is only sporadically updated to create dev builds for 3.2. All development takes place in CVS head and requires the latest 3.3 milestone (currently it even requires an Eclipse integration build). If you want to contribute patches I would strongly recommend that you use CVS head, otherwise you won't see the latest changes and merging of patches will difficult due to potential conflicts. I almost finish implementation but there are some difficulties for me in SWT programming. 1. Custom fields can be several type : checkbox (label), selectbox (with label above), text box (with label and filter selector), textarea, and radio (in group) 2. They are can be ordered in special way 3. All controls grabs different cells in grid layout. Please recomend me good solution for this case. Now i group all fields and draw they by type (first text, second select, third radio) Andrey: your approach of manually arranging by type is fine since we don't yet have anything sophisticated for arranging these kinds of attributes and leave it up to the connector. After you provide the patch Steffen can comment or iterate on the layout. Yes, go ahead and attach the patch and the Mylar context, so we can iterate on the layout. We may need to put the custom attribute filter in a expandable section to avoid cluttering the UI. Ok, I provide patch ASAP. But now i have no free time to polish and complete it, but i hope what i can make it in 2 weeks. Any news on this? There are little cleanup in code, but i cant finish it because after update my Bootstrap workspace. Today i'll try to recreate my workspace and finish work (if it'll work) in two-three day. Yesterday i restore my Mylyn workspace and IDE and continue to creating patch. Today i'll upload context and basic patch. I have some issues on it. 1. In common fields (milestones, components, etc) first draws UI components and then filling values int it. But for custom fields it's wrong because initial TracClientData fills in updateRepositoryAttributes. I remove some code in separate function. 2. I realize next types of ticket fields: SELECT, CHECKBOX, TEXT. There are left RADIO and TEXTAREA. I think this will no so hard to do in two or three days 3. In my realization of CHECKBOX, when generating query if CHECKBOX checked all fine, but if it not checked... What it mean? On Trac Custom Query form i can add filter by any field. But on our form filter always present and can be only in 2 states. But no states to not include in query filter. Maybe do like in trac custom query dynamic filter addition? 4. Resulting wizard page is too small. There is need scroll bars. I'll try to add it. (In reply to comment #12) > Yesterday i restore my Mylyn workspace and IDE and continue to creating patch. > Today i'll upload context and basic patch. Great! This will be a useful addition for the Trac connector. > 1. In common fields (milestones, components, etc) first draws UI components and > then filling values int it. But for custom fields it's wrong because initial > TracClientData fills in updateRepositoryAttributes. I remove some code in > separate function. Can the components for the custom fields be added after the task data has been retrieved? > 3. In my realization of CHECKBOX, when generating query if CHECKBOX checked all > fine, but if it not checked... What it mean? On Trac Custom Query form i can add > filter by any field. But on our form filter always present and can be only in 2 > states. But no states to not include in query filter. I guess this will require an additional check box that determines if the criteria is to be included in the query. > Maybe do like in trac custom query dynamic filter addition? That is also a possibility. I'll attach the original implementation of the query page that took that approach, resembling the web interface. > 4. Resulting wizard page is too small. There is need scroll bars. I'll try to > add it. Sounds good. Created attachment 72115 [details]
TracWebQueryPage
Please note that this implementation is almost a year old (from Mylar 0.6.0) and will not compile with the current source. It can give you an idea how to dynamically create the search page if you decide to implement it that way.
(In reply to comment #13) > > Can the components for the custom fields be added after the task data has been > retrieved? After i upload patch you can see in what maner i realise it. > > 3. In my realization of CHECKBOX, when generating query if CHECKBOX checked all > > fine, but if it not checked... What it mean? On Trac Custom Query form i can add > > filter by any field. But on our form filter always present and can be only in 2 > > states. But no states to not include in query filter. > > I guess this will require an additional check box that determines if the > criteria is to be included in the query. Result form will be very overload by controls. > > Maybe do like in trac custom query dynamic filter addition? > > That is also a possibility. I'll attach the original implementation of the > query page that took that approach, resembling the web interface. Thanks. i think this is the best choice in terms of usability. Created attachment 72142 [details]
mylyn/context/zip
Created attachment 72143 [details]
Basic implementation without Radio Buttons and Text Area
For review. Needs suggestions on layout.
Thanks Andrey. Please excuse the slow feedback. We are currently very busy the upcoming 2.0 release. I'll take a look at the patch next week so we can iterate on any outstanding layout issues. I already made new patch, with Trac like filter addition. I submit it on Friday or monday. I'll try to make it more polish and logicaly clean. Now i in deep debuging. Created attachment 72866 [details]
Implementation of query page like in Trac web interface
Need review
Created attachment 72867 [details]
mylyn/context/zip
Last patch is implements query page in the Trac custom Query dialog. But there is some problems 1. Update attributes id called twice 2. Need review and clean up. More clear code for work with add filter combo and scrollContainer 2. Need to arrange and rearrange after change in filter selection combo 3. Not tested radio buttons but must work 4. No tests 5. When repository is unavaliable creating query have no valid exception handling Thanks Andrey. I am having trouble applying your patch, could you please recreate it against the latest CVS? If you are working on Eclipse 3.2 it would be great if you could upgrade to Eclipse 3.3 since the code in the 3.2 branch has diverted too much for patches to apply cleanly on head. If that's not possible, let me know and I'll try to resolve the conflict manually. Also please make sure "Workspace" is selected as the patch root when creating the patch. It makes it easier to apply the patch. I create this patch againts 1.33 revision. With "Project" root. I have a problem. After importing Team Project Set all ok, but when select all projects and choose in context menu Team->Update, all finished bad. Very often resources is out of sync. I do refresh and after new update its look like the code in the head is buggy. Very many errors. If you want i can attach whole file TracCustomQueryPage.java Created attachment 73057 [details]
patch against head
I think for testing we need Trac server more coplex configured, then we have now. Is this patch was useful? What wrong with it? What need to be done on this bug? Sorry for the slow response. We have been busy preparing the 2.1 release with the goal not make any big UI changes. I would like to make more progress on this for the next release. My major concerns with the patch is that the current query wizard is straight forward to use and sufficient for most use-cases therefore I would like to keep it as is. Instead of replacing it I would prefer it if we could come up with a way of specifing the additional query properties in some type of advanced UI. I can think of two ways to do this: - add an advanced section to the wizard that is folded by default (similar to the repository properties) that uses the UI from the patch to flexibly specify additional properties - have two different query dialogs, basic and advanced, and provide UI to switch between them Hello, Steffen. Your arguments is strong. And i think you are right. But only from GUI position. This implementation against trac looks like against Bugzilla. But trac more flexible. If i dont need "component" i remove it. And your connector dosent work. Bugzilla is big stable monster, but trac small flexible and customizable. Do you hear about scarab. In Scarab no fixed fields ALL maybe removed and Any created. How do you realize this Page for Scarab? (In reply to comment #29) Maybe Soon trac became i10n. This mean what all fields get translation. But your connector stay English because hardcoded. This is another minus. (In reply to comment #30) > If i dont need "component" i remove it. And your > connector dosent work. The component list will be empty but that should not cause any problems. Please file a bug report if that doesn't work. Having the empty list is a compromise but that way the query UI look the same for each repository making it easy to use. > Do you hear about scarab. In Scarab no fixed fields ALL maybe removed and Any > created. How do you realize this Page for Scarab? I agree that the approach taken for Trac would not work in that case. Still for Trac the current UI is simplest I could come up with that satisfies most use cases but there is always room for improvement. As I said I would like to add more advanced querying if we can integrate it with the existing UI. (In reply to comment #31) > Maybe Soon trac became i10n. This mean what all fields get translation. But your > connector stay English because hardcoded. This is another minus. Trac queries the fields from the repository so localization should not be an issue. I just want to say, what Trac provides API for requesting fields and metadata. Why not to use this info instead of Hardcoding. In which UI we use it no mater. Important to provide for users real (true) image of they Trac's. If in customized trac no Milestone, component, version, priority, severity we display for user just empty form. *** Bug 252949 has been marked as a duplicate of this bug. *** (In reply to comment #34) > Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items Any plans when this could be implemented? (In reply to comment #29) > [...] Instead of replacing it I would prefer it if we could come up with a > way of specifing the additional query properties in some type of advanced UI. I > can think of two ways to do this: > > - add an advanced section to the wizard that is folded by default (similar to > the repository properties) that uses the UI from the patch to flexibly specify > additional properties > - have two different query dialogs, basic and advanced, and provide UI to > switch between them > I'd opt for the advanced section. It leaves the dialog simple by default, but at the same time provides access to advanced features for those who need them. We just changed our ticket handling to rely on a custom field and as I wanted to adapt my Mylyn queries, I found that it can't handle them :( Any plans? (In reply to comment #34) > Need to defer: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items I think we still need to address this. I imagine a lot of us are using Trac, and things like custom fields, or even just support for "severity" are pretty important when creating a sort order. Perhaps we could actually just use XML-RPC to return results back from Trac's own reporting engine, so we could take advantage of existing reports we've build? Would also like to see this. How does your connector work with trac? Some ideas: 1. Allow for using a Trac Report. This would keep the interface simple and defer the custom fields to trac and creation of the report. 2. If feasable and easy allow a text field where you can either type in the custom query url directly or enter the raw sql query. Either way you don't have to have a clunky UI generator. *** Bug 393103 has been marked as a duplicate of this bug. *** Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |