For the documents stored in the database, I would like to create a human readable key to uniquely identify the document. e.g. PO20090110-001. How do I go about doing that?
When saving a document you can put together the first part of the number by using the date or any technique you like (ej. "PO" & format(date, "YYYYMMDD") & confDoc.getitemvalue("doccounter")).
As for the counter I like to store it in a configuration document and update it when each doc is saved. If there are lots of documents created during the day you can run into rep conflicts on you configuration document, if this is the case you can have an agent on the server do the actual assigning of the number, the drawback to this is that you don't get the number right away when saving.
Hope this helps.
One solution used in our help desk is to take the initials of the current user and add it to the a number in the last document in a view. Add one to the number and store that it the new document along with the ititals and the new number as the key.
It's not simply.
Create field for uniquely key and this key saving onSave (or other event), but you must protect this number to be unique.
You can create agent, which checking number on domino server and if agent find conflict then notify application administrator or other responsibility person to resolve this.
Or each replica generate own number and after replicate on domino, agent assign number in right format.
You can create a "nearly" unique key in Domino simply by using the #Unique function, with no arguments. This will generate a string key, based on the current user's first and last name and the current clock time. You will end up with a string something like: "ESCR-12345678".
I say "nearly" unique, because it is not really like an identity column in SQL - Domino does not guarantee it will only give out a particular string once. If you use #unique in a server-side agent which generates many id's at once - for example, and agent that loops and uses #unique within the loop, you can get into a situation where #unique will return a duplicate - because you create 2 docs within the same second and because your "username" is always the server's canonical name. But, outside of that scenario, #unique is generally safe to use.
If you then need to open or reference docs by this ID, just create a view sorted by that ID and you can a url in the form ../myView/id?readDocument.
Related
I have recently learned tutorial about restful APIs.In that, my instructor suggested me that if we want to delete any document we should pass id in the parameter of the request. But now I am confused How do we handle this implementation on the client side.I mean how can even the programmer on the front side could be aware of that particular document ID. Does he need to go to the database each time?
Common practice for accessing a record in db is to use its unique identifier, to get or update or delete the record.
On the client side (if you mean user interface) when user wants to delete a document, he/she must see the document somewhere in the interface. Suppose a page with a table containing a list of all (for instance) books in the db. On each row, you have book title and author's name and the id of the book document in the db.
So you can use that id to call the delete rest API.
In a nutshell, when you want to delete something you must have got it from db to simply see it, so the id is at your hand.
When you want to delete a some doc from the database you need to get all documents to the front end to see what do we need to do to this data right ?
Imagine any database GUI that u have worked with..
let's say phpmyadmin when using mysqli
in that case you have php mydamin's GUI so that u can clearly see what are the tables and how things persist in the database. you need to see that in order for you to make decision
. Like that you will need to bring at least a portion of that data to the front end for user to see it and choose what portion of data the user want's to make changes or delete.
so when we have a set of data in the front end like a list, if a user select one item from that list the id or the name of that item can be send to the server side and make the task if the user wishes to do
that's why you need an Id or a identification field of that particular data..
I'm using Liferay 6.2.
My need is to add one user in LR, with a specific userID.
Or alternately, update a userID with another value.
The standard addUser service does not provide the possibility to specify the userID, and even the updateUser.
I would like to understand how LR choose the IDs for a new user, and if I can modify it.
thanks!
Like in almost any database driven application they're assigned in sequence. And no, you don't have to choose anything, it'll be taken care of by the framework. It needs to be unique, you can't add another user with the same ID and you must be sure that the user with this id will never be created in future. Thus: If you'd use an id that has already been given out, you'd have a duplicate. If you'd use one that has not yet been given out, you'll have a duplicate some time in future, when the sequence of ids comes to this value and the framework assigns the same id for the second time.
If you have an architecture that relies on a specific ID, your architecture is wrong. Rethink the problem and change the architecture and whatever you've already done to implement it.
LR core services use a CounterService to automatically assign UserId (and plugin developer should do the same)... so all the generating code is properly wrapper in the service methods that creates a number of rows in different tables when creating a user.
I agree with previous comment "If you have an architecture that relies on a specific ID, your architecture is wrong"... by the way you can use a tip.
Do you know Expando in LR? In enables you to add virtual columns on a DB entity... by using it, you can create a virtual column "myExternalId" to table "User_" (entity "User") and store there the ID you need. Then modify your code to use the field myExternalId instead userId.
Basically what I want to do is create a form whilst within another form and pass values from the earlier form to the second. Complicated I know but here is what I got.
#Do(#Command([Compose];"LPK"); #SetField("PR_Make"; PR_Make))
The fields in both forms have the same name and this code is called when first document is attempted to be saved.
I think instead of editing the field on the second form it just saves a field as itself instead. Any help appreciated.
The best and common way is to enable form property "Formulas inherit values from selected document" in second form "LPK".
Add a default value formula to second form's fields you want to inherit and put just the name of field itself in. For your example default value formula it would be
PR_Make
Make sure you save document first and then create the new document.
Knut Hermann's answwer is the 'standard' way of achieving such things but there are other methods- eg you can use environment variables ..
Something like:
#Environment("PR_Make") := PR_Make;
#Command([Compose];"LPK");
Then set the default value for PR_Make in your new form as ..
#Environment("PR_Make")
FYI Environment variables are written to the user's Notes.ini file and so remain even after Notes has been closed and re-opened. #Environemt doens't work too well with Web applications as it uses the server's notes.ini.
An alternative would be to use profile documents:
#SetProfileField( "PRDefaults"; "PR_Make" ; PR_Make;#Username);
#Command([Compose];"LPK");
.. in the default field for PR_Make on new form :
#GetProfileField( "PRDefaults"; "PR_Make"; #Username);
Profile documents are stored as a kind of hidden document in the Notes database and persist with the database. The last parameter sets a further subdivision by username so each user gets their own profile doc - a bit like a personal profile for "PRDefaults". You can miss this last parameter #Username out, to have one profile doc per database but there's a risk of two people trying to use it at the same time and clashing.
Profile docs also work with web applications.
I work in a development/support team which has a shared Lotus Notes mailbox. We need to be able to associate an issue ID with each email. We started by adding this ID to the subject line (eg. "Something doesn't work [ID12345]"). For performance reasons, our IT dept don't allow indexing of shared mailboxes, so it takes a long time to search for a particular ID.
I decided to add a new ID field, which can be shown as a sortable column in views and folders. I put this field to the visible header (just below 'Subject') in the ($All) view and the ($Inbox) folder, and copied the ($Inbox) design to all the other folders in the database. That much was easy.
My problem is that when we reply or forward, this custom field is not carried over to the new memo, so we have to manually add it again before sending. And of course when the user responds, the field is again missing and must be manually added. I have searched the docs and the internet and haven't found any information on this. Either I have to declare this field as something which persists across replies and forwards, or I have to add a line somewhere which explicitly copies the field contents to the new memo.
fsw,
We do exactly this with our complaint system however our database is indexed although this should not be an issue to you. We created a view that is sorted by ID by extracting just the ID from the subject line, order it by ID and then by date descending. Base it on the $ALL folder view so you get both incoming and sent emails.
We then altered the memo form to include an embedded view single category of the new view that sits above the body which shows all other documents linked to the ticket.
This should avoid having to delve to far into the very complex mail template any further. One thing is to make sure you have a copy of the changes you made and a bit of doco re deploying as you can guarantee that one day your template will be completely overwritten in an upgrade and all your good work will be gone.
As the additional field would have to incorporated into all Memo forms in mail templates in your corporation and as these fields do not easily travel via SMTP, you should stick with the ID in the subject.
What you could do is to parse the subject (#Mid, #Right, ...) in the column formula in the view and only display the ID there (like you did with the additional field).
The other option I envision if having a field is required is to have an agent that processes the incoming message(reply) to have it parse out the issue ID from the subject and write it to the field. You could also do that with queryopen or postopen if running an agent is not possible
I'm currently writing an application that moves Notes documents between databases based on the amount of days that have elapsed from the creation/modified/last accessed dates. I would just like to get ideas on a simple and convenient way to create documents with specific dates, without having to change the time on the Domino server, so that I could test out my application.
The best way I found so far was to create a local replica and change the system clock to the date I want. Unfortunately there are problems associated with this method. It does not work on the modified date - I'm not sure how it is getting the modified date information when the location is set to Island (Disconnected) - and it also changes the modified and last accessed dates when the documents are replicated to the server replica.
Someone suggested trying to create a DXL of the document, modify the date time in the DXL file, then import it back into the database as a Notes document; but that does not work. It just takes on the date-time that it was created.
Can anyone offer any other suggestions?
You can set the created date for a document by setting the UNID (which is fundamentally a struct of timestamps, although the actual implementation has changed in recent versions). Accessed and modified times, though, would be unsettable from within the Notes/Domino environment, since the changes you make would be overwritten by the process of saving the changes. If you have a flair for adventure and a need to run with scissors, you could make the changes in the database file itself either programmatically from an external application, or manually with a hex editor. (Editing the binary will work -- folks have been using hex editors to clear the "hide design" flag safely for years. Keep in mind that signed docs will blow up badly, and that you need to ensure that local encryption is off for the database file.)
There's actually a very simple way to spoof the creation date/time: just add a field called $Created with whatever date/time you want. This is alluded to in the Notes C API header file nsfdata.h:
Time/dates associated with notes:
OID.Note Can be Timedate when the note was created
(but not guaranteed to be - look for $CREATED
item first for note creation time)
Obtained by NSFNoteGetInfo(_NOTE_OID) or
OID in SEARCH_MATCH.
Unfortunately, there's no analogous technique for spoofing the mod or access dates. At least none that's ever been documented, as far as I know.
I imagine given how dependent Lotus Notes is on timestamps (for replication, mainly), there isn't an API call that allows you to change the modified, created, or last access dates of a note. (More on the internals of Lotus Notes can be found here.)
I dug around the Notes C API documentation, and found only one mention on how to get/set information in the note's header, including the modified date. However, the documentation states that when you try to update that note (i.e. write it to disk), the last modified date will be overwritten with the date/time it is written to disk.
As an alternative, I would suggest creating your own set of date items within the documents that only you control, for example MyCreated, MyModified, and MyAccessed, and reference those in your code that moves documents based on dates. You would then be able to change these dates as easily as changing any other document item (via agents, forms, etc.)
For MyCreated, create a hidden calculated form field with the formula of #CREATED or #NOW. Set the type to computed when composed.
For MyModified, create a hidden calculated form field with the formula #NOW, and set the type to computed.
MyAccessed gets a bit tricky. If you can do without it, I suggest you live work with just the MyCreated and MyModified. If you need it, you should be able to manage it by setting a field value within the QueryOpen or PostOpen events. Problems occur if your users have only read access to a document - the code to update the MyAccessed field won't be able to store that value.
Hope this helps!