![hierarchical structure][1]Previously we were using #functions to create forms and those forms are hierarchical structure means.
Initiator raises the form and sends to particular dept officer
Department officer approves and sends to next authority(Dept HOD) for approval
Finally, Dept HOD approves the form.
Now I want these structure in xpages. Please help me with how to create.
The general pattern of application creation hasn't changed. You show and hide information based on values in the documents. In classic Notes application you use "HideWhen" formulas using the #Formula language. These formulas work on the current paragraph.
In XPages you use the "visible" property. Clicking on the diamond shape next to visible allows you to enter code there. That code is written in server-side JavaScript.
The difference: in classic Notes a result of true means the whole row gets hidden, in XPages: the element (and all its children) is visible.
You might want to learn more about XPages following my guide and do the 27 Exercises
Related
Here's what I'd like to do but not sure how to. I have a form that's like a typical doctor/school form, where the form has 2 sections: [1] Section 1 at the top is for user (with standard fields like First Name, Last Name etc.), and [2] Section 2 at the bottom is for Admin/Office use only (with fields like Reviewed by, Approved/Not Approved etc.)
what I was able to do is to process Section 1 where I got ALL users' submission and display all their data on a webpage using a RepeaterWithCustomQuery. That's pretty basic. But in order to do what described above, I guess that I'll need to pull the submitted data and populate them back to Section 1 of the form (maybe as readonly data at this time) and then the Office/Admin staff can fill in Section 2.
I hope I made sense and hope that someone can point me to the right direction. I only use Portal Engine, no access to file system or backend.
I think I understand your issue you want to have some sort of an editor for biz form data. Similar to what you have in the admin. And the problem is that you don't have access to backend. :( Such thing is available for custom table data (there is web part), but not for biz form data. There is no ready to use web part. Here is old topic on that https://devnet.kentico.com/questions/how-to-edit-the-information-of-a-record-using-the-bizform-layout.
you want to have something like the admin page for editing form records:
/CMSModules/BizForms/Tools/BizForm_Edit_EditRecord.aspx?formID=7&formRecordID=1
but customized :(. I'd say without back end access the only options I see:
Create a new role "Biz Form Editor" (or use existing) that has rights only to edit biz
form data. So all your people who do "validation" part must have a
Kentico account with role "Biz Form Editor".
Add link above to your repeater with appropriate record id.
P.S. There are special code names for alternative forms (https://docs.kentico.com/k8/configuring-kentico/creating-alternative-forms/code-names-of-automatically-used-alternative-forms). If you create an alternative form with special name update the system will automatically load it when you edit the record.
Not sure that I understood correctly your question. But what you need is to use alternative forms. So the idea is that one form is for "registration" and the 2nd one for "validation".
So in your registration form you show only firstName, lastName etc and you don't show "validation" fields. In the validation form you show firstName, lastname etc as label and show textboxes for validation fields.
One of the standing out features of Acumatica's Modern UI is the Form-Specific Help menu, which is opened when you click the Help button while viewing the majority of forms:
I wonder how big is the effort to create Form-Specific Help menu for a custom screen?
As described in the Acumatica ERP documentation, to link a reference article with a particular screen, you should specify the Article ID based on the Screen ID of the form, replacing periods with underscores. For example, if the Screen ID is AP.10.10.00, the ID of its reference form must be specified as AP_10_10_00.
A very similar concept is used to link form-specific help with a particular screen. If you take a quick look at the Wiki Site Map (SM.20.20.10), you should notice the Form Quick Reference node under User Guide:
The Form Quick Reference node in its order contains a number of sub-nodes representing different modules of Acumatica ERP. And by checking the list of Wiki articles included into the Sales Orders (User Guide -> Form Quick Reference -> Sales Orders), you can easily tell, that form-specific help menu is nothing more than a Wiki article linked to a particular screen. To link form-specific help with a particular screen, you should specify the Article ID based on the Screen ID of the form, replacing periods with underscores and adding _NAV in the end of the Article ID.
The content of a Wiki article representing form-specific help is usually quite simple:
==Procedures==
[HelpRoot_User\SO__How_Create_Sale_Order|To Create a Sales Order (SO)]{br}
...
[HelpRoot_User\SO__How_Process_RM_Order|To Process Authorized Returns (RM)]
==Concepts==
[HelpRoot_User\SO__con_Order_Processing|Sales Order Processing Options]{br}
...
[HelpRoot_User\SO__con_Order_Types_for_Returns|Predefined Order Types for Customer Returns]
==Form Reference==
[HelpRoot_User\SO_30_10_00|Sales Orders] ([~/?ScreenId=SO301000|SO.30.10.00])
==Help Dashboard==
For the majority of standard Acumatica ERP screens, form-specific help consists of up to 4 sections:
Procedures
Concepts
Form Reference
Help Dashboard
Also keep in mind, the Procedures section is considered optional and can be easily excluded from some of form-specific help menus.
Hoping someone can point me in the correct direction for an XPages application we are writing inside the Domino Client (Notes?) viewer.
I have a view of documents which is being returned, this view has categories on it, and shows fine as this in an XPage, we now apply a filter to the view to limit it to specific owners of the documents, but as soon as we apply the filter, the categories disappear, which means we are left with a long list of documewnts, but unsorted - is there any way to display a filtered view in a categorized manner, on an XPage.
Moving further down my list, I also need to be able to select these documents (and one or many owners) to send to an Lotus Agent which will then create a JSON document to be sent to our friends at DocuSign requesting signatures from the selected owners on the selected documents. I'm not sure what an Agent is yet, but that is the goal ...
Caveat: I'm not a Domino developer, so excuse me if some of the terminology is incorrect.
Categorised views are a very "Notes" construct. When you filter a view, it will only show documents, but not categories. While they are practical in the back, they are cumbersome in the UI.
There are a few design considerations how to tame them in a webUI. However if your users love them, you might consider to flatten them out and recreate the categories in the UI (client side) only.
The actual better way for your use case: add another view that is firstly categorised by the owner and secondly by your category. Use the category filter of the view control to limit the documents to that author. This should do the trick. Eventually use one of the controls from the extension library.
For the agent: don't bother, that's "old Notes speak". An agent would be a piece of code (LotusScript or Java, but since you do web interaction: Java) that gets triggered by an event: manual, on schedule, on document create/update (with some delay).
Since you are in an XPage, you have easier options at your disposal: create a Bean that has the JSON format you need, add a method that takes a Notes document as parameter to populate it, something like public void populate(final Document doc) {...} and use e.g. the GSON library to simply marshall them to JSON (or a collection of them). The GSON library probably is on a current Domino, I put it there as part of VoP 1.0.
Then use a managed bean to talk to Dokusign. When traveling down the managed bean road is is much easier to test than trying to mess with agents.
Hope that helps and ask more questions! (Check the Learning XPages Cheatsheet too)
In my SharePoint List, I have an "Employee" column that is a User type field. I would like to add some custom Business Logic to the processing of this field.
Currently, when the user adds a row, I check to see if the user is an Employee or a Manager and then change the behavior on this column accordingly. I do this by statically rendering the field in my custom "ListForm Rendering Template", just before my custom ListFieldIterator. I simply use a standard SharePoint FormField (and FormLabel) control. In the markup of the FormField control, I specify the FieldName (Employee) and an event handler for the Load event. In this Load event, I will check to see if the current user is an Employee or Manager (using two different SharePoint groups). If the user is an Employee I set the value of the field to the current user (this part works perfectly). I also want to change the field so it can't be modified. I thought I might be able to just change the ControlMode on the field (in the code of the OnLoad Event Handler) to Display, but for some reason this has no effect. The field still renders with the full, people picker editor. Am I not changing the fields control mode soon enough? Or is this simply not the correct approach? The other logic I want to put in is if the user is a Manager, I would like to allow that user to select the person from a list (SharePoint group) of Employees. It may be easier to just use the people picker and limit the selectable users to that group. (I think I can do this with the SelectionGroup property.) Although, it would be better if I could just provide a dropdownlist of users, which I could possibly do with a hidden dropdownlist that I would show and event handlers that I could use (handle event selectedindexchanged) to pull the value selected and populate the (now hidden) Employee (user) field. Does this approach make sense? Assuming all that will work, the real difficulty I am having is with changing the ControlMode (rendering) on the field (when the user is an employee) to a label or some kind of read only control, which is how that field renders when viewing the row, which is why I think if I can just trick the control into thinking it is in Display mode then it should work perfectly!
I am still learning SharePoint, but I am very proficient in ASP .Net. This is why I would like to keep my customizations in this Custom Rendering Template, using code behind and leverage my existing skill set as much as properly.
Any thoughts, opinions or advice? Does anyone know why I can't get the column to switch the "Control Mode"?
I do not think that I fully understand your scenario. Some code samples could help.
But anyway it sounds like you want some heavy customizations of the user field. In that case you might want to have a look at creating a custom field with all its advantages and disadvantages. Have a look at MSDN: http://msdn.microsoft.com/en-us/library/gg132914.aspx
Another option might be - in case you do not want to re-use this column in many list definitions - that you can get away with your custom rendering template and create a custom create/edit form where you implement the specific edit behaviour for the field (plain ASP.NET with some SharePoint controls). Here is a nice walk-through on how to grab a custom edit form from SharePoint designer: http://community.bamboosolutions.com/blogs/sharepoint-2010/archive/2011/05/12/sharepoint-2010-cookbook-how-to-create-a-customized-list-edit-form-for-development-in-visual-studio-2010.aspx
I hope this helps. Kr., Bernd.
I have 10 form libraries on a Sharepoint 2007 site.
The site is for the use of 20 "Scholars". Any Scholar (or any of a dozen secretary-types who assist them) can go into any form library, cick [New] to get an Infopath Form, select the appropriate Scholar's name from a drop-down list field, fill out the rest of the form and click [Submit]. The form is then saved (with the title of the form being the Scholar name that was selected from the drop-down list).
The owners of this site want to be able to generate a report (at any given time) that lists all 20 Scholars and which of the 10 forms each has completed.
......................Form1...........Form2............Form3.........etc....Form10
Scholar Ann Adams.....completed.......not complted.....completed............not completed
Scholar Beth Baker....completed.......completed........not completed........completed
etc.
Any ideas on how to automate this?
For something like this, I would use an ItemUpdated event receiver to write details of who has updated the form to a separate audit list. Then you can simply query the audit list to get the report you need.
To implement this, first create the audit list containing fields for the form name and a user name (as well as anything else that you feel would be useful to log). Then create an Event Receiver derived from SPItemEventReceiver. The receiver will need to only work on forms libraries. Within the event receiver, override the ItemUpdated method to check of the item that has been updated is a form, and if so log the name of the form that was updated and the user who updated it to the audit list.
There is a very similar example to this at http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spitemeventreceiver.aspx, although it uses the ItemAttachmentAdded method rather than ItemUpdated.
Some other tutorials that may be useful to you are here and here.