joomla / jissues Goto Github PK

When you set the item limiter to say, 5 or 10. And then click "page 2" from the pagination, the issues table resets and loads all the items instead of navigation to page 2. This might be a router issue or something else.

The admin interface should, at a minimum, contain:

• Tracker management area (admin com_tracker), to include a way to manage issues (add/edit/delete/move/whatever the case may be) and manage data for the various entry fields
• User management area (something to manage ACL)
• Reporting area

Whenever I look at the current tracker, one of the first things I wish to know is who last looked at it/made a change.
Instead of just a date could we have something like:

Last Modified 2013-01-01
by Jayflux

You would then be able to see who looked/modified the issue without having to even open it up

Since the GitHub markdown parser is now in master, we need to look into preventing its abuse as discussed in #60.

Right now, the additional fields aren't being processed when adding new issues. In trying to work on it, I'm finding that no matter how I tweak the code, I can't get those fields (everything but Build and Easy, which aren't even being recorded ATM) to push to the $_POST superglobal.

This notices only seem to be thrown during the first import of issues (jos_issues has no data)

Undefined variable: data in /cli/retrieveissues.php on line 194
Trying to get property of non-object in /cli/retrieveissues.php on line 194
Undefined variable: currentAssetId in /libraries/joomla/table/table.php on line 778

It would be cool if we add a markdown parser for parsing the issue description as well as for the comments.

If have a content plugin that supports also fenced code highlighting and other stuff ready to pull in.

I think this would also make it possible to add those "spice links" to reference issues etc. with a simple "shortcut"
See: http://github.github.com/github-flavored-markdown/

ACL system, should at a minimum incorporate:

• Guest access (at most, the ability to submit reports and comments in a moderated fashion, otherwise read-only)
• Registered user (is able to submit reports and comments, able to update status on own items, edit summary/description on own items, upload files to own items (screenshot, patch, etc.))
• JBS (Registered user + able to manage non-owned items)

I've gotten the first webhook written to listen for issues opening and closing. This should update the tracker instance I've posted to http://tracker.babdev.com. This needs to be cleaned up some so that it will only accept input from GitHub (they have a list in the docs) as well as handle all updates to issues. As we add additional data to the schema, that should be injected as well. I'll be doing a separate hook for issue comments, and any others as needed.

I have examples of the data payload online as well. http://tracker.babdev.com/hooks/githubdata.new.txt is the payload for issues opening and closing. http://tracker.babdev.com/hooks/githubdata.comment.txt is the payload for comments.

I'll commit the hook momentarily. Assuming I've got it working now, once I submit this issue, it should trigger the hook and add this issue to the "live" instance.

One of the things I really miss on the jcode tracker is the ability to mark an issue as duplicate and include a link to the original issue without scrolling down the comments..

So I thought we can implement a simple 1:1 relation management. Example:

• Let's say #3 is a duplicate of #2

Edit #3 select "duplicate" and fill in the id of the original issue:

The "issue view" now indicates that #3 is a duplicate of #2:

While the item view of #2 indicates, that it has duplicated items #1 and #3 (while #1 is already closed)

I also added the relation types "related to" and "not before".

Open for comments.

We need to figure out which administrator extensions are "essentials" to managing this beast. At present, we have the ability to use modules and plugins without an interface to manage those. And we don't have a mechanism to install extensions (though, I don't see us having a major need to do that). So, we're probably going to want the Module and Plugin Managers.

Before merging the Module Manager though, it's going to need to be reviewed and stripped down. If it can be avoided, I'd really like to NOT use the Joomla menu system, which it depends on to handle module assignments. This one will need to be thought through if we do get to a point where we have to have modules on selected pages only.

I think we're far enough to code our mailing solution in now.

Basically, we need e-mail notifications for activity. Should be opt-in/out kinda like Joomlacode allows now, just a little more friendly than a link buried in the sub-nav, and customizable. Does the user want to see all updates on an issue (status changes, comments, etc.), only certain events, or none at all. Allow the user to subscribe to issues at will, as well as unsubscribe.

Not quite sure how to handle tracking preferences at the moment, but that can be worked on.

I think it would make sense to have a single view for single items that serves viewing and editing, depending on the users permissions.
Just like in joomlacode ;)

Thanks for everyone's work on this! :)

It would be awesome to include gamification aspects to it to make it more fun and interactive. For example, there could be:

1. a leaderboard (all-time, yearly, monthly, etc)
2. individual statistics (e.g. total number of issues I've tested, worked on, etc)
3. badges
4. point system where you get x number of points for completing tasks, and maybe where you can even trade in those points for Joomla merchandise (e.g. a Joomla t-shirt) or other prizes (e.g. a free JWC ticket). Points could also be exchanged. For example, if someone tests your patch very throughly, you could give that person bonus points, which transfer over from your points.

(1) and (2) are probably things that we should be doing anyway. (1) would be difficult to implement. (3) if someone is interested in implementing something, I can find a designer to do art work.

I can't log into admin on the live site or local. I see no code changes in the legacy Application or the Session packages that would cause this to happen. So, any ideas?

When logged in as a Super User, new issues added from the front end fails. The page refreshes with the URL containing all data to be submitted, and returns to the issue list, but the issue is not added.

Testing user registration on the live instance, getting the following error message in the error log: Undefined index: action in /plugins/user/joomla/joomla.php on line 149

End state for the user is they're redirected to the login screen with their login data still in the form with no messages of any kind.

Develop a login mechanism that allows users to log into the application with their GitHub account. Refer to http://developer.github.com/v3/oauth/ for API information Potential rough sketch of workflow:

• User authorizes GitHub account to share data with application (will most likely need someone in the joomla organization to create an application to allow this)
• If first time login, a record is created to the application's database table (this part will probably require someone to port com_users to the new infrastructure, this is important to have for ACL purposes)
• Login is processed through Platform to authenticate ACL and load user settings
• User is logged in

One thing that must be replicated here is the ability for registered users to upload files (screenshots, patch files, etc.) to items they have permissions on. Joomlacode makes it pretty much impossible to remove files after the fact, but we should be able to do this.

Basic requirements:

• Folks be able to upload patch files generated locally (GitHub is 1000% preferred, but some just aren't with the times)
• Folks be able to upload supporting files (images, documents, etc.)
• Selected file types aren't allowed (i.e. no PHP files, like Joomlacode)
• With permission, users are able to delete files

As noted below, I think we agree on blueimp for the frontend. Do we want/need anything for the backend?

We should add a field to configure the base URL for a project's issues on GitHub to com_categories. Using my live example which has the issues here feeding to it, the issues are linked to joomla/joomla-cms instead of here.

One of the reasons I'm mildly adiment about building our own app is the ease of translating it, and I feel we would open the door for more international contributions if we can translate the interface for them. The instructions would need to include a blurb about English being the primary language and issues should be submitted in such if possible, Google Translate can only go so far. That said, in places where we are rendering hard coded language, we should do our best to use language strings so data can be translated.

Also, we would need to ensure we have the mechanisms in place to set the proper language for users. Should be able to get this code from the CMS application classes if it isn't already included.

I was wondering what file header to use for new files.
Should it contain the © of the original author ?
When I modify some files, should I add myself with an @author tag or something ?

Or..

Could we just stick to the OSM header ?

/**
 * @package     JTracker
 * @subpackage  ?
 *
 * @copyright   Copyright (C) 2012 - 2012 Open Source Matters, Inc. All rights reserved.
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */

It's never too late (or too early) for this kind of ugly discussions ;)

Hi,

I am a programmer and i'd like to help the Bug Squad Coding Team
I saw on this page you need people: http://forum.joomla.org/viewtopic.php?f=681&t=783593

Niels

Issues are inserted in the database without project_id value.

We probably need to A) update the CLI to inject a project ID and B) update the SQL dump.

I am playing around with an idea for an CMS extension autoloader.
The goal is to create a single function capable of loading the classes for every extension for both the admin and site application.

Since we are at a very early stage with our project, and have only two components so far in our "site" application, maybe we can implement it and see how it works.

The required changes would be to register the common autoloader instead of the specific autoloader for com_tracker, change the lookup for the view- and model classes inside the tracker default controller (or even better, create a common default controller) and - to prefix all the classes with a Com.

The "magic" function can be seen here: https://gist.github.com/3936393

The logic to name the classes would be:

• ComFooModelBar to load
  • JROOT/components/com_foo/model/bar.php
• ComAdminFooModelBar to load
  • JROOT/administrator/components/com_foo/model/bar.php

Same for modules, plugins and templates.

Thoughts ¿

With the current installation process, creating a back-end administrator requires registering a user from the front-end and then escalating that user to belong to group_id = 8 in #__user_usergroup_map directly in the database. While not a big deal, it might be nice to add a generic admin account during install. Or, would that be creating a potential security issue by having known default admin information?

Since this project isn't pushing stable releases, I think we're safe to make an effort to keep in sync with current versions of the CMS Libraries and Platform versus waiting for a tagged release. So, every couple of weeks, merge in the latest and greatest. The commit message should indicate what commit the external libraries are merged from as well.

I'd image that some of the fields when adding a new Issue are required. We'll need (ajax?) validation of these fields.

So I'm just making sure the issue hook still is. Only difference is the events triggered.

So, the ugly beast in the room is how to handle routing. Right now, things work just fine with the ugly default URL system. The question is what do we want to do, and what system do we use to do it. If we want SE&HF (Search Engine & Human Friendly) URLs, we're going to have to create a routing instance. We can either use JRouter or try out JApplicationWebRouter (which, TBH, I don't quite understand, but it's in the version of the Platform Pull Tester Louis was working on at https://github.com/LouisLandry/tester).

Ideas are welcome. As well as router system experts.

PHP Fatal error: Call to undefined method JException::isSite() in /libraries/cms/menu/site.php on line 90

Since we're using ACL to test conditions in actions and toolbar buttons, I think it's time to build a proper usergroup structure versus the default one for the CMS. This should probably mimic the current structure (this is discussable), which I think is something like this:

Groups without backend access:

• Registered to Joomlacode: allowed to submit reports, allowed to comment on all items, allowed to upload files to self submitted items, allowed to edit data on self submitted items
• Registered to Joomlacode and added to Bug Squad group: allowed to submit reports, allowed to comment on all items, allowed to upload files on all items, allowed to edit data on all items

Groups with backend access (Bug Squad leadership, PLT, whomever else they decide to give access to)

• Something like a view-only access (can see issues, can see reporting data if/when that gets built)
• Next level up allows someone to manage the issues via backend, and this is where delete and move functionality is present
• Next level up allows above plus ability to manage the fields structure (com_categories basically)
• Ability to manage com_users somewhere in here
• Highest level is super admin (Mark & JM type folks)

Once that repo stabilizes, I'd be interested in moving to use the new Framework code in place of the current Platform. Since this is the part of the code that should be 100% decoupled from the CMS, this should be the best to build an application from. From there, we retain dependencies we require (i.e. JHtml) and go forth to do great things. Thoughts?

Since the GitHub markdown parser is now in master, it would be nice to find a way to highlight code eventually contained in issue descriptions and comments as discussed in #60.

I made the change from #44 and checked if I get an entry in the asset table and there aren't entries for the new issues. I think that is a bug, can some check if it is just me ;-)

Cheers,
Robert

Title: PLG_USER_JOOMLA_NEW_USER_EMAIL_SUBJECT
Body: PLG_USER_JOOMLA_NEW_USER_EMAIL_BODY

Nada mas.

Testing a receive hook. Sorry for the spam your e-mail may receive.

Thoughts on how we track issues in the development of JTracker/jissues.

1. It would be useful to have a convention for non-collaborators to suggest a tag. I'll suggest a [...] prefix to the issue title. This could then be migrated to a real tag by collaborators.
2. Additional tag suggestion. I think it would be useful to separate the must haves from the would likes. e.g. [REQUIREMENTS] [ENHANCEMENTS]

Currently the event types is a VARCHAR field. It appears we have comment / open / close as data that is tracked by this activities table. Will there be other event types that are available. When looking at reporting etc, it's nice to know all possible activities we're tracking.

When editing a category in the back-end, the following top-level menus are visible:

System
Users
Menus
Content
Components
Extensions
Help

The repo was seeded with the Platform pure at joomla/joomla-platform@f1dfc46. Since we're going with the Bootstrap markup, we'll need to merge in the CMS edits to the various classes to get that styling.

First of all: Congrats for starting this baby.

OK, so here comes the first issue. I would like to point this out es early as possible because I feel it's quite important.

One of the things a tracker needs very badly is the ability of sorting and filtering - extensive..

Example: I need to filter the issues of a given priority and a given status and whatever.

I don't think the approach with a single select for filtering will work here (nor in the CMS..)

So i believe in the Magento approach - which is putting the filter fields inside the headers of the table columns. Works pretty well for extensive filtering in extensive tables..

Now let me repeat my congrats, installation and retrieval of the issues from github worked good after figuring out how to set it up ;) I am forking this thingy right now and hope to contribute some code in the future.

hF,
Nikolai

The tracking system will need sufficient data to be able to filter items at each stage (and sub-stage) in the workflow.

NOTE: This issue isn't to add filters, it's to add the information required for filtering.

Whilst the status is sufficient for most stages, some additional information is required for some stages for further filtering to assist efficiency. To allow these to be implemented, additional information needs to be captured somewhere (Example: the number of successful tests). Some existing status values might be better captured in extra informational fields rather than a status change. Some existing status values are overloaded (Example: Pending). I've added some additional transitions for consideration and some possible alternative names (Example: Testing / Pending)

Workflow transitions:
New -> Open -> Confirmed -> Development / In Progress -> Ready to test -> Testing / Pending (Needs two) -> Pending (Needs one) -> Pending (Needs none) -> Ready to commit -> Closed (Fixed)
Open -> Open (Further Information Required)
Open -> Open (Needs Review)
Open -> Closed (Unable to confirm)
Open -> Closed (Known issue)
Open -> Closed (Duplicate)
Open -> Closed (Not Joomla Core)
Pending -> Pending (Needs Review)
Pending -> Needs Rework / Development (Needs rework)
Pending -> Needs Re-patching (eg. rebasing)
Pending -> Pending (Submitted to platform)
Pending -> Waiting on platform

Comments on status values:
New - Possible new status. This is the initial status and transitions to open once reviewed. Adds the ability for an initial traige for potential fast-tracking.
Development - Possible new status, replacing or in addition to in progress. When an issue needs to be returned to development, it would be returned here, rather than to confirmed.

Possible additional fields:
Required Versions (2.5, 3.0) - multi-select
Committed Version (2.5, 3.0) - multi-select
Successful Tests (1,2)
Closed Reason (Fixed, Unable to confirm, Known issue, Duplicate, Not joomla code)

The JoomlaCode tracker contains the following canned queries to assist the workflow. I don't have visibility of the query rules, but as best as I can tell here's a start.

• All Open (no closed date)
• Tracker Team (status = open, information required)
• Active Artifacts (?)
• Release Blockers (?)
• Open 3
• Needs two tests (Pending, Not Tested)
• Needs one test (Pending, Tested once)
• Needs no tests (Pending, Tested twice)
• Submitted by (Ordered by submitted by field)
• Closed during bug squash (Closed, Range of dates, Updated for each bug squash)

Further information on existing workflow can be found at :

• http://docs.joomla.org/Bug_Tracking_Process

The tooltip for <i class="icon-unpublish"></i> of an un-activated user reads "Activate javascript:void(0);"

As noted at https://github.com/JTracker/jissues/blob/master/libraries/tracker/application/hooks.php#L103, we're pulling in the payload for the web hook scripts directly from the $_POST superglobal. Though we can assume that data received from GitHub would be properly cleaned, there's still the chance someone could IP spoof and attempt to do terrible things to the tracker instance. So, we should get the data via JInput.

When I first implemented the hooks, I tried and tried, but couldn't make it work. Anyone who's looking to work on this can find a sample payload at https://help.github.com/articles/post-receive-hooks which can be used to test the hook.

Sorry!

Considerations for a lecacy tracker id.

• reference legacy tracker id (i.e. JoomlaCode Tracker ID)
• link legacy tracker id
• Include legacy tracker id in grid. This would be needed in the grid during a transition period.
• Include in filters. Or some other way of jumping directly to a specified id.

If I install the master branch then I see the following picture:

There is no content.

Database and sample data were successfully installed. There is unfortunately nothing appears.

I've looked but I can not found the error. :(