Authorisation File - Revision history

Arvind: /* Rules for Customising the Authorisation Table */

2021-12-05T06:19:04Z

Rules for Customising the Authorisation Table

← Older revision		Revision as of 06:19, 5 December 2021
Line 217:		Line 217:
	#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead. If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]		#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead. If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]
	#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.		#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.
	#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.		#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access as this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.

	====How to set up departments or user groups in Authorisation File for multiple companies in the same dataset====		====How to set up departments or user groups in Authorisation File for multiple companies in the same dataset====

Arvind: /* Access restriction by IP No. */

2020-03-18T13:03:49Z

Access restriction by IP No.

Show changes

Arvind: /* Tasks and Locks */

2018-05-27T08:50:11Z

Tasks and Locks

← Older revision		Revision as of 08:50, 27 May 2018
Line 29:		Line 29:
	A typical lock code might be AA (mneumonic for "access accounts") which would be placed on all general accounting tasks except those requiring further limitations. The AA key would only be given to accountants, thereby placing a convenient blank restriction on the ability of non-accountants from accessing accounting functions.		A typical lock code might be AA (mneumonic for "access accounts") which would be placed on all general accounting tasks except those requiring further limitations. The AA key would only be given to accountants, thereby placing a convenient blank restriction on the ability of non-accountants from accessing accounting functions.

	A blank locks field on a task ~~which is under Mandatory authorisation~~ means that the task is ~~NOT AUTHORISED TO ANYBODY~~ EXCEPT NEOSYS not ~~everybody authorised~~. ~~Only a~~ few tasks are ~~kept~~ under ~~Mandatory~~ authorisation, ~~for eg:~~ JOURNAL POSTING, COMPANY ACCESS 'X'.		For mandatory authorisations, a blank locks field on a task means that the task is not authorised to anybody EXCEPT NEOSYS, not open to every user. Currently very few tasks are under mandatory authorisation, e.g. JOURNAL POSTING, access to particular records like COMPANY ACCESS 'X'.

	The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.		The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.

Joel: /* Tasks and Locks */

2018-05-24T11:53:51Z

Tasks and Locks

← Older revision		Revision as of 11:53, 24 May 2018
Line 28:		Line 28:

	A typical lock code might be AA (mneumonic for "access accounts") which would be placed on all general accounting tasks except those requiring further limitations. The AA key would only be given to accountants, thereby placing a convenient blank restriction on the ability of non-accountants from accessing accounting functions.		A typical lock code might be AA (mneumonic for "access accounts") which would be placed on all general accounting tasks except those requiring further limitations. The AA key would only be given to accountants, thereby placing a convenient blank restriction on the ability of non-accountants from accessing accounting functions.

			A blank locks field on a task which is under Mandatory authorisation means that the task is NOT AUTHORISED TO ANYBODY EXCEPT NEOSYS not everybody authorised. Only a few tasks are kept under Mandatory authorisation, for eg: JOURNAL POSTING, COMPANY ACCESS 'X'.

	The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.		The lock code "NEOSYS" locks all users out of a task without exception, the key "NEOSYS" should not be given to any user.

Gregory: /* Tasks and Locks */

2018-03-18T13:09:23Z

Tasks and Locks

← Older revision		Revision as of 13:09, 18 March 2018
Line 19:		Line 19:
	The various tasks that users may be authorised to do are listed and have a single code (lock) next to them. The same code (lock) may be placed on many tasks, allowing the bulk authorisation of groups of tasks according to need. The grouping of tasks can be seen by sorting the tasks in order of their lock codes by clicking on the column heading titled "Locks".		The various tasks that users may be authorised to do are listed and have a single code (lock) next to them. The same code (lock) may be placed on many tasks, allowing the bulk authorisation of groups of tasks according to need. The grouping of tasks can be seen by sorting the tasks in order of their lock codes by clicking on the column heading titled "Locks".

	Often to do accomplish some function in NEOSYS you need to be authorised to do more than one task in the authorisation table. For example to update a media schedule you need to be authorised to both access the schedule file and to update it.		Often to accomplish some function in NEOSYS you need to be authorised to do more than one task in the authorisation table. For example to update a media schedule you need to be authorised to both access the schedule file and to update it.

	Access to individual records may be restricted by appending the record key in quotes for example placing a lock on a task called ACCESS COMPANY "X" would restrict access to that company. To restrict access generally to a file but allow access to specific records, place a lock on the file eg ACCESS COMPANY but specifically enable access (place a lock) to specific records eg ACCESS COMPANY "X".		Access to individual records may be restricted by appending the record key in quotes for example placing a lock on a task called ACCESS COMPANY "X" would restrict access to that company. To restrict access generally to a file but allow access to specific records, place a lock on the file eg ACCESS COMPANY but specifically enable access (place a lock) to specific records eg ACCESS COMPANY "X".

Arvind: /* CIDR notation */

2017-07-17T07:51:22Z

CIDR notation

← Older revision		Revision as of 07:51, 17 July 2017
Line 257:		Line 257:

	==== CIDR notation ====		==== CIDR notation ====
	In Classless Inter-Domain Routing, or CIDR is a notation where you can add a specification in the IP address itself as to the number of significant bits that make up the routing or networking portion.		Classless Inter-Domain Routing, or CIDR, is a notation where you can add a specification in the IP address itself as to the number of significant bits that make up the routing or networking portion.

	For example, we could express the idea that the IP address 192.168.0.15 is associated with the netmask 255.255.255.0 by using the CIDR notation of 192.168.0.15/24. This means that the first 24 bits of the IP address given are considered significant for the network routing. Each octet consists of 8 bits. Therefore if only first 24 bits of the IP address given are considered significant for the network routing, it means that only the first 3 octets are considered as significant. This is equivalent to 192.168.0.* in NEOSYS format.		For example, we could express the idea that the IP address 192.168.0.15 is associated with the netmask 255.255.255.0 by using the CIDR notation of 192.168.0.15/24. This means that the first 24 bits of the IP address given are considered significant for the network routing. Each octet consists of 8 bits. Therefore if only first 24 bits of the IP address given are considered significant for the network routing, it means that only the first 3 octets are considered as significant. This is equivalent to 192.168.0.* in NEOSYS format.

	=== “Per User” Authorisations ===		=== “Per User” Authorisations ===

Arya Mohandas: /* Access restriction by IP No. */

2017-07-13T13:35:18Z

Access restriction by IP No.

← Older revision		Revision as of 13:35, 13 July 2017
Line 255:		Line 255:
	* The user NEOSYS has been restricted to login only from Private LAN, NEOSYS Office/VPN IP addresses and configured static IP addresses.<BR>Ordinary users may or may not be authorised to login from dynamic IP addresses outside the office, but the user NEOSYS cannot.		* The user NEOSYS has been restricted to login only from Private LAN, NEOSYS Office/VPN IP addresses and configured static IP addresses.<BR>Ordinary users may or may not be authorised to login from dynamic IP addresses outside the office, but the user NEOSYS cannot.
	* To prevent NEOSYS access from WAN (public internet) via a NAT router with a private LAN IP, we list the full IP of the NAT Router in the System Configuration File.		* To prevent NEOSYS access from WAN (public internet) via a NAT router with a private LAN IP, we list the full IP of the NAT Router in the System Configuration File.

			==== CIDR notation ====
			In Classless Inter-Domain Routing, or CIDR is a notation where you can add a specification in the IP address itself as to the number of significant bits that make up the routing or networking portion.

			For example, we could express the idea that the IP address 192.168.0.15 is associated with the netmask 255.255.255.0 by using the CIDR notation of 192.168.0.15/24. This means that the first 24 bits of the IP address given are considered significant for the network routing. Each octet consists of 8 bits. Therefore if only first 24 bits of the IP address given are considered significant for the network routing, it means that only the first 3 octets are considered as significant. This is equivalent to 192.168.0.* in NEOSYS format.

	=== “Per User” Authorisations ===		=== “Per User” Authorisations ===

Priyanka: /* Rules for Customising the Authorisation Table */

2017-06-05T07:26:09Z

Rules for Customising the Authorisation Table

← Older revision		Revision as of 07:26, 5 June 2017
Line 209:		Line 209:
	#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [[Authorisation_File#How_to_set_up_departments_or_user_groups_in_Authorisation_File_for_multiple_companies_in_the_same_dataset\| below section for more information on this]])		#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [[Authorisation_File#How_to_set_up_departments_or_user_groups_in_Authorisation_File_for_multiple_companies_in_the_same_dataset\| below section for more information on this]])
	#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.		#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.
	#Do not create new ~~keys~~ for convenience. Existing keys must be reused where ever possible. Good support is doing the right thing for the long-term success of the system. Refer to [[Authorisation_File#Tasks_and_Locks\| ~~Tasks~~ and ~~Locks~~]]		#Do not create new locks for new or existing tasks for convenience. Existing keys must be reused where ever possible. Good support is doing the right thing for the long-term success of the system. Refer to [[Authorisation_File#Tasks_and_Locks\| allowed tasks and locks]], also refer to STARTUP database for any new tasks and locks
	#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead. If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]		#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead. If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]
	#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.		#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.

Priyanka: /* Rules for Customising the Authorisation Table */

2017-06-05T07:19:53Z

Rules for Customising the Authorisation Table

← Older revision		Revision as of 07:19, 5 June 2017
Line 209:		Line 209:
	#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [[Authorisation_File#How_to_set_up_departments_or_user_groups_in_Authorisation_File_for_multiple_companies_in_the_same_dataset\| below section for more information on this]])		#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [[Authorisation_File#How_to_set_up_departments_or_user_groups_in_Authorisation_File_for_multiple_companies_in_the_same_dataset\| below section for more information on this]])
	#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.		#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.
	#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead ~~<BR>~~ If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]		#Do not create new keys for convenience. Existing keys must be reused where ever possible. Good support is doing the right thing for the long-term success of the system. Refer to [[Authorisation_File#Tasks_and_Locks\| Tasks and Locks]]
			#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead. If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]
	#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.		#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.
	#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.		#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.

Priyanka: /* Rules for Customising the Authorisation Table */

2017-06-05T07:12:23Z

Rules for Customising the Authorisation Table

← Older revision		Revision as of 07:12, 5 June 2017
Line 206:		Line 206:

	#Get approval from higher authority when customising Authorisation file or granting authorisation to all "ACCESS" tasks. Refer link [http://techwiki.neosys.com/index.php/Procedures#Handling_Requests_that_require_Approval_from_Higher_Authority Handling Requests that require Approval from Higher Authority]		#Get approval from higher authority when customising Authorisation file or granting authorisation to all "ACCESS" tasks. Refer link [http://techwiki.neosys.com/index.php/Procedures#Handling_Requests_that_require_Approval_from_Higher_Authority Handling Requests that require Approval from Higher Authority]
	#When creating a new department, use only standard department names already in use in NEOSYS like MEDIA/MEDIA2/MEDIA3 or CLIENT SERVICE1/CLIENT SERVICE2 etc. Refer to the initial dataset (STARTUP1) for standard department names. You must NOT use double digit numbering as it says nothing about the level or type of seniority. You must NOT use non-standard group names like "MEDIA A" or "MEDIA COMPANY A" or "LINE HEADS" etc as this will create problems especially for Timesheet users (For more information, see [~~http://userwiki.neosys.com/index.php/~~Setting_up_and_Configuring_NEOSYS_Timesheets_System#Activities_already_setup_in_NEOSYS_for_Timesheets Setting up Activities for Timesheets]).		#When creating a new department, use only standard department names already in use in NEOSYS like MEDIA/MEDIA2/MEDIA3 or CLIENT SERVICE1/CLIENT SERVICE2 etc. Refer to the initial dataset (STARTUP1) for standard department names. You must NOT use double digit numbering as it says nothing about the level or type of seniority. You must NOT use non-standard group names like "MEDIA A" or "MEDIA COMPANY A" or "LINE HEADS" etc as this will create problems especially for Timesheet users (For more information, see [[Setting_up_and_Configuring_NEOSYS_Timesheets_System#Activities_already_setup_in_NEOSYS_for_Timesheets\| Setting up Activities for Timesheets]]).
	#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [~~http://userwiki.neosys.com/index.php/~~Authorisation_File#~~How_to_set_up_user_groups_in_Authorisation_File_for_multiple_companies_in_same_dataset~~ below section for more information on this])		#If separate departments are present for each company in the dataset, the company name of the department should be entered as the User Name of the Department id. This is done so that it is easy to identify which company the department belong to, at one quick glance. (See [[Authorisation_File#How_to_set_up_departments_or_user_groups_in_Authorisation_File_for_multiple_companies_in_the_same_dataset\| below section for more information on this]])
	#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.		#Other than the above case, department names/levels need not have any username specified as these are not real users. Also, you should not specify an email address on the same, as these department names/levels are only to identify the user groups. You may log in using these for testing purposes.
	#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead <BR> If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations.		#Do not assign keys to individual users. Assign them to a group “user” i.e. Department instead <BR> If you feel the need to assign keys to a user, feel free to insert a new group user under them and assign the keys to that group user. This will enable us to manage the authorisation table i.e. add/delete users based on what Department they belong to, so that they get all required authorisations. Also refer to [[Authorisation_File#.E2.80.9CPer_User.E2.80.9D_Authorisations\| Per user Authorisation]]
	#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.		#If one or more members of a group or subgroup need an authorisation that other users in the same group MUST not have then you can split the group into two subgroups where one subgroup is "senior" to the other. eg MANAGEMENT could become SENIOR MANAGEMENT and MANAGEMENT subgroup by inserting a "group user" in the middle of the group and moving the users up and down until they are in the right new subgroup.
	#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.		#Do not create user IDs like AUDITOR or MANAGMENT and grant special access to such users like read-only access this breaks all security rules. Only create accounts with names and email addresses WITH NO EXCEPTIONS unless agreed by NEOSYS management.
Line 215:		Line 215:
	====How to set up departments or user groups in Authorisation File for multiple companies in the same dataset====		====How to set up departments or user groups in Authorisation File for multiple companies in the same dataset====

	(Note: This section only talks about how to set up USER GROUPS. For setting up TASKS/LOCKS, see [~~http://userwiki.neosys.com/index.php/~~Authorisation_File#Tasks_and_Locks Tasks and Locks])		(Note: This section only talks about how to set up USER GROUPS. For setting up TASKS/LOCKS, see [[Authorisation_File#Tasks_and_Locks\| Tasks and Locks]])

	Let's say there are two companies: company A (Art Company) and company B (Bat Company).		Let's say there are two companies: company A (Art Company) and company B (Bat Company).