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
Issue number format - 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


Deprecated: DateTime::__construct(): Passing null to parameter #1 ($datetime) of type string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Date/Date.php on line 112

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

Issue number format


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

10 years 5 days ago #1 by sanderv
Issue number format was created by sanderv
Hi,


Is it possible to have other "issue numbers" than the randomish 10-digit strings? For instance just consecutive numbers (1, 2, 3, 4, ...) would suit me very well.

Thanks,


Sander.

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

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


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2070


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2070


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2115


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2022


Unknown Error 8192: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in libraries/kunena/external/nbbc/src/BBCode.php on line 2070

10 years 4 days ago #2 by chrisc
Replied by chrisc on topic Issue number format
The short answer is not currently.

The long answer is that it is something we are thinking about. The rationale was that nobody could 'guess' the issue number (alias) which is a dubious security masking. In reality it is possible not that important so could be changed.

Were you thinking of just a plain numeric in which case we could logically just use the actual issue number. Would require some coding so I would have to take a closer look.

The inital 'letter' is currently used to differentiate betwen a front end and a back end raised issue. Is that something that is useful to you?

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.

10 years 4 days ago #3 by sanderv
Replied by sanderv on topic Issue number format
Thank you for that. Yes, the actual issue number would be fine. I'm trying to slightly-mature a currently manual process of keeping track of outstanding issues in just a Joomla article, and having to deal with the 10-long random characters feels like overly painful. ("Dealing" as in human conversation about the issues.)

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

10 years 3 days ago #4 by geoffc
Replied by geoffc on topic Issue number format
As a compromise I would like to pass a suggestion by you. I would like to retain the current issue 'alias' mechanism, but propose to add another option to the component to allow an alternative mechanism.

The 'new' issue number would be built up of a leading character (currently used to unique identify whether a back end or front end issue), followed by the issue number padded to the left with leading zeros to give a total length of 10 characters as present. The issue number would be the current unique id for the issue.

The advantage (from my perspective) is that it is a simple change, that only realy impacts two (virtually similar) routines, and will not impact any other functionality. It would also simplify your 'overly painful' human interaction and be a quick and easy change for 1.6.2 (and which you could implement yourself very easily).

Regards
Geoff

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

10 years 3 days ago #5 by sanderv
Replied by sanderv on topic Issue number format
It makes sense to keep a separate primary key (the record no.) and business key (the alias). If there's a nice, single place (one method or so) that comes up with the business key (the alias) I could make it look whatever I want it to look. In my case, I would then even remove the backend/frontend prefix. Clearly someone must have had use for that, but it doesn't do much for me. Then, also, I wouldn't prefix with zeros. Would there be any constraints that will keep me from doing this?

The only problem that I'm expecting is: how will I generate these numbers? Should be unique, reliable, and preferably equal the primary key (the record no.), to prevent future confusion on my or whoever's end. But I expect that the business key (the alias) must typically be generated before the record is first saved, so that I don't have the record no. available yet. Does that make sense?

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

10 years 3 days ago #6 by geoffc
Replied by geoffc on topic Issue number format
The code for the alias is now in one location (in a helper file) in 1.6.2.

The length of the issue item is really only a limitation in that it would currently save having to modify things which assume the length, such as in the 'latest issues module'. Of course removing the prefix and padding with spaces would achieve the same thing. [Padding with spaces and retaining the prefix is not really sensible, hence the padding with zeros.] I was looking to minimise the coding changes required to be honest.

The code currently gets the 'next id' from the database to build the alias, which of course has to be before the save. Then after the save there has to be a further check to ensure that some other issue hasn't crept in between the earlier two action. If it has then the issue needs an update of the issue alias. This is/can be done in the store/save issue method prior to emails being generated etc.

Could easily be a third option and would be very extensible for other alternatives.

An alternatively to use something other than the issue id might be to make use of a database sequence to ensure that there is a unique value to pick up when it is required. Fetching the sequence value could increment the value. Used to do this with Oracle databases all the time and I suspect MySQL could be used in the same way, although I haven't specifically checked.

[All this could be done in a database transaction in theory, but it amounts to the same logic.]

Regards
Geoff

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

Time to create page: 0.144 seconds
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries