Best way to model staff directory content

(Birdg) #1

Hi,

 

We are using 4.16.0 and just beginning to learn what Matrix is capable of.

 

We are considering building a staff directory in Matrix for our intranet. It seems to me that we could model the content in several different ways.

 

We need staff members to belong to one or more teams (since staff often have multiple roles or responsibilities). Teams and staff members will have pages on the intranet site but also potentially on the website as well (which makes me wonder whether Data Records might be better than Standard Pages with metadata). Team pages will need to list their staff members. Staff pages will need links back to their respective Team page(s).

 

We don't want to do hacky field values like comma-separated asset IDs if they can be avoided.

 

Option 1: Staff assets have a Related Asset metadata field which directly links to a Team asset (but Related Asset metadata fields can only take one value so this wouldn't work for people with multiple teams)

 

Option 2: Staff and Team assets are both tagged with the same Thesaurus terms (but it's not clear whether things like the link from a Staff member page to the Team page could be derived from this)

 

Option 3: Staff assets could be linked under several Team assets (but this can't be done if Teams are Data Records)

 

I'd like to understand how this kind of functionality is typically achieved. I know every situation is different but presumably there are recommended ways of doing these "one-to-many" or "many-to-many" relationships within Matrix.

 

Any advice would be most appreciated.

 

:)

 

Graham

(Nic Hubbard) #2

I would group your Staff into User Group Assets, then create the Staff Members as User assets. Then you can apply a paint layout to those assets to print however you want them to look on the front end.

(Bart Banda) #3

It depends on the size of your organisation and how many staff members and teams there will be. If there are less than 30 or so teams and less than 100 staff, you are probably best of by linking the staff member assets under each team asset. This will also mean that each staff member asset has multiple web paths applied to it as well, not sure if that will be an issue for you though. But to get around that you could always have the teams as folders outside the site asset somewhere or remove the web paths from the parent team asset so that no matter how many locations a staff member is in, they only have 1 URL. 

 

Another option would be metadata. Each team could be a metadata checkbox value and you could simply just check the teams that a staff asset is part of of the metadata screen, and then use a search asset to dynamically list the staff members by searching on that metadata field. 

 

If the staff assets are all located in one folder, and you link to them from different team pages, the link from a team page to a staff asset could just be to the same URL as the team page or a dynamic global standard page but with a URL parameter that will print info of the staff member using something like ?staff_asset_id=1234&team_asset_id=1234. You can then print dynamic values of both using the %globals_get_staff_asset_id^as_asset:asset_whatever% and %globals_get_team_asset_id^as_asset:asset_whatever%.

 

Hope that helps and gives you some ideas. 

(Birdg) #4

Hi,

 

thanks for the replies. We have over 6,000 staff and many, many teams.

 

RE: Nic's idea - I'm not sure I like that idea because then team and staff pages are conflated with user permissions

 

RE: a checkbox/select - this doesn't seem like a good idea on the scale we would require and that's what led me to the Thesaurus option.

 

The querystring idea sounds like it might work. Is it possible to do these as rewrites so there is no visible querystring for the user? Or is that outside Squiz's capabilities?

 

I notice that neither of you recommended using Thesaurus functionality. Is there a reason for that?

 

Graham

(Bart Banda) #5

The querystring idea sounds like it might work. Is it possible to do these as rewrites so there is no visible querystring for the user? Or is that outside Squiz's capabilities?

 

You would need to do it with apache rewrite rules outside of the squiz platform. 

 

Also, I think using thesaurus terms over metadata might require a bigger performance hit depending on how you filter and apply them. But not sure

 

You could probably try both as a proof of concept on a small number of teams and staff and see which one would work best for you. 

(Joel Porgand) #6

 

thanks for the replies. We have over 6,000 staff and many, many teams.

 

 

Don't build a database of that size within matrix, you're just setting yourself up for pain. Build it in a real database & pull it in with db datasources. You probably already have most of the information you require available to you anyway - no sense duplicating it, you'll just create a maintenance nightmare. 

(Anthony) #7

Random thought... does your organisation have the users already set up in Active Directory or in some other LDAP compliant system? I've not tried it personally but I know but Squiz has a way of synchronising to LDAP so maybe all the users and groups (=teams) could be populated / managed automatically?

(Birdg) #8

Hi,

 

Thanks for the replies. We do have some basic info in LDAP but it's not our intention to put detailed staff profile info in there. Whether we use something external for the basic team structure or not, I think we will need content for every staff member in Matrix.

 

JP - why shouldn't we build it in Matrix? I would have thought an enterprise CMS such as Matrix would handle that without even breaking a sweat. Could you explain further?

 

Thanks again,

 

Graham

(Nic Hubbard) #9

JP - why shouldn't we build it in Matrix? I would have thought an enterprise CMS such as Matrix would handle that without even breaking a sweat. Could you explain further?

 

I think he meant, if you already have these in a DB elsewhere, use that. Because if someone is added or removed from the database, you would have to make the change in Matrix also if you are using normal assets. If you used a DB Data Source it would pull directly from your DB.

 

But, the downside of this is that you cannot assign things like metadata or give the users content.

(Birdg) #10

Ah, OK, thanks. Makes sense. I was worried for a second there. :slight_smile:

(Joel Porgand) #11

 

I think he meant, if you already have these in a DB elsewhere, use that. Because if someone is added or removed from the database, you would have to make the change in Matrix also if you are using normal assets. If you used a DB Data Source it would pull directly from your DB.

 

But, the downside of this is that you cannot assign things like metadata or give the users content.

 

Mostly this.

 

Provided it's all cacheable performance shouldn't be much of an issue.