1. Forum
  3. Joomla
  5. Issue Tracker
  7. General Questions

General Questions

7 years 10 months ago #1 by chimz
General Questions was created by chimz
Hello, can i please have knowledge on how to do the following:
When a user is deleting or purging something, for example the 'Display Log', can the system give a warning before they proceed, something like 'Are you sure you want to delete'..I accidentally purged my log today when i wanted to just test how it works.

Another thing is, I have a link which directs a user to the all issues list, and when they are filtering by Project/Priority etc the system right away returns results before the user finishes their selection. Can I have a way of letting the user finish their selection first?for example they want to display issues with a high priority for a certain project which were identified within a specified time period?can it let the user specify all three filters first then it loads the results once?because this thing of selecting one filter and then it displays and takes the user to the top of the page and then they have to scroll down again and get back to select another filter and on and on kind of annoys them.

I really hope this is possible and sorry for asking too much

Please Log in or Create an account to join the conversation.

7 years 10 months ago #2 by geoffc
Replied by geoffc on topic General Questions
Hmm A prompt before the delete actually runs? This was considered but was not implemented, basically because it can get very annoying when one presses the 'delete' button, and one is presented with another screen saying 'are you sure?'. The usual answer is 'Yes, that is exactly why I pressed the delete button!' We will consider it for a future version, but to be honest that type of feature can get equally as annoying. It can be implemented by adding a couple of extra lines of javascript in the back end log display, probably better as a template override, otherwise any changes that are made would be over-ridden on a component update.

The front end issue list immediately fetching the issues when a filter is chosen, is another one of those 'annoyances' for some people. Changing the filter causes the javascript to then kick in, hence the effect that you see. The only alternative is to have an additional button that says 'Go' once all the filters are selected. If you are only changing one filter this is an extra step that has to be taken. There are pros and cons to it. On this possible option there are probably as many people who hate it as those that would love it, and to be honest although aware of the situation, you are the first person who has raised it as a possible future change. Again we will consider it for a future update, particularly if we can come up with an easy way to satisfy both camps. Again you could create a template override and add some javascript to achieve this, but it would be more code that the above.

Thank you for taking the time to raise it as a possible future enhancement, but would equally appreciate anyone else adding their comments upon these are possible future changes.
Regards
Geoff

Please Log in or Create an account to join the conversation.

7 years 9 months ago #3 by ashley
Replied by ashley on topic General Questions
Good day, I'm having these two problems please help:
1.After creating triggers and i open the change history tab,it doesn't show me who made the change(please refer to attached picture), the column is there but it's always empty,am i missing something?
2.I have three separate projects and each has its two supervisors,is there a way of making the system send emails only to certain individuals when an issue is assigned to a certain project and not to all admins?and also maybe for types,like if an issue is a Defect send emails to A&B and if its for Documentation send only to B&C
Thanks in advance for helping
Attachments:

Please Log in or Create an account to join the conversation.

7 years 9 months ago - 7 years 9 months ago #4 by chrisc
Replied by chrisc on topic General Questions
Hmm.
First the changed_by field. Basically this is not a problem usually per se, since the information is often not available to populate. To explain further, the trigger runs within the database and it captures the information passed to the database and records what is there, so for a text field we can capture what the contents of the field was, and obviously what the new field value will be. When we come to who made the change, we have another small problem, since all the changes made by the component are going through Joomla, which uses the Joomla connection information, but does not pass through to the database the details of the actual user (user_id or anything else) on whose behalf the change is being made. It will always be the Joomla user connection detail user, which may or may not (usually not), which is virtually useless for auditing purpose for identifying an individual. Only way to resolve this is to 'hack' the Joomla core core, which is not a good idea.

If the component itself can pass the information which should be/is the case with the it_issues table then we should be recording it, which we are doing. But its not the changed_by field that you need to be looking at. You are using an INSERT trigger, and therefore the field that is of use to you is the 'identified_by' field which is shown in the picture as id=34. There is an option to change that to the actual username. You should also see a 'created_by field in the list, not shown in your picture, which will be the id of the user that created the issue, (or their name it the option is used). On an update the 'modified_by field would have the value of the Joomla user who made the change.

The 'changed_by' field is only useful if someone makes the change in the database itself via myphpadmin or similar, when it capture the database login details.

Re the second question, currently there is no concept of different types of admin users. They are all effectively the same, hence all get the same messages. Its an interesting idea though. I will think about it, but no guarantees (as usual). Not sure how much work would be involved with such a change.
Regards

If you are using our extensions please leave a review at the JED: IP Mapping | Issue Tracker | JAudit | Password Control

Please Log in or Create an account to join the conversation.

7 years 9 months ago - 7 years 9 months ago #5 by ashley
Replied by ashley on topic General Questions
I'm not seeing the 'created_by field' as you're saying I should,so does this mean there is a problem?

Please Log in or Create an account to join the conversation.

7 years 9 months ago #6 by geoffc
Replied by geoffc on topic General Questions
I suspect that you may be misunderstanding or looking in the wrong column. They would show just as any other column that is changed. It is the only way one can force Joomla to show change information, without modifying the core.

The rationale is that the underlying database trigger has to be 'correct' and enabled otherwise you wouldn't see any change fields whatsoever. Your snapshot indicated that these are 'correct'.

I have run a test myself and I can see the field in the audit change records. The 'created_by' and 'created_on' fields are only populated (in the table class) on a new issue being created. i.e. an INSERT trigger. On an update (or delete) the 'modified_by' and 'modified_on' fields are populated. i.e. an UPDATE (or DELETE) trigger.

These issue tracker table fields are (all) populated also by the Issue Tracker Table class, and if they were wrong I am sure you would have seen a PHP error, or something.

I do not think there is a problem with the code, or if there is I am not aware of it, and cannot replicate a problem. The code itself hasn't changed since 1.6.5 so I think if there had been a problem it would have shown before now.
Regards
Geoff

Please Log in or Create an account to join the conversation.

  1. Forum
  3. Joomla
  5. Issue Tracker
  7. General Questions
Time to create page: 0.162 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries