Difference between revisions of "Community Notification Standard"
m (Mercury moved page Community Notification Standards to Community Notification Standard) |
Tag: 2017 source edit |
||
(12 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | Lorekeeper's notification system makes use of | + | Lorekeeper's notification system makes use of many notification types-- one for each type of notification a user can receive. These are hard-coded as constants in the Notification model, with messages and associated information defined in the Notifications config file. That is, each notification type has a unique ID number which is stored in the database alongside the notification's data and which helps structure the notification using information from the config file. Given this, it's understandably important that overlap not occur in these IDs. |
To account for this, the community has created a standard wherein base LK, as well as individual extension creators, are allotted a block of 100 numbers each in which to define notification IDs to ensure that no overlap occurs. The currently assigned blocks are as follows: | To account for this, the community has created a standard wherein base LK, as well as individual extension creators, are allotted a block of 100 numbers each in which to define notification IDs to ensure that no overlap occurs. The currently assigned blocks are as follows: | ||
Line 11: | Line 11: | ||
|- | |- | ||
|1xx (100-199) | |1xx (100-199) | ||
− | |Uri | + | |Uri/Preimpression |
|- | |- | ||
|2xx | |2xx | ||
− | | | + | |Ne-wt |
|- | |- | ||
|3xx | |3xx | ||
− | | | + | |TGI |
|- | |- | ||
|4xx | |4xx | ||
Line 23: | Line 23: | ||
|- | |- | ||
|5xx | |5xx | ||
− | |Mercury | + | |Mercury/itinerare |
|- | |- | ||
|6xx | |6xx | ||
|Draginraptor | |Draginraptor | ||
+ | |- | ||
+ | |7xx | ||
+ | |DeeP-ci | ||
+ | |- | ||
+ | |8xx | ||
+ | |Wormbie | ||
+ | |- | ||
+ | |9xx | ||
+ | |AW0005 | ||
+ | |- | ||
+ | |10xx | ||
+ | |AnimatedCritter | ||
+ | |- | ||
+ | |11xx | ||
+ | |CH3RVB | ||
+ | |- | ||
+ | |12xx | ||
+ | |SpeedyD | ||
+ | |- | ||
+ | |13xx | ||
+ | |Cylunny | ||
+ | |- | ||
+ | |14xx | ||
+ | |sunnsetcadett | ||
|} | |} | ||
− | == Reassigning Notification Type ID in the Database == | + | ==Request an ID Block== |
− | If you created an extension prior to this standard, after reassigning IDs in the notification model you may wish to move existing notifications in a site's database so as to prevent errors. This can be done with the use of the extension service found in | + | To request an ID block for use in developing extensions, please reply [https://github.com/corowne/lorekeeper/issues/29 here]. |
+ | |||
+ | ==Reassigning Notification Type ID in the Database== | ||
+ | If you created an extension prior to this standard, after reassigning IDs in the notification model and config file you may wish to move existing notifications in a site's database so as to prevent errors. This can be done with the use of the extension service found in versions [[Updating: to 2.0.0|2.0.0]] and later. An example command making use of this service can be found [https://github.com/itinerare/lorekeeper/blob/15f9ba0a750f4a08d1e3e07139ad32a0b3c7fc9f/app/Console/Commands/FixCharItemNotifs.php here], made for [[Extensions:Character Items|Character Items]]. | ||
+ | |||
+ | The key part is this: | ||
+ | <pre> | ||
+ | (new ExtensionService)->updateNotifications(39, 501); | ||
+ | (new ExtensionService)->updateNotifications(40, 502); | ||
+ | </pre>In short, it calls the updateNotification function from the Extension service, once each for each notification type that needs reassigning within the database. The first parameter is the notification type ID to be reassigned, and the second is the ID it should be reassigned to. In this case, 39 becomes 501 and 40 becomes 502. | ||
+ | [[Category:Documentation]] |
Revision as of 18:16, 23 September 2024
Lorekeeper's notification system makes use of many notification types-- one for each type of notification a user can receive. These are hard-coded as constants in the Notification model, with messages and associated information defined in the Notifications config file. That is, each notification type has a unique ID number which is stored in the database alongside the notification's data and which helps structure the notification using information from the config file. Given this, it's understandably important that overlap not occur in these IDs.
To account for this, the community has created a standard wherein base LK, as well as individual extension creators, are allotted a block of 100 numbers each in which to define notification IDs to ensure that no overlap occurs. The currently assigned blocks are as follows:
ID Block | Assigned To |
---|---|
xx (0-99) | Core Lorekeeper |
1xx (100-199) | Uri/Preimpression |
2xx | Ne-wt |
3xx | TGI |
4xx | Juni |
5xx | Mercury/itinerare |
6xx | Draginraptor |
7xx | DeeP-ci |
8xx | Wormbie |
9xx | AW0005 |
10xx | AnimatedCritter |
11xx | CH3RVB |
12xx | SpeedyD |
13xx | Cylunny |
14xx | sunnsetcadett |
Request an ID Block
To request an ID block for use in developing extensions, please reply here.
Reassigning Notification Type ID in the Database
If you created an extension prior to this standard, after reassigning IDs in the notification model and config file you may wish to move existing notifications in a site's database so as to prevent errors. This can be done with the use of the extension service found in versions 2.0.0 and later. An example command making use of this service can be found here, made for Character Items.
The key part is this:
(new ExtensionService)->updateNotifications(39, 501); (new ExtensionService)->updateNotifications(40, 502);
In short, it calls the updateNotification function from the Extension service, once each for each notification type that needs reassigning within the database. The first parameter is the notification type ID to be reassigned, and the second is the ID it should be reassigned to. In this case, 39 becomes 501 and 40 becomes 502.