nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Moving to LiveSite: End-user change plan?

RichDiaz

Changing an end-users development interface can be met with resistance and/or confusion.

Are there any training guides/plans/posts for this transition in place already?

Another question: Is there a way to have LiveSite installed but only give LiveSite access to select groups of end-users. In other words, can I hide the LiveSite functionality/interfaces from targeted end user groups? (i.e. they don’t see anything 'LiveSite')

Thank you,

Find more posts tagged with

Comments

wscott

I'm not sure what you mean by "an end-users development interface." Do you mean transitioning page authors onto TeamSite? Or transitioning them from using DCRs (forms) and presentation templates to generate HTML? I'm not aware of any specific transition documents, although there may be a section about it in the user guides.

For your second question, I don't think there's a way to hide LiveSite functionality on a per-user basis, but you can restrict functionality by role, so you could deny certain roles from accessing any LiveSite functions. You can also restrict user groups per branch and workarea, so you could specify that all LiveSite dev occurs in certain branches, and deny permission to those branches to any non-LiveSite users.

RichDiaz

Or transitioning them from using DCRs (forms) and presentation templates to generate HTML?

Correct. Transitioning them to LiveSite from using DCRs (forms) and presentation templates to generate HTML.

You can also restrict user groups per branch and workarea, so you could specify that all LiveSite dev occurs in certain branches, and deny permission to those branches to any non-LiveSite users.

Ok, so would this work? At the start we could restrict everyone from using LiveSite. Later (after training) certain groups would get access to 'new LiveSite folders' to created/modify their current DCR built site to LiveSite built site. Is there a better way to do this staged roll-out?

I think TeamSite 6.7 supports custom groups but we can't wait for it.

Thanks!

wscott

I think that would work. You would need to have a special LiveSite Users group. Make sure that the branch /livesite/main/component and /livesite/main/template are restricted to this group. Users within any normal branch would still be able to access LiveSite functions, like New Site and New Page, but they will not have any components or templates available to add to the new site or page.

In theory you could create a "sites" directory inside of all those branches and restrict it to the LiveSite Users group as well -- when someone tries to create New Site they will get an error since they can't write to that directory. However, I have not actually tried that (you would need to play around with it a little to see what works). Alternatively, you could just tell people not to utilize the New Site and New Page feature.

You might also be able to do something with a custom workflow -- reject any submissions of /sites/* from users who are not part of the LiveSite Users group.

If you want to get really advanced, you could use UITK customizations to override the New Site and New Page command to check for particular user permissions. This would involve subclassing the LiveSite classes responsible for these commands to perform the check, and if successful, call the super method. While customizing the UITK is supported, I don't think subclassing the LiveSite classes is supported, so be prepared for a little extra testing/experimentation effort if you go that route.

RichDiaz

You would need to have a special LiveSite Users group.

If you want to get really advanced, you could use UITK customizations to override the New Site and New Page command to check for particular user permissions.

Special LiveSite groups and the UITK is a great idea for this control.

Maybe we could roll out LiveSite to production but completely modify the interface BACK to default TeamSite 6.5 interface? This would allow us to roll LiveSite out the specific departments (groups) defined by a training schedule.

We’ll start messing around with these ideas on our Research and Development Servers and post updates as we go along.

Thanks again!