Best practice forum (Archived)

Some more visibility for Totara bug tracker?

Hi,

Just wondering for enterprise subscribers, whether we could get some sort of visibility to the Totara bug tracker?

For example, we are in the process to evaluate our next minor point upgrade, and in the changelog (between 2.5.23.1 to 2.5.28.1), there are quite a few bugs that we don't quite understand what actually got changed, and we can't further drill down as we don't have access to the Totara bug tracker. For example:

TL-6769: Fixed undefined constant error when deleting a course (??? what does this affect the system stability or users? that's all the description that we got...).

I believe many enterprise subscribers in this forum would really appreciate it if we could have some sort of better visibility to the Totara bug tracker. Thanks!

Dauerlink | Antwort

I agree with Wen also this could cut down on unnecessary support calls when subscribers can see what bugs are being worked on and submitted by other subscriber/partners. Just my 2 cents.

Thank you,

Peter

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Peter,

Thanks for chiming in and letting us know it is of interest to you as well.
It helps us to build an understanding of how many people are interested, and if there is enough interest of course things will change.

As mentioned to Wen already if you are able to share use cases or examples of when you've needed more information and have felt our bug tracker held the answer this would help in us ensuring we do make the information you need available.

Kind regards
Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Sam,

an example is that I recently upgraded to Totara Version 2.7.3. When I contacted My partner about a bug appearing in dynamic audiences it created a bit of work for them and wait time for me. Also lost productive time looking at audiences that had settings that would not work. The reasons I did not see this previously were

#1 I had no visibility of a bug tracker.

#2 I had no active learners in the LMS and therefore did not see any issues.

Providing Subscribed members (whether directly or through a Partner) a more detailed view of Bugs that are known is not only part of transparency that many companies are required to strive for but also would assist in better customer relations with Totara and their Partners in that Personnel with the need to know information about bugs would be better able to handle situations where they might become apparent. Incidentally we are using Most of the features of Totara from competencies to audience based enrollments. Certifications, Programs and many of the elements of courses such as face to face and Lessons that are provided with Totara core.

I am also looking forward to using appraisals and goals as these have many benefits in the aspect of performance management.

Thank you,

Peter

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Totally agree with Peter. +1!

We had similar use cases in the past. Time and $$ got lost in the process when we had to wait for our Totara Partner to get back to us when in reality, if we have some read-only visibility to the Totara bug tracker, it would have made the whole process MUCH more efficient...

Also as I pointed out before, in the changelog some of the changeset description is just way too simple.

For example,

TL-6566 Improved XSS prevention checks when serving untrusted files in IE (what kind of untrusted files??)

TL-6756 Improved information provided by webservices logging (what info are now provided??)

If Moodle can open their bug tracker to public, why can't Totara (at least open to the enterprise subscribers)? It really is a win-win-win for everyone and would be more align with the "open-source" spirit. Thanks again for your consideration!

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Wen,

I've just replied down the bottom, but wanted to chime in here specifically as well.

In regards to the two examples:

TL-6566 even if we did have open up access security issues would still be limited until such a time that subscribers, site administrators and partners all had suitable time to upgrade. This is very similar to what Moodle does and is inline with responsible disclosure best practices. A point on which we would not compromise.
TL-6756 is a good example of an issue where more information is required in order to better understand the issue.

Our process is greatly different to Moodles, and I can tell you right now that there is still a lot in Moodle's tracker which is not made public.
We deal with a lot more sensitive information than Moodle thanks to our support process a several other factors and not nearly as much can be made public presently because of it.
I cover this more in my previous reply.
But just to extend upon it support is how we differ from Moodle, and our support process allows us to respond in the best possible way to reported issues.
A tracker issue is a repository of all resources required for the developer and is primarily for them (presently).
Talking about making things open isn't talking about flicking a switch, it is talking about modifications to our development and support processes to ensure that people are still able to trust us and supply the artefacts that allow us to respond, as well as properly segregating our information so that issues in tracker can be made accessible to partners and/or subscribers without revealing anything confidential or sensitive.

Cheers
Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Der Inhalt des Forumsbeitrags wurde gelöscht und kann nicht weiter angezeigt werden.

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi all,

I completely agree with Maurice. The possibility of having a read-only view of the Totara bug tracker will help to:

- Confirm bugs we found, or suspected to have. We could still write to the helpdesk by possibly providing other use cases where the bug arose.

- Simply saving us time because we can better and faster identify the bug and possibly find temporary turnarounds or patches.

- Make us aware of other bugs.

Regards,

Aldo

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

+1 from me too - for the read only version. It would be useful to if a bug has already been reported and if there was a fix for it.

Also when doing a git show commit, it displays the bugzilla ticket number, so its useful to go back to bugzilla to see the details about the commit.

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Wen,

You asked a very similar question not long ago: General Discussion Forum - Visibility to Totara bug tracker

The response I gave there is still accurate. At present we are keeping our bug tracker private.
Our official support channel is via helpdesk where issues can be reported and where you will be kept up to date on progress of any and all development tasks that relate to your support ticket.

If you still feel you need more visibility than is provided we would interested to here more about your needs, knowing what you would like to be able to see and why would help us to continue to develop our communication channels to best meet your needs.
We are always looking to improve our processes and systems and sharing your use cases would give us great insight into how we could improve things.

Kind regards

Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Sam,

Thanks for you reply, and sorry to ask this question twice (I totally forgot that I posted this question before).

For our use cases, please see my responses above. It's all about efficiency.

In your previous reply, you mentioned that "Keeping tracker private is about providing a development centric environment for our developers in which they can work with issues that have been prioritised and directed by both the support team and their team managers."

==> I don't see there is any conflict if we open the Totara bug tracker (read-only) for Enterprise Subscribers, as they won't be able to comment on the bugs? Also, what if some of your enterprise subscribers are actually Moodle developers? I think Totara developers might benefit from some insights from these Moodle developers as well?

Let me elaborate why I think this is a win-win-win for everyone:

Win for Totara subscribers (customers): More visibility to the bug tracker (read-only) means that less bugging our Totara Partner for support, which lead to better efficiency.

Win for Totara: Build a transparent culture and align with "open-source" spirit. This also means that you get more pairs of eyes on how these bugs are fixed (which is always a good thing). Making your product more robust ==> happy customers ==> project/company success!

Win for Totara Partners: Less time spending on tech support, meaning better focus on the "core" value-added, which is local customization and making the system more stable/scalable, etc.

My $0.02. :)

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi everyone,

Thank you for the feedback so far.
It seems like there are a couple of common use cases here and I think there is some real merit in them.

Unfortunately it is not as easy as just opening read only access.
Each issue in tracker can contain information that is sensitive to any of the three parties involves, to the subscriber, to the partner, and to use as Totara core.
This can include information shared in confidence with Totara for the purpose of investigating and confirming a fix, things such as the following can be found in issues:

Details of the installation and configuration of the site.
Details of hosting and infrastructure including server architecture, versions etc.
Files and content provided by the reporter.
Security issues usually including replication steps which have not be disclosed yet.

I appreciate an open community as much as many of you do, however our support process generates a great number of artefacts that can only be made available to those who need them and in whom we trust.
Tracker as our development platform is how these artefacts are made available to the core developers who require them in order to resolve the issue.

I am sure everyone is in agreement that such information does not need to be made available.
But it is tied into the tracker issues very heavily at the moment and for this reason opening our bug tracker in a read only mode is not a possibility presently.

However the use cases that are arising are very valid, and they help us to confirm that there are advantages to be found in brining visibility to what is there.
The decision for us on whether or not to, is bound to the question of how as well as what.

I cannot promise anything will change, a dialogue has started internally and we are discussing this.
If you have any specifics on what you would like to be able to see (issue number, summary, status, assignee, fix versions etc) or anything other information that may help us in making this decision then now is the time to share it.

Popularity will greatly help this get over the line, so if you are reading this thread and want more visibility but haven't commented yet - comment now!

Final note and as a heads up for potential future discussion we use JIRA as our bug tracker, it is licensed software and the licensing cost of opening it to more users is still an unsolved issue as well.

Kind regards
Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Much of what I say will have already been described by others, but I'll just lay out my perspective.

From a support perspective, the Bugzilla was helpful in our standard troubleshooting process, because we could discover if some aberrant behavior being described by a client was already being worked on and visible to developers. Of course the subscriber community is helpful for this same purpose to a degree, however the visibility to the bug tracker often gave us visibility into issues that were never available in the forums, and even much more technical, low level details. I personally have not felt comfortable bringing up low level technical details in the forums, and as such more or less avoid that level of participation in the forums areas. But the real deal for us is, almost every problem is very complex to a degree that we are constantly troubleshooting issues at the code and db level, and seeing the work that developers are doing at that code level could easily confirm our findings or give is the additional low level insight we need in our support of very technical problems.

Additionally, from the support perspective, we could describe and understand specific bug fixes better than we could have otherwise without the bug tracker. This was helpful when clients asked for more in depth information about a specific bug.

What we found was having access to the bug tracker improved our support efficiency. Yes we can analyze code commits all day, but it doesn't always tell the whole story about the why how of a bug or problem. Furthermore, it didn't make sense to analyze code commits when some very good developers had already understood and described the problem in great detail.

That all said, I certainly can see and understand that the sensitive artifacts included in Jira are not appropriate for sharing in the way that has been requested. I don't know what the right solution is, it certainly would seem it does not exist at this time though. Since now many issues are reported in private channels (with good reason for this) but the community and user base then doesn't get the visibility to the bigger picture and breadth of all the problems/bugs currently being worked on. Maybe what is needed is just better visibility into all of the currently reported bugs, along with descriptions of what conditions and circumstances trigger the bug, which functionalities are affected, etc. So that we can have a place to go to see if something is already a known issue are not. Again, the forums will often times have discussions on current issues, but it certainly is not a complete picture.

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Follow up to my last message... folks are asked to report bugs through the ticketing system, but then visibility of those bugs never comes back to the community at large. THAT is part of the missing transparency for a great many people.

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Excellent point Jamie!!

I guess if JIRA would require a license for "read only" users, then I would suggest at least provide Enterprise Subscribers some visibility regarding changelogs and detailed descriptions (including code diffs) for each changeset. This can be added under the current "Feature documentation for recent versions," (see screenshot), which Totara team is doing a great job over there already!

Remember, not all of the Enterprise Subscribers are using a "stock" Totara. A lot of us are using Totara with upstream HR data sync and hierarchy automation and complex downstream management dashboard integrations, etc.. Lots of local customization! That's why we would really appreciate more technical details regarding each changeset as it could affect our integrations and test plans, etc.

Thanks again for your consideration!

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Wen: Totara partner can provide code diffs as needed, fyi.

Jamie

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Jamie,

It's good to know that Totara partners can provide code diffs.

But, why should we go through Totara partners, and spend $$$ for many hours of support, in order to just get code diffs?

I think that's my point (and your point as well), which is support efficiency.

My $0.02...

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

As a Totara Partner, we provide this level of access to our clients, bypassing the mentioned inefficiency for high level clients.

Jamie

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

This is to respond to Sam's comments, about:

"If you have any specifics on what you would like to be able to see (issue number, summary, status, assignee, fix versions etc) or anything other information that may help us in making this decision then now is the time to share it.

Popularity will greatly help this get over the line, so if you are reading this thread and want more visibility but haven't commented yet - comment now!"

For us, we are in the process of evaluating the upgrade from 2.5.23.1 to 2.5.28.1 (or 2.5.29.1). However, we want to make sure that this minor point upgrade will really address some of our current pain points (instead of just "upgrading for the sake of upgrading")... Here are some changesets that I would really appreciate some more detailed info (e.g. before/after upgrade system behavior changes with screenshots, etc.). This would be very helpful for our decision making:

TL-6319: Fixed rules for dynamic Audiences based on a text input user profile/custom field being empty.

TL-6516: Fixed resetting of Certification message logs when the recertification window opens. When the window opens it tried to delete message logs for the users manager as well as the user even though the manager records were never created.

TL-6581: Improved handling of and recovery from missing Certification completion records.

TL-6305: Fixed Program/Certification alerts and messages to exclude suspended and deleted users.

TL-6345: Fixed setting of a Certification completion status to 'expired' when renewal expires

TL-14131: Added courses which have completion records to the record of learning (RoL).

TL-14114: Fixed program and certification exceptions being regenerated after being resolved. (we need to be able to see some examples to know in what conditions these cert exceptions would be regenerated).

T-14043: Added ability to unlock activity completion without deletion (This change also fixes a bug whereby a user editing an activity included in course completion but not yet completed by any users causes all users who have previously completed the course to loose their data.)

T-14042: Fixed cleanup of users enrolled on a certification by an audience, who are no longer part of the audience.

(My note: The description looks promising and I believe this was fixed in 2.5.24. However, based on our preliminary testing, it doesn't seem to generate the result that we are looking for)...

T-13190: Fixed users being incorrectly enrolled onto unavailable programs

(My note: does this mean that it would fix issues that users would still get an initial Enrollment message even if that program has been "ended" - passed the Program End date? Any other use cases that would count as "unavailable programs"?)

Thanks!

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Wen,

A ticket has been put through your partner to our help desk for this information.
Per our current process that is our preferred approach and we'll deal with getting you some information there.

I'll comment again in a minute on the main thread.

Cheers
Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi everyone,

As mentioned we've discussed giving access to tracker and have come up with a plan.

We are going to start a trial whereby we will give a selected group of partners read only access to tracker issues.
This won't necessarily be all issues, issues that contain private client information and potentially security issues will be kept private.
This won't happen immediately, there are a few hurdles to overcome and we will have to adjust our process in a couple of ways in order to make it happen. I hope to have the trial starting in the next month or two.

If the trial goes successfully and value is found in it then we will open it up to all partners.
At present we're not planning to open it to subscribers sorry - however we can re-evaluate this upon the success of the system if need be.

Kind regards
Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Sam, any update on this please? Thanks!

Dauerlink | Ursprungsbeitrag anzeigen | Antwort

Hi Wen,

We're working on a little tool that will publish details now.
More will come out about it in the near future.

Cheers

Sam

Dauerlink | Ursprungsbeitrag anzeigen | Antwort