Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170
Resolved: Issue Tracker Version 1.2.1 - Macrotone Forum

Unknown Error 8192: KunenaControllerApplicationDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in libraries/kunena/controller/application/display.php on line 21


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/route/route.php on line 437


Unknown Error 8192: ComponentKunenaControllerWidgetAnnouncementDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/widget/announcement/display.php on line 18


Unknown Error 8192: ComponentKunenaControllerTopicItemDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/display.php on line 25


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/forum/category/category.php on line 415


Unknown Error 8192: Automatic conversion of false to array is deprecated in libraries/kunena/bbcode/bbcode.php on line 107

Resolved: Issue Tracker Version 1.2.1


Unknown Error 8192: ComponentKunenaControllerTopicItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/actions/display.php on line 23


Unknown Error 8192: ComponentKunenaControllerTopicPollDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/poll/display.php on line 21


Unknown Error 8192: ComponentKunenaControllerTopicItemMessageDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/topic/item/message/display.php on line 23

11 years 7 months ago - 11 years 7 months ago #1 by freddiesfather
Hi Geoff,

As you can see from my other threads v 1.2.1 has resolved my previous issues. You well and truly deserve a pat on the back for this latest release bug fixes.

I have now have what I suspect to be config settings as I did a completely fresh install.

1. I note that when a new user is created at the front end and they activate their account through the email link they are not automatically PUBLISHED within Issue Tracker People but rather are created in an UNPUBLISHED state. Am I missing a setting to auto publish a user and ideally auto set the notify flag or is this by design?

2. As I understood from a previous thread as far as permissions go it is enough to allow REGISTERED users - ACTION - EDIT OWN in Issue Tracker - Options. However unless I Allow Create the logged in user is unable to submit an issue and receives an error about not being registered although they are logged in. As soon as CREATE is ALLOWED for REGISTERED they get their issue submission screen no problem. I only ask because I never like to give more permissions than I need to.

3. When I update an issue as admin in the front end (using JCE editor) I am typing with white font on white background and changing the font colour in JCE does not make any difference, I wondered if it picks this up somewhere from Issue Tracker. The reason I ask is that If I log into the front end as admin and select an article to edit (NOT an issue) using JCE I am automatically using black font on white and the editor responds to changes I make to the colour of the font within JCE.

Regards

Wayne

Edited by freddiesfather - 12.09.2012 02:03

Edited by freddiesfather - 12.09.2012 02:11

Unknown Error 8192: ComponentKunenaControllerMessageItemActionsDisplay implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in components/com_kunena/controller/message/item/actions/display.php on line 25

The topic has been locked.
11 years 7 months ago #2 by geoffc
Thank you for your kind works.

In answer to your questions.

1. I note that when a new user is created at the front end and they activate their account through the email link they are not automatically PUBLISHED within Issue Tracker People but rather are created in an UNPUBLISHED state. Am I missing a setting to auto publish a user and ideally auto set the notify flag or is this by design?

A: There is an option to specify the default published state, by default it is set to unpublished. It should do what you require.

2. As I understood from a previous thread as far as permissions go it is enough to allow REGISTERED users - ACTION - EDIT OWN in Issue Tracker - Options. However unless I Allow Create the logged in user is unable to submit an issue and receives an error about not being registered although they are logged in. As soon as CREATE is ALLOWED for REGISTERED they get their issue submission screen no problem. I only ask because I never like to give more permissions than I need to.

A: Sorry you are correct. I was assuming that you were allowing the Public to be able to create issues, in which case the Public group would have the CREATE permission, and hence the Regsitered group would inherit the permissions. If you are not letting the public create issues, then you are correct you need to specifically grant create to 'registered'.

3. When I update an issue as admin in the front end (using JCE editor) I am typing with white font on white background and changing the font colour in JCE does not make any difference, I wondered if it picks this up somewhere from Issue Tracker. The reason I ask is that If I log into the front end as admin and select an article to edit (NOT an issue) using JCE I am automatically using black font on white and the editor responds to changes I make to the colour of the font within JCE.

A: I do not do anything much with the editors that you use on a site. About all I do is control the buttons. i.e. You do not really need the 'Insert Article', 'Read More' etc. which I suppress. I use JCE on my own website and certainly do not see any problem with fonts. I did however have a similar problem with the JCK editor but MCE and JCE have always worked fine especially for admin. I never found out why JCK didn't work, but since it was only being used for testing, I never followed it up. I think I wrote something in the manual about my JCE experiences but I doubt that it will be much asistance. As Admin on the front end, JCE was fully functional, it was with users using JCE that I had a problem, which I resolved. Sorry. It might be worth trying a different editor to see it that makes any difference, and might give a clue. One other thought is that it might be template related somehow? There is not really much (hardly any) css definitions that Issue Tracker uses or defines itself, instead using existing site settings, which is one possible cause of the problem, which might be worth looking into.

If I think of anything I will update this post. If you find out please also let me know, as I am interested to find out as well.

Regards
Geoff
The topic has been locked.
11 years 7 months ago #3 by freddiesfather
Hi Geoff,

Thank you for all the responses.

Can you just confirm, the only default UN/PUBLISHED setting I can find is in Issue Tracker - General Settings but that is for the state of the ISSUE when it is first saved and NOT the UN/PUBLISHED state of a new user. I looked in People - Options but of course this is the same Options! Can you point me in the right direction please.

As for the editor I will do some more testing and let you know if I come up with anything.

Regards

Wayne
The topic has been locked.
11 years 7 months ago #4 by geoffc
Oops. I must have been tired last night when I responded, because you are correct, the published option is for issues NOT people.

To do that there would need to be some changes. The reason this hasn't been implemented is due to the 'sensitive' nature of publishing people details.

Before we look into it we would need some details of what you would required. There are two distinct situations where people can get created.

1. When a user registers on a site there is a plugin that automatically enters the person into the it_people table.
2. If the appropriate options are set then a person (unregistered) can be created in the it_people table The 'anonymous' user (and the sample people) are examples of these.

The 'published' flag in it_people was originally only intended to control the people list display on the front end. Would you want both 'automatically' published, or only one, and if so which one?

Would you envisage there to be any other difference between 'published' and 'unpublished' other than the people list display on the front end? [We could see a possible need to 'mask' the details of 'unpublished' people from the display of their information in the front end displays. i.e. Issue details etc. This could some start getting a little complex.] We currently assume that users are prepared to have their name and username make public but not necessarily their email address etc. There are some menu display options that already control this. Issues of couse only contain links to these fields and do not display them.

We would, presumably require another option parameter to impact people, since it would not make sense to use the 'default issue published' option for people as well. Not everyone would want people 'published' I suspect.

I do not think it would be difficult to implement, provided it is a display in the it_people lists that is required. Off hand I would say there are about a dozen lines of code required in about 6 files. If masking of 'unpublished' user details is required there woul be many more.

Let me know your opinion and we can take it from there.

Regards
Geoff
The topic has been locked.
11 years 7 months ago #5 by freddiesfather
Hi Geoff,

I think I have misunderstood the purpose of a USER being PUBLISHED in ISSUE TRACKER - PEOPLE. I previously understood that a USER needed to be published even to see his OWN issues and interact with ISSUE TRACKER. Can you please confirm then that a status of UN/PUBLISHED in PEOPLE only dictates if a user can or cannot be seen by other users when the the menu item LIST ALL ISSUES is used with the DISPLAY OPTION SHOW USERS ISSUES is set to NO. If this is the case and as long as there is no impact on a user being UNPUBLISHED as my set up is USERS can ONLY see their own issues anyway then the current process works correctly for my scenario.

Regards

Wayne
The topic has been locked.
11 years 7 months ago #6 by geoffc
The purpose of the 'published' in it_people is currently soley to indicate whether they are visible in the it_people list view.

A registered user can, if the menu item is set up to 'See own issues' see all their issues published and unpublished. Whether the published flag is set in it_people is irrelevant to achieving this.

Regards
Geoff

Other users can only see issues that are published. The published state of the person in not involved.

There is one exception to this and this is the issue administrator(s), who if the Menu option 'display all' (added in 1.2.2) can see every issue. There are checks to ensure that the user is indeed an issue adminstrator in the data fetch.

Edited by geoffc - 13.09.2012 17:33

I suspect that I need to write something in the FAQ and/or the documentation to clarify all this.

Edited by geoffc - 13.09.2012 17:37

I have updated the FAQ and included a link to an article going into a little more details about component and menu options. It will be updated as time permits with new information, as well as being included in any future documentation.

Edited by geoffc - 14.09.2012 18:11

Regards
Geoff
The topic has been locked.
Time to create page: 0.140 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries