At the outset a Livelink system represents some vestiges of a File System like Unix or Dos.People having worked in that is probably familiar with the term U G O which stood for User,Group,Others.This is what you see in the std permission bit of an object on its ACL. Every object has one ,many times you set the container object right and let the inheritance trickle in.In many places if you set it right you can forget it.But if you install livelink Out of the Box and has no training or nobody to watch it over you are probably going to end up in rogue territory.This is because the user ‘Admin’ and ‘Default Group’ has very high permission bits set.Out of which the owner is a role,so if you start a folder where Admin did not willfully do the permissions set normalization and if you gave ‘Appu’ creation privileges for folder when ‘Appu’ creates objects he becomes owner who is very powerful and so on.Now this could be argued as not a big problem until it runs amok.So what a good permission model is Owner See,See Contents or Nothing,Group See,SC or Nothing and PA,S,SC or nothing.Now you will create administrative groups something simlilar to these discussions and you will be fine.
Always rely on proper groups that you can create and maintain in a directory service (AD is very common) and have those groups synchronized in.It is quite possible that HR systems release feeds into Directory services hence when users leave your organization they will go as well.There will be no permission problems because the real administrative group has overriding permissions that the owner based approach.Simple try it and you will be happy and 50 % of your help desk tickets will come down.
This is what one hears in OpenText engagements as “Community Modelling” well my next part will cover object truth tables as well.
Permissions bit use BitWise logic in FileSystems as well as livelink does recently a programmer told me he finds the awesome bitwise logic un understandable.I just thought wow where is the programming world heading into 🙂
There is nothing wrong in owner having high permissions so long as the administration is willing to support it and understand it.
Security Clearance and Supplemental Markings are OT’s way of securing against inheritance rules in big hush hush organizations.
A Post where I will try to share commonly looked for advise,many time that does not require programming but just configuration,I hope to make this in a question answer format.I will also try to answer commonly encountered problems if it does not require me to stop my paid work .
Category,Attributes and the mandatory aspects of it.
Categories is a template in livelink so that you can “model” your metadata requirements.In essence after you “create” the category and create meaningful “leaves” or “attributes”,you can allow others to use it as models where you can use awesome livelink search api .Here’s the RUB most container objects like Folders does not make the “mandatory” compulsory but if you try to add a versionable subtype like “Document” it becomes mandatory.Now imagine somebody starts using a OT tool like EC or Explorer to copy a file system full of things into livelink,the folder gets replicated but livelink will stop the user from proceeding forward until documents get filled with mandatory metadata.If memory serves me right OT will even allow a flag that says substitute a top filled attribute to be trickled in.Now if you are a programmer,integrator or even a casual user trying to get things done in a jiffy what you need to know is the “mandatory” aspect is tied to a livelink server instance(not globally enforced) as well as reversible in a subtype setting.So you can go to the admin.index and try to navigate to the command “Configure Required Attributes”.You will find that folder is un checked as well as document is checked,this is what prompts the mandatory pop up to occur when you add things.Note if you defeat what the modelers intended you will end up having data that does not get returned in a meta data search.Also try to use the livelink GUI as much as possible before you start programming as programming just replaces the human clicker at the gui, this is often overlooked by all new comers.
Added:Hugh pointed out the fallacy of a default attribute.Yes it is true that people will not put values if it can be inherited.But by the same token if the category is in need pf a upgrade and has 1 million items to be upgraded,it just adds to the cost of programming or operational efficiency.So Moral just do your design judiciously thinking that not only GUI users but there might be times you need to change the values around 🙂
BTW-To supply default values to help in a upgrade is what I have done most in my job 😉 Many times it is a quick and dirty job with the mandatory values read off a file.In my current employment we have a beautiful batch framework that is able to do all bells and whistles almost could sell this to OT.
Form Based Livelink Workflows and WF Attribute based workflows