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; } } }

Unlocking based on role

lizn

I working on customization of 6.1 and can't find a solution to unlocking files based on roles. I want everyone to be able to have the option to unlock files. However only authors and editors can unlock their locked files, and admin and masters can unlock all locked files. We currently have this on 5.5.2, but want to put the same functionality into 6.1. Any suggestions?

Find more posts tagged with

Comments

Migrateduser

Sounds pretty dangerous, but have you considered custom menu item? One option I would build in if it's still not provided by the vendor - when a DCR is unlocked, unlock the output files as well. When an output file is unlocked, unlock the DCR. I think that's more consistent with user expectations (it doesn't really make sense to unlock one without unlocking the other).

Edited by john on 07/27/04 09:09 AM (server time).

Dwayne

In reply to:

One option I would build in if it's still not provided by the vendor - when a DCR is unlocked, unlock the output files as well. When an output file is unlocked, unlock the DCR

I would tend to disagree, unless the architecture of your system is such that there is always a one-to-one relationship between DCRs and generated pages. It is certainly possible to generate two separate output files from one DCR. If one generated page is unlocked, should unlocking the DCR also unlock any other generated pages?

That's also not an easy thing to do in TeamSite. Finding the DCR from a generated page is easy. Finding all generated pages is not (unless you're using DAS or something equvalent).

Migrateduser

Right, every implementation is different, but this kind of functionality would be a nice option for at least 90% of the projects I've been involved with. Content administrators use the system very differently than developers. Most projects seem to generate one output file per DCR.

I feel that if any of the output files or the DCR is locked it should behave as if the selected file is locked, which means report the lock owner through the UI so the user can make manual contact. In this case they want to override the existing lock, which is dangerous but can be convenient. The lock on the DCR is all that matters though, since any changes the second user is making to an output file without having a lock on and editing on the DCR will be lost anyway.

Toitally agree that it's a pain to find the files generated from a DCR, have been complaining about this for years. One potential workaround - on generate, set/update one or more EAs on the DCR listing the generated pages. Since EA has length limit, use multiple EAs if you generate a lot of files from one DCR. You can do this really easily by wrapping iwpt_compile.ipl or putting a modularized function call in each template. Be sure not to include the zz_ files generated by preview. You can also use this to determine what to attach to a job when a DCR is submitted for a new job. The system should be rules about what file(s) can be generated from what DCR(s).

Edited by john on 07/27/04 09:27 AM (server time).

Dwayne

In reply to:

Right, every implementation is different, but this kind of functionality would be a nice option for at least 90% of the projects I've been involved with. Content administrators use the system very differently than developers. Most projects seem to generate one output file per DCR.

Agreed that this is a common usage pattern. However, I don't think that it's a pattern that Interwoven wants to push functionalty toward. One of the value props of templating is content reuse. This usage pattern tends to show that users aren't taking advantage of that. Of course, that could just be my cynicism talking.

In reply to:

Toitally agree that it's a pain to find the files generated from a DCR, have been complaining about this for years. One potential workaround - on generate, set/update one or more EAs on the DCR listing the generated pages

That's a good start. However, there are other issues that need to be addressed. What happens when a file is deleted, or, more importantly, renamed? You'd need to have triggers on those events to update the EAs on the owning DCR. And then there's the question of what to do if the DCR is deleted. But, then, that's an issue with OOTB templating anyway.

Migrateduser

> This usage pattern tends to show that users aren't taking advantage of that. Of course, that could just be my cynicism talking.

Agreed. I think TeamSite does not lend itself to or even suggest best practices for content reuse. I am also quite cynical. Still, templated file lock management logic could be an option built into iw.cfg. On the other issues, I've never really worked on an Interwoven system that well supported rename and delete (kindof the same thing) - generally manual effort, possibly by CMS administrator. I am interested in how other organizations are managing delete.

Thanks,

-John

lizn

I may have phrased the questions a little wrong, but the advice you all have offered is also now going to be considered. I'm more looking for ways an author can only unlock files the they had locked. in other words author 1 locks a file it can only be unlocked by author 1 or an admin/master, author 2 or an editor wouldn't be able too. We would also only be talking about unlocking just the DCR or generated files, not both at this time.

Migrateduser

You can put that logic to only allow unlock if user owns lock or has a specific role in the custom menu item, which can be exposed to all users. At least in 5.5.2 there is no way to remove the unlock item from the UI if a user has selected nothing, a directory, a file that is not locked or is locked to another user, etc. So if a user tries to unlock a file the logic prevents them from unlocking they get an error message.

I remember seeing documentation somewhere saying authors are not allowed to unlock, and someone mentioned writing a CMI for this could break licensing agreements, but that's ridiculous as having a CMS admin manage locks holds up the business process. I also think that this kind of thing should ship with the product.

Adam Stoller

http://www.quotient-inc.com

sumarryFiled.jpg