Jump to content

Hi, We currently use AppStudio in WF8201M. We plan to add a...

Emily Lee

Recommended Posts

Hi Emily

Tell me about the blog. Is your blog a report (focexec) that your users run from WebFOCUS

The rules apply only to things in the WebFOCUS repository.

If its just a report that you want to lock down, or a folder where you lock down all the parts under the folder, you can do that with 8201. That functionality is old and should work fine. But we need to know what it is you want to lock down.

Id suggest locking down a folder instead a specific report if thats possible. Likewise, Id suggest letting a Group do the edits to the code instead of choosing individuals. Just makes your rule making simpler to deal with Groups and Folders instead of individuals and individual focexecs.

Where are the resources located that you need to control


Link to comment
Share on other sites


We currently use AppStudio in WF8201M. We plan to add a message blog to the current portal to deliver urgent messages to all users.

We want all users can read the blog, but only group of selected people can add/delete the blog message. Can this be done with WF8201M

Or can it be done with WF8207 - We will migrate to WF8207 in 6 months.


Emily Lee

Link to comment
Share on other sites

Hi Toby,

We want to add a blog onto a Portal to send messages to our user community like " Please ignore Report A of Date mm/dd/yyyy due to data discrepancy. We are working on this issue now. Stay tune."

We found that, we can add this message blog to our portal, and publish it, so all user community can see it. But at the same time, all users can add/delete any message from this blog. This is not what we want. Any suggestions


I am using AppStudio 8201M, I can not find what you said the Other tab in the WebFOCUS web interface under a workspace. Do you refer to AppStudio8207



Link to comment
Share on other sites

Hi Emily

So your blog is shown to the user the same way a report would be.

The key here is to make it only available for edit from a few users.

Something to understand about WebFOCUS and security - Unless you are permitted to do something, you will be denied.

Somewhere, someone has created a rule that allows your users to do more things to this focexec than you want. Best way to find out why users can mess with the focexec is by navigating to the focexec (lets call it blog.fex) then right click on it and look at Security / Rules on this Resource and likely youll need to check the box that says to show any rules that were inherited from folders above blog.fex.

Pictures always help. Oh - and also if you have an admin who governs your rules, they should be the one to do these steps:

Rules on this resource (with any parent rules)


image.png681547 52.2 KB


Check the Include Inherited box


image.png114076 5.13 KB


Youll see what Rules are governing your blog.fex. Usually the reason someone has too much authority is because you gave your Developers access to some folder above this. The Developer Role has lots of privileges turned on in it (read / write / run / delete etc).

Maybe youll want to move your blog.fex to a whole different folder that the other developers cant alter

Once you can see why they can alter your blog.fex, youll probably be able to figure out how to make it so they cant.

One suggestion: Try to make rules that Permit access as opposed to making individual rules to Deny. It gets hard to keep up with your Deny rules after a while.

Like for your example, if you move blog.fex under a folder called SystemMessages/blog.fex, youd Permit the group thats allowed to change it to have a role like DomainDeveloper, and youd give your normal users group Run (or List and Run).

Security takes a little while to get your feet on the ground with. If you already have an admin around, Id lean on them to help you get that working like you want. If youre the admin, just take a lot of screenshots so you can reset everything back to how it was. Just change one thing at a time and re-test.

Let us know if you have questions.

Link to comment
Share on other sites

There are specific operations for blogs. opCreateComments lets you add comments (and opEditComments lets you modify them afterward - a group in law enforcement never wanted a comment changed once is was created - even if it said the exact wrong thing!). And opReadComments allows a user to see the comments but can not add anything. And opManageComments lets administrators fix others comments). So before you make a new role, you may have roles (and some rules) in place already. You could probably simply insure your basic users already have opReadComments in the roles already grated for the domain. Then make an additional role called something like MakeComments and add a rule at the domain level that grants the group the role. While you can make rules on each individual blog, if its the same group that is able to add comments to all blogs in the domain, simply make the one rule at the domain level. (its faster and easier to manage).
Link to comment
Share on other sites


Should the Admin grant opCreateComments, opReadComments to each different roles ( such as Developers, Validators, Portal users)

When I created a blog at our Development environment portal, all developers can read/add/delete comments in the blog. But when I created a blog at a Production portal, non of our portal user can see my blog content, only the Admin ( Project Admin and Content Admin) can see the blog content.

I wonder maybe our portal user role does not have the opReadComment access.

Thanks for your direction, I will follow up with our Admin team.

Emily Lee

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...