4 Replies Latest reply on Jun 24, 2008 12:19 AM by Brian Slick

    I-DEAS Transition Problem - Access Control

    Brian Slick
      We are in the process of configuring Enterprise, and have bumped into what we perceive to be a major stumbling block. Actually, several, but I can't possibly do each topic any justice in a single post. I'm afraid I will have to compare to what we are currently doing in I-DEAS in order to define the issue. In the interest of space, I'm going to leave out the parts regarding "why" we do what we do, but if it matters I will be happy to provide that info in response to questions. For lack of a better description, I'm going to call this topic...

      ACCESS CONTROL

      We have I-DEAS configured with states that, in concept, are identical to states in Enterprise. I-DEAS does not have an equivalent of transitions. There is no workflow in I-DEAS, but how we move around between states is defined by procedures external to the software. The states that we have are:

      1. Initial
      2. Record
      3. Review
      4. Programming
      5. Pre-Issued
      6. Issued

      Basically, "Initial" is wide open, and is the default state for all new items. "Issued" corresponds to our document release process, and is locked down pretty hard. All of the others fall somewhere in the middle in terms of permissions. All states have, at minimum, read-only permission for all users.

      We do NOT allow check out of Issued items. The only action that can be performed against an Issued item is to create a new version. So if an Issued item needs to be revised, the user must first create a new version of it. The new version will be in the default state of Initial, and the user can then check the part out and make the required revisions.

      So that is most of the data management piece of the puzzle, but there is one more aspect that pertains to geometry. When an assembly is marked for check out (CK), all components in that assembly - parts and/or other subassemblies - will be marked as read-only (Rfl). So once the data is transferred to the local workspace, the end result will look like this:

      TopAssy - CK
      ...SubAssy - Rfl
      ......Part - Rfl

      Assuming that the user had permission to check out "TopAssy" in the first place, then this is the behavior that will always happen, regardless of the individual states of the sub-items (again, all states have at minimum read-only).

      I think that covers the preliminary information needed to define the issue. If I need to provide more, please ask.

      It would be a huge stretch to say that we fully understand what we are doing in Enterprise. So hopefully, we are just missing some combination of checkboxes necessary to get what we want. The problem is manifesting in a couple of different ways.

      First of all, as a starting point, we have created states in Enterprise to mimic what we have in I-DEAS. Same names, same permission levels. This means we have an "Issued" state in Enterprise that is read-only, and check out is not allowed. Following our normal document release process, we would issue data in a similar fashion, and thus wind up with the vast majority of our data being in this read-only state.

      The other scenario we are playing with is taking advantage of the global capabilities that Enterprise has, and I-DEAS lacks. We will be sharing data with several locations around the world, and our first location to play with is Australia. They do things differently than we do here in the US, so we will have an alternate workflow for their use. Data in the US workflow will be read-only for Australia, and data in the Australia workflow will be read-only for the US. We will collaborate on projects; we'll use their parts, they will use ours.

      In either scenario, the point is that I'm going to have a lot of stuff in a read-only state.

      In order to reach the problem that we are seeing, here are the preliminary steps to perform:

      1. Create a new part - Part1 - save it into the vault.
      2. Check in Part1. Do not keep it checked out.
      3. Approve Part1 into Issued state (read-only).
      4. Create a new assembly - Assembly2 - save it into the vault.
      5. Insert Part1 into Assembly2, save again for good measure.
      6. Check in Assembly2. Do not keep it checked out.
      7. Close all SolidWorks files.

      Everything is fine up to this point. Now I would like to add another part to Assembly2.

      8. Go to blueberry, find Assembly2, right-click Edit.
      9. The Check Out dialog window is presented, however it has a warning on it. Part1 says "No check out rights." That's fine, I'm not trying to check out the part, I'm trying to check out the assembly. However, I'm dead in the water.

      There is a setting in Enterprise about allowing users to ignore warnings, and I'm not allowed to ignore the warning. So I cannot go forward. I'm perfectly ok with the setting, what I don't understand is the reason for the warning. Why do I need check out rights on a part in order to check out an assembly? That makes no sense.

      If we change the setting to allow users to ignore warnings, then I can get through this dialog and open the assembly.

      In my head, the ability to prevent users from going through warnings is a fantabulous thing that I wish I had in I-DEAS. So I'm not comfortable at all with disabling this feature. Also, I'm not yet familiar with the gamut of potential warnings in Enterprise that may cause real problems if I allow users through.

      This is only an issue because SW and/or Enterprise seem to want to have check-out on parts in order to check-out an assembly. If I am incorrect about this, please correct me, because this is ridiculous if true.

      I'm only seeing a couple of options at this point. I can allow users to go through warnings (bad). I can prevent users from going through warnings (good), but then I have to allow check out for my Issued state (bad). I don't like either of those options.

      Am I accurately describing the state of the world? Is there some other option we need to know about? Any assistance will be greatly appreciated.
        • I-DEAS Transition Problem - Access Control
          I have had 'Can't ignore warnings' turned off on all my users since the beginning and we haven't run into any issues.

          From my understanding PDMWE doesn't care what the warning is; it just cares that there is one (or more) in the dialog and it will not allow you to continue. If it did care what the warning is, it would specify that in the error message. It doesn't. It only tells you the count of warnings.

          Warnings are just that; warnings. They are not errors. I can see your concern, but if your workflow is set up correctly you shouldn't have anything to worry about.
          • I-DEAS Transition Problem - Access Control
            Jeff Sweeney
            Lee you are correct that a good workflow can over come this problem, but one of the greatest benefits you get from that option is that it checks to ensure all children of an assembly are in the vault before the assembly is added. -Helps enforce users are keeping their stuff in the vault. At this point too early to be caught by workflow.

            So I want my cake and eat it too! When working with assemblies, I want it to check the children when checking in for the first time. In Brian's example I am working with the assembly - - I did not chose to checkout the parts, IMHO that should not be a warning. Maybe an alert, but a show stopping warning?

            It is enhancement request time!
            • I-DEAS Transition Problem - Access Control
              Brian Slick
              Thank you for the responses.

              Short term, I don't think we have any choice but to allow users to ignore warnings. Since I don't have an equivalent function in I-DEAS (thus no prior expectation), I'm not exceedingly worried about this for now. However longer term, especially once we get to a point of automating things based on activities in the workflow, this has me concerned. I guess I'll just have to cross my fingers and that bridge when we get there.