Member Types

Member Types define the data-entry form for each kind of member. They decide which fields appear when adding a member, which fields are required, which values must be unique, and which custom fields the library wants to maintain.

Use Member Types for data shape. Use Membership Plans for borrowing, expiry, fee, and access policy.

Screenshot To Add

Add screenshots of the Member Types list, template selector, Data Fields tab, and Custom tab.

Templates

Libcodesk supplies ten editable starter types:

• Student.
• Teacher / Faculty.
• Child Member.
• Corporate Member.
• Public Member.
• Researcher.
• Staff / Employee.
• Senior Member.
• Family Member.
• Visitor / Guest.
• Blank.

The ten named types are installed only when their template key, name, and code do not conflict with existing library data. A conflict skips only that starter type; it never replaces an existing record. Blank is an additional builder rather than a member type. Admins can edit a supplied type, mark it inactive to hide it from new-member selection, or add entirely new types. Later software updates do not overwrite those choices.

Untouched starter names are displayed in the active software language. Libcodesk identifies them by their stable template key rather than by translated text. If an admin renames a starter type, that custom name is shown exactly as saved and is not translated automatically.

Core Field Rules

• Profile Image is a fixed common field and can be made required if the organization needs member photos.
• Member ID is required and unique, but it is the visible library identifier rather than a login replacement.
• Name and Email are required.
• Phone and Date of Birth can be included as common data.
• Gender uses predefined options and should default to a respectful neutral value where the form does not require a choice.
• Custom fields can be text, number, date, email, phone, single select option, multi select options, checkbox, image, or multiline text.

Data Fields Tab

Use Data Fields to decide which fields appear in Add/Edit Member. Templates preselect useful fields, but the admin can still tune the list.

Control	What It Means
Enabled/disabled	Whether the field appears in the member form. Fixed fields such as Profile Image, Member ID, Name, and Email remain available for identity consistency.
Required	Staff must complete the field before saving a member. Use this carefully.
Unique	The value must not duplicate another member. This is useful for Student ID, Employee ID, RFID Tag, ID proof number, and similar identifiers.
Move up/down	Changes the order of editable fields in the member form. Fixed identity fields keep their required position.

Do not make every useful field required. A field should be required only when staff can reliably collect it for every member of that type.

Saving And Delete Safety

The save button becomes available only after something changes. While Libcodesk saves, the popup keeps the current values visible and shows a working state so staff know the request is in progress.

Deleting a Member Type can affect member records that use that type. Libcodesk asks staff to type the Member Type name before deletion continues. If the type is still needed or cannot be removed, the page keeps the record visible and shows the reason.

Default Password

Member Types can store a default one-time password behavior for new member logins. When a member is created, the add member form can use the type default unless the librarian enters an override password.

The guide and UI should never expose stored default passwords as plain text after saving. Staff may override the temporary password at member creation when the workflow allows it.

Do And Don'ts

Do

• Start from the closest template and then remove fields the library will not maintain.
• Mark Student ID, Employee ID, RFID Tag, ID proof number, or similar fields unique when duplicates would cause real problems.
• Keep required fields limited to values staff can reliably collect.

Don't

• Don't use a custom field for sensitive information unless the organization has a clear policy.
• Don't make too many fields mandatory; this slows down circulation desk work.
• Don't use Member Types to control borrowing limits or fees.

FAQ

What is the difference between a Member Type and a Membership Plan?

Member Type controls the form fields collected for a member. Membership Plan controls validity, borrowing, fees, renewal, and access policy.

Can I add custom fields?

Yes. Use the Custom tab to add extra fields such as hostel, transport route, department group, or any library-specific information.

Can a field be required?

Yes. Required fields are marked in the add/edit member form and must be filled before saving.

Can I change field order?

Yes. Defined fields can be moved where allowed. Fixed identity fields stay in their required position so forms remain predictable.

Can one library have several member types?

Yes. Schools may use Student and Teacher / Faculty. Public libraries may use Public Member, Child Member, and Corporate Member.