I have an authors field, computed, multi-value with the formula
@Trim(@Unique(“[Admin]”:MinuteTaker))
MinuteTaker is a field on the doc where people select a member of staff (creators generally have the admin role of course).
The lookup is from the address book and when a person is selected and the doc saved the authors field will have the value (for example):
[Admin]
CN=Fred Bloggs/O=Company
At this point if Fred Bloggs (who has author access to the db) tries to edit the document he can’t.
I have an input translation on the Minutetaker field to CN the name (so it appears as Fred Bloggs rather than Fredd Bloggs/Company).
If I save the doc again (so the translation has now kicked in), the authors field now contains:
[Admin]
Fred Bloggs
Fred can now edit the document
Odd, or am I missing something?
Subject: input trans
if you have an input translation you should not have to save the document again in order for that to “kick in”, as you explained. However, it’s still a bit troubling why the user cannot edit the doc when his full hierarchical name is displayed in the field, as this is the preferred format. Have you examined the ID the user is logged in with to make sure the name within it matches exactly what is displayed in the authors field?
Also, try removing the input translation all together, create a doc, see if he can edit it, if not then open and resave the doc, can he edit it now? the name in the authors field should still be the same as before you resaved it. just trying to figure out what this extra resave is doing and why it’s necessary.
How is the original document created?
Subject: input trans
The input translation is happening on first save, but I think it’s because the computed field is above that field maybe that it’s happening this way. I might move it to check that (it’s a hidden field obv so no problem moving it around).
As you say though, the more concerning thing is the authors field not working as expected
The original doc is created in script, but adding the new person to the MinuteTaker field is done manually.
I will try your suggestion, although maybe not for a couple of days so will post back if I find anything out. If not I may submit to IBM to see if it is a bug, there shouldn’t be any problem with the user account and the exact hierarchical name as we only have one domain and no OUs
Thanks
Subject: Re: “The original doc is created in script”
Since the document is created in script, as you are writing: How do you create the Authors item on it - using doc.ComputeWithForm() or doc.ReplaceItemValue()? If the latter is true, make sure you set the item’s IsAuthors property to True.
Subject: authors
The field is definitely an authors field, and the problem occurs after a manual save in the ui, so the script isn’t the issue I don’t believe
Cheers
Subject: Pass to template dev to have a look
Subject: Who?
What do you mean by template dev. I’m the dev at our company or are you suggesting submitting to IBM?
Subject: I believe he meant that he forwarded to a developer at IBM
Subject: Thanks
Doesn’t really answer my question though - does anyone know whether this is actually a bug, or I’m doing something wrong?
Subject: Try this…
Try doing the lookup in another field then have the formula in that field set the authors field using the formula @Name([Abbreviate]; ) instead of just selecting the common name. This will give author access based on the users hierarchical name instead of just common name. This will avoid collisions where you might have two Joe Smiths who are members of different OU’s or O’s.
Also, if you need for display purposes a field with just the common name then create a computed for display field (again separate from the author field) to display that value.
Subject: thanks but…
The author field doesn’t seem to be working when the full hierarchical name is present, only when it gets changed to the common name.
The lookup brings down the abbreviated name (Fred Bloggs/O), and only when that gets translated into the common name does the author field start working
Seems backward to me, always possible it’s a bug