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

User constraint

System

Does anyone know how to constrain the use of a workflow to a UNIX group, instead of the four TeamSite role files listed in WorkflowBuilder when sending to the server?

Find more posts tagged with

Comments

Migrateduser

There is no option to restrict a workflow to a group or groups in the product at present. There is an open feature request (24966) to add this option to the available_templates.cfg.

However, you can restrict the use of a workflow to a branch or branches.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

I wonder where feature requests go, other than in the box of excuses given to decoy answers to questions. Wouldn't it be nice to know what feature requests Interwoven deems worthy and which are left in the pile to simply be used as excuses to use when they need them.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Migrateduser

Ha, ha. Very funny.

The reason that I cited the feature request -- including the number -- was so that customers who feel strongly about the feature can have their names associated with the request. This is one of the ways in which product management prioritizes the requests.

We currently have over 1800 open feature requests. Clearly we are not going to implement all of these features, nor are all of them necessarily desirable by most of our users. But we do keep a record of the requests, and they are consulted when planning a product release.

Only about one sixth of the feature requests have been associated with any customer, so this significantly increases their priority. We do reject many feature requests, but rarely when the request comes from a customer.

Brinko Kobrin
Interwoven Staff Engineer

Migrateduser

Thanks, Brinko, but you just basically said nothing useful for any customer who would want to know what feature requests are deemed worthy or being implemented. Telling us that there are things called feature requests and that some get implemented while others do not is nothing for us to get very excited about. How about a way for all your customers to see all 1800 feature requests so that we have a decent opportunity to voice which ones we might be interested in? How about showing us which ones are flagged for being implemented? Something...anything. Every so often telling us that something is a feature request is not really helping much.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

[*personal response - not intended as an official response *]

Dave,

Please show me some examples of commercial software products where the list of feature requests that customers have filed are visible to the customers to vote on.

To the best of my knowledge, this just isn't the way commercial development gets done (i.e. is there some place I can look at a list of feature requests for Microsoft Word, Eudora, Oracle, Cisco, DreamWeaver, Acrobat, etc.?)

The fact that we *do* inform you that there is a feature request open and provide a reference number that you can use when contacting Support to add your name to the list of interested parties is, I think, rather unique in this regard - as in being more than what most other companies provide. Is it everything you want - no - but little in life is.

If you were given the choice between us providing the current level of information we provide, or providing no information about feature requests that have been submitted - which would you rather we do?

My experience with most other commercial vendors is that they'll let you send in email requests for features but pretty much guaratee that you will NOT receive any confirmation of follow-up email regarding such a request unless, for some reason, they decide to follow-up on the request with you (which I think is pretty rare).

Free-ware products tend to be much more open about such things - largely because they want to get other folks to pitch-in and help implement functionality for the "community".

Interwoven is not a free-ware vendor - we're interested in getting feedback from our users and try to incorporate such feedback into future development efforts. The number of customers interested in a specific feature is *one* part of the equation that goes into scheduling resources for such development, and our telling you what the feature request id is allows you to participate in that part of the process.

[* again - this is NOT an official response of Interwoven - just my own personal response *]

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Sorry Adam, I just don't buy it. You can't have it both ways. You tease your customers with these things called "feature requests" as if they mean something and are valid responses to peoples concerns. You claim Interwoven is unique in that you "allow" us to know that some of these feature requests exist, yet only when it is convenient to brush off a specific request or question. You use them when it is convenient but when asked specifically about them you turn the other cheek and say you're doing us a big favor? I don't see it. If they are things we are not entitled to know about, then don't bring them up. All they are are a carrot on the end of a virtual stick. But if you do bring them up, be prepared to discuss them in detail. Maybe if you sold your products for $79.99 you could compare yourself to Microsift. All I'm saying is that if the feature requests that the most companies want are the ones that rise to the top of the list, how are cuatomers supposed to know what features they could get if they can't see the list? If you're willing to advertise certain feature requests, why not advertise them all? What's the point in keeping them secret? You're obviousl willing to talk about them when it's convenient for you.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Adam Stoller

(Apologies to all those who don't like these seemingly public/private exchages - this is again my personal response and not intended to be taken as the opinion of Interwoven)

Sorry Adam, I just don't buy it.

Sorry Dave, I didn't think I was selling it

You can't have it both ways.

I didn't realize that I was trying to have it both ways

You tease your customers with these things called "feature requests" as if they mean something and are valid responses to peoples concerns.

It was never my intent, nor do I believe it was anyone else's intent to tease anyone regarding these things that are called "feature requests" - because that are requests for features. I'm not sure what you mean by the last part of the above sentence. Are we talking concerns about an actual problem with the product, which is generally called a "bug"; or are we talking about things that people would like to see added to the product, which is generally called a "feature" ? How is informing someone that a request has been filed for a specific feature that they have asked about and giving them the ability to register their interest in that feature not meaningful? How is it not a valid response?

You claim Interwoven is unique in that you "allow" us to know that some of these feature requests exist, yet only when it is convenient to brush off a specific request or question.

Actually I said "rather unique" not just "unique" - there is a difference. My personal experience dealing with vendors of products that I use regularly as a consumer, is that I don't even get that much of a response - but more often than not just a little form-email that says "thank you for your comments".

I take some offense at the phrasing and the suggestion that we provide this information because it is "convenient to brush off a specific request or question" - if we wanted to brush off a request or question we wouldn't bother responding at all.

As employees of the company, we have the opportunity to register requests for all sorts of features and functionality - but requests backed by customers tend to get much more attention because they are backed by customer desire. So our informing you of these requests to enable you to register your interest in them and thus drive up the attention that they receive doesn't seem to be a "brush-off" to me - but obviously I'm biased.

You use them when it is convenient but when asked specifically about them you turn the other cheek and say you're doing us a big favor? I don't see it.

Why does it always have to be about "convenience" for you? Frankly, we'd love never to have to log a feature request because the product would do everything that everyone wanted it to do straight out of the box (seen some of those IBM ads on TV lately?) - if "convenience" comes into at all, it comes in because we're trying to make it convenient for you to register interest in a specific request - rather than opening up tons of duplicate requests that might otherwise get missed (can't see the forest for the trees).

What cheek are we turning? I'm not sure I ever said we were doing you a "big favor". Someone asked about the ability to do X. We said it cannot be done (or done easily) in the current system but it sounds like a good idea for a feature request or that we found a similar feature request on file, and you can follow a very simple procedure for registering your interest in it. If the request is something for which a work-around exists - more often that not (as far as I know) we provide that information too.

If they are things we are not entitled to know about, then don't bring them up. All they are are a carrot on the end of a virtual stick. But if you do bring them up, be prepared to discuss them in detail.

You seem to have a hard time distinguishing the difference between a desire for functionality and the method used for implementing it. The first is something that we can share because it is generic in nature: Someone wants the ability to do X. The latter is something we generally cannot discuss.

The level of detail we can discuss varies based upon the subject matter of the request, at the very least. If you want us to provide a better description of the feature request - ask. If you want us to tell you exactly how the feature request will be implemented - be prepared to be unsatisfied with the response.

You are more than free to suggest strategies for implementation, but it is unlikely that we will ever be able to actually inform you of exactly how something will be implemented, at least not at the levels that you like to delve in. This is, again, a distinction usually found between free-ware and commercial products.

Maybe if you sold your products for $79.99 you could compare yourself to Microsift.

I'm not looking to compare Interwoven specifically to any other company - I provided a range of products from a range of companies that went anywhere from off-the-shelf to enterprise-system and asked if you had any better experience getting information about logged feature requests for those products. Since you didn't response with an example from one of those other companies, I assume the answer is "no".

All I'm saying is that if the feature requests that the most companies want are the ones that rise to the top of the list, how are cuatomers supposed to know what features they could get if they can't see the list? If you're willing to advertise certain feature requests, why not advertise them all? What's the point in keeping them secret?

Finally, a question raised without malice! And a question I've asked before at other companies that I've worked for - and the answer is usually a combination of several factors:

Audience. Similar to the above, but with a different slant. Some feature requests are there purely for internal tracking purposes. Some are requests based on internal testing of products that haven't been released. There is currently no provision in the system we use for determining the appropriate audience for a given feature request nor the restraints on who can file such requests to make sure that in the future they are properly classified.
Visibility. Again, similar to the above. A feature request and bug tracking system contains not only the initial description of the request or problem, but lots of information regarding who filed it, who's reviewing it, who's assigned to it, internal dialogue regarding it, etc. That information (regardless of the "audience" for the request description) is never intended to be seen outside the company.
Open vs. Naked. Okay, that's probably not a very politically correct nor possibly accurate phrasing - but the point I'm trying to get across is that it is one thing to provide information on a registered request when someone's asked specifically about it, and another thing to lay all such requests out in the open for anyone to look at. The latter, while offering potential fodder for competitors, is also far to easily misinterpreted as defects rather than requests for additional features and/or functionality. True, sometimes there is a fine-line between the two terms, but that's a different matter (One man's ceiling is another man's floor -Paul Simon) Or put another way, how would you like to be required to put a complete list of every one of your own personal faults and imperfections out in public, and be required to constantly maintain it whenever someone finds something else about you that could stand improving?

There are probably other factors too. It's a difficult tight-rope to walk - you want to provide information, but you can only provide so much.

Are they a secret? Not in the traditional sense - but yes, they probably are to some degree. Thus far Interwoven Management has not told us that we cannot refer to these items in the forums, and so we do when it seems appropriate (perhaps that's what you mean by convenience - but it's a different word with a different definition).

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

Brinko claimed that feature requests are prioritized by the amount of companies who request them. No one but Interwoven brings up specific feature requests in DevNet. If customers have any ability whatsoever to have an effect on which feature requests get Interwoven's attention, Interwoven should make all of them available to their customers. Interwoven mentions some. Why not all? Makes no sense to me. If you can't get into any of the troubles you mentioned with the ones you taunt us with, why not mention them all - at least on the support site? I'm not going to sit here arguing semantics with you. It's Interwoven's own people who have set the precedent. I would love to know what those 1800 feature requests are so I could voice my opinions on those we could try to get inplemented.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com