WebSVN – oidplus – Diff – /trunk/TODO



- System status plugin: Check if file owners are mixed
- a possibility to upload & assign custom icons to objects (both in the tree & in the page)
- a possibility to move objects/nodes from one hierarchy level to another (for now, I have to reconstruct them)
- 2FA TOTP support (+backup codes) - good for public instances, like FreeOID (Yes, I'm that one person who always asks for true totp 2FA everywhere xD )
- a setting for a permanent choice between 'Always switch to newly created object' / 'Never switch' / 'Ask user if they want to switch'
 
- a possibility to 'construct' my own object types in UI (1: specify list of their fields and 2: choose "oid-like/forward" com.example.api or "domain-like/reverse" api.example.com naming scheme), so they would appear as the whole new type
 
Recently added TODO entries:
- should all country codes (even unused) in 1.2 and 2.16 be added to the wellknown list?
- "Decoding" section (tech info) at OID nodes, e.g. the AID decoder, should this be a scrolling <pre> block instead of a <code> block? (For mobile devices)

- Let users have their own settings. This could be achieved by the ###_config table, by having a key with the name scheme "<settingname>(<useremail>)".
	Example settings:
	* Own color settings
	* Newly created OIDs: Always open, Never open, Ask (default)
	But what do we do if multiple users are logged in??
 
- if a third-party plugin throws an exception in the init() method, maybe OIDplus should avoid loading the plugin?
- "hidden" alt ids which are not shown in the GUI, but can be used for reverse-Alt-ID ? (I believe we have excluded some AltIDs which are "not neccessary", e.g. an GUID already is a GUID and therefore does not need a Namespace GUID, or something like that)
 
RDAP:
- Extend handle404() to handle more things required by the RFC, as well as more object types

- when user changed email from "A" => "B", then all previous log events for "A" are not visible for "B" anymore!
	=> should we also change the log entry email address references when the user changes their email address?
- At "oidplus:system_log", user log section and object log section, the users and/or objects should be clickable
 
IDEAS
- Backup plugin (adminPage 401): Use an INTF_OID_ interface let other plugins backup/restore their own data/tables, too.
- Backup plugin (adminPage 401): In addition to the already existing database backup, also let the user choose to download a ZIP containing userdata and userdata_pub
- admin plugin that shows the recent oid edits / inserts?
- in the search feature, search for object creation/update date?
- adminPages/800_plugins: We could also list plugins that have been blacklisted in the config? But that is hard to achieve, because these plugins are ignored and not loaded at all
- Similar to Security Event Token, we could issue JWT tokens which log the allocation of an OID to an RA. This signed token can be stored somewhere and can be used to proove the ownership of an OID.
- have an option to assign a custom icon to any object in the system (file attachment with name "icon.*"?). Especially useful for easy visual distinguishing between root objects inside 'Other objects', but may be useful for other object types too.

Subversion Repositories oidplus

oidplus/trunk/TODO – Rev 1401 → 1405

Rev 1401		Rev 1405
Line 67...		Line 67...
67	- System status plugin: Check if file owners are mixed	67	- System status plugin: Check if file owners are mixed
68	- a possibility to upload & assign custom icons to objects (both in the tree & in the page)	68	- a possibility to upload & assign custom icons to objects (both in the tree & in the page)
69	- a possibility to move objects/nodes from one hierarchy level to another (for now, I have to reconstruct them)	69	- a possibility to move objects/nodes from one hierarchy level to another (for now, I have to reconstruct them)
70	- 2FA TOTP support (+backup codes) - good for public instances, like FreeOID (Yes, I'm that one person who always asks for true totp 2FA everywhere xD )	70	- 2FA TOTP support (+backup codes) - good for public instances, like FreeOID (Yes, I'm that one person who always asks for true totp 2FA everywhere xD )
71	- a setting for a permanent choice between 'Always switch to newly created object' / 'Never switch' / 'Ask user if they want to switch'	71	- a setting for a permanent choice between 'Always switch to newly created object' / 'Never switch' / 'Ask user if they want to switch'
72	- a possibility to export&transfer all data between OIDplus'es: Attention: Do not use this XML Export/Import to exchange, backup or restore data between OIDplus systems!	-
73	- a possibility to 'construct' my own object types in UI (1: specify list of their fields and 2: choose "oid-like/forward" com.example.api or "domain-like/reverse" api.example.com naming scheme), so they would appear as the whole new type	72	- a possibility to 'construct' my own object types in UI (1: specify list of their fields and 2: choose "oid-like/forward" com.example.api or "domain-like/reverse" api.example.com naming scheme), so they would appear as the whole new type
74		73
75	Recently added TODO entries:	74	Recently added TODO entries:
76	- should all country codes (even unused) in 1.2 and 2.16 be added to the wellknown list?	75	- should all country codes (even unused) in 1.2 and 2.16 be added to the wellknown list?
77	- "Decoding" section (tech info) at OID nodes, e.g. the AID decoder, should this be a scrolling <pre> block instead of a <code> block? (For mobile devices)	76	- "Decoding" section (tech info) at OID nodes, e.g. the AID decoder, should this be a scrolling <pre> block instead of a <code> block? (For mobile devices)
Line 85...		Line 84...
85	- Let users have their own settings. This could be achieved by the ###_config table, by having a key with the name scheme "<settingname>(<useremail>)".	84	- Let users have their own settings. This could be achieved by the ###_config table, by having a key with the name scheme "<settingname>(<useremail>)".
86	Example settings:	85	Example settings:
87	* Own color settings	86	* Own color settings
88	* Newly created OIDs: Always open, Never open, Ask (default)	87	* Newly created OIDs: Always open, Never open, Ask (default)
89	But what do we do if multiple users are logged in??	88	But what do we do if multiple users are logged in??
90	- "Download Complete Backup" plugin (contains a full SQL backup for all DBMS, as well as everything inside "userdata" and "userdata_pub")	-
91	- if a third-party plugin throws an exception in the init() method, maybe OIDplus should avoid loading the plugin?	89	- if a third-party plugin throws an exception in the init() method, maybe OIDplus should avoid loading the plugin?
92	- "hidden" alt ids which are not shown in the GUI, but can be used for reverse-Alt-ID ? (I believe we have excluded some AltIDs which are "not neccessary", e.g. an GUID already is a GUID and therefore does not need a Namespace GUID, or something like that)	90	- "hidden" alt ids which are not shown in the GUI, but can be used for reverse-Alt-ID ? (I believe we have excluded some AltIDs which are "not neccessary", e.g. an GUID already is a GUID and therefore does not need a Namespace GUID, or something like that)
93		91
94	RDAP:	92	RDAP:
95	- Extend handle404() to handle more things required by the RFC, as well as more object types	93	- Extend handle404() to handle more things required by the RFC, as well as more object types
Line 292...		Line 290...
292	- when user changed email from "A" => "B", then all previous log events for "A" are not visible for "B" anymore!	290	- when user changed email from "A" => "B", then all previous log events for "A" are not visible for "B" anymore!
293	=> should we also change the log entry email address references when the user changes their email address?	291	=> should we also change the log entry email address references when the user changes their email address?
294	- At "oidplus:system_log", user log section and object log section, the users and/or objects should be clickable	292	- At "oidplus:system_log", user log section and object log section, the users and/or objects should be clickable
295		293
296	IDEAS	294	IDEAS
297	- Database plugin (adminPage 401): Use an INTF_OID_ interface let other plugins backup/restore their own data/tables, too.	295	- Backup plugin (adminPage 401): Use an INTF_OID_ interface let other plugins backup/restore their own data/tables, too.
-		296	- Backup plugin (adminPage 401): In addition to the already existing database backup, also let the user choose to download a ZIP containing userdata and userdata_pub
298	- admin plugin that shows the recent oid edits / inserts?	297	- admin plugin that shows the recent oid edits / inserts?
299	- in the search feature, search for object creation/update date?	298	- in the search feature, search for object creation/update date?
300	- adminPages/800_plugins: We could also list plugins that have been blacklisted in the config? But that is hard to achieve, because these plugins are ignored and not loaded at all	299	- adminPages/800_plugins: We could also list plugins that have been blacklisted in the config? But that is hard to achieve, because these plugins are ignored and not loaded at all
301	- Similar to Security Event Token, we could issue JWT tokens which log the allocation of an OID to an RA. This signed token can be stored somewhere and can be used to proove the ownership of an OID.	300	- Similar to Security Event Token, we could issue JWT tokens which log the allocation of an OID to an RA. This signed token can be stored somewhere and can be used to proove the ownership of an OID.
302	- have an option to assign a custom icon to any object in the system (file attachment with name "icon.*"?). Especially useful for easy visual distinguishing between root objects inside 'Other objects', but may be useful for other object types too.	301	- have an option to assign a custom icon to any object in the system (file attachment with name "icon.*"?). Especially useful for easy visual distinguishing between root objects inside 'Other objects', but may be useful for other object types too.