How to add an Employee Directory? [was How to merge features into Modx]

Couldn’t come up with a good subject title for this...

I have a client who wants me to plug his site into modx. He also wants an employee directory (A to Z including phone extensions) built into the cms. I guess I could set it up using hidden pages, but I’m not sure how to add tables to the modx db for the employee dirctory. Can anyone send me in the right direction?

Is there some reason why employee records cant be normal documents with tv’s to get all necessary fields?

Maybe the reason is that this directory already exists and no one wants to enter the data again?
In this case you could create the required TVs and fill them using an import directly in the DB-backend (like MyPHPAdmin) or create an external table and reference it using keys in the TV.

Quote from: doze at Jul 17, 2006, 09:05 PM

Is there some reason why employee records cant be normal documents with tv’s to get all necessary fields?

In all honesty I still don’t know how to use TVs. Can some guide through how I’d do this? The directory hasn’t been created yet, so I’m starting from scratch.

Hi. I’ve changed the subject; often its easier to figure out the subject after you’ve read the first post.

Anyway. The client wants the employee directory in the CMS so they can add the employees themselves, is that right?
Will you be giving them Manager access, or will you need to be able to add/amend/remove employees from the frontend?

Does this need to look snazzy, or is it OK if it looks a lot like a document editor with some extra fields stuck on the bottom?

If you go down the document route, the two TVs you need to add are Surname and Extension. Possibly also Job Title.
In brief, you add these Template Variables to the template and you would then have them available to the document, and to Ditto etc for sorting and display purposes.

The other route to consider would be adding fields to the user table and giving everyone a web account. Then you’d just need someone to write a Web User List snippet.

Personally, I’d go for a new database table.

That said, how many employees does he have? If it is 20ish, you might as well just have a single page that someone edits!

Quote from: PaulGregory at Jul 17, 2006, 10:47 PM

The other route to consider would be adding fields to the user table and giving everyone a web account. Then you’d just need someone to write a Web User List snippet.

You don’t need to add anything to the user table, you can use the user_settings table for any extra data.

Quote from: sottwell at Jul 18, 2006, 01:22 AM

You don’t need to add anything to the user table, you can use the user_settings table for any extra data.

And how would one do that?

That table has three columns, user (user ID), setting_name (first_name) and setting_value (’Susan’).

You want the first name of user 48? SELECT setting_value FROM modx_user_settings WHERE user = 48 AND setting_name = ’first_name’.

You want to list everybody by their last name? SELECT user, setting_value FROM modx_user_settings WHERE setting_name = ’last_name’ ORDER BY setting_name

I am not an experienced MODx-user, but I tried nearly the same.
I have a database for an organization which is to be used outside from MODx too.

So I created about 20 tables within MODx database.
The advantage is - you have your business logic separated from MODx and you can use MySQL to check key dependencies.
Creating the tables within MODx database has the advantage too that you don’t have to care about login because MODx does it for you.
And for changing from outside MODx I created some users in MySQL.

I wrote my own php-classes in separate files, stored in separate folders - that’s all make it easier to keep the business and project logic separated from the MODx displaying logic and to find your own files faster in the directory tree.

I wrote some snippets to access my files and classes and now the most time I use Zend Editor to edit the files

snippet to get my own pathes:


other snippets may use this snippet by the code

Quote from: sottwell at Jul 18, 2006, 01:22 AM

Quote from: PaulGregory at Jul 17, 2006, 10:47 PM

The other route to consider would be adding fields to the user table and giving everyone a web account. Then you’d just need someone to write a Web User List snippet.

You don’t need to add anything to the user table, you can use the user_settings table for any extra data.

Or web_user_settings, as appropriate.

Quote from: sottwell at Jul 18, 2006, 03:50 AM

That table has three columns, user (user ID), setting_name (first_name) and setting_value (’Susan’).

You want the first name of user 48? SELECT setting_value FROM modx_user_settings WHERE user = 48 AND setting_name = ’first_name’.

You want to list everybody by their last name? SELECT user, setting_value FROM modx_user_settings WHERE setting_name = ’last_name’ ORDER BY setting_name

I rather think that the question was how you *add* the data, rather than how you get it out.

But yes, it is true that user_settings can be used to store user information, and the table is worth considering for a number of purposes. (Although that needs to be ORDER BY setting_value).

However, I do not think using user_settings is the best way for an Employee Directory.

1) It is counterintuitive.
The user’s phone number is already stored in the "phone" field of user_attributes / web_user_attributes. As is "fullname", "email, "mobilephone" etc. It appears to me that _settings are more "optional" settings, like "which days of the week can they access", etc. Every (human) user has a first name and a last name. Unless Madonna is on the payroll. Even so, it’s more likely than having a mobile phone. So adding 2 fields (firstname & lastname) to _attributes makes sense.

2) There is little benefit to the Manager in this instance.
Given that one would have to hack "mutate_user.dynamic.action.php" to add the fields/quasi-fields to either tab, there’s no benefit there. (If there was an User Setting Editor allowing you to add settings as if they were template variables, this reason would be void).

3) There is little benefit to Any Other Script in this instance.
It is obviously easier to add/update "fullname", "first_name", "last_name" and "phone" data at the same time. (If there was an API feature for checking for the existence of a user_setting entry and either adding one or amending the existing one, this reason would be void).

4) It is harder to sort properly by last_name, first_name if both are in the same table.
Compare
with
Now try adding the phone number, or worse another _settings value.

5) Before anyone says it, any "future db versions do it more like _settings than _attributes" argument doesn’t wash.
Any major change of data model would need to convert the _attributes anyway.

So whilst I welcome being reminded of the _settings table, my opinion is that it is better to add fields to _attributes.

Field for sorting
One thing worth considering in place of "firstname" / "lastname" is "SortBy".
That way "Bruce Forsyth" would be "Forsyth Bruce", "Scott McQueen" would be "MacQueen Scott" etc. That may well be better if you have lots of names where the traditional human sorting is different from what would be achieved by Lastname, Firstname sort (eg cultural differences). It is also a field used in Outlook, which may well be the source of the employee data.